Subject: Re: Review of draft-ietf-webdav-quota-02.txt

From: Brian Korver <[email-masked]>
Date: Fri, 7 Nov 2003 18:00:05 -0800

On Monday, October 27, 2003, at 01:47  PM, Julian Reschke wrote:
>
> Issues with draft-ietf-webdav-quota-02.txt
>
> Content
>
> 01-C01 Organization
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
> 0425.html>
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
> 0438.html>
>
> I think the draft could greatly benefit by a more clean separation of  
> (a) terminology, (b) protocol (property/error code) definition and (c)  
> examples.
>
> Proposal for a outline:
>
> 1 Introduction/Notation/Terminology
> 2 Additional live properties
> 3 Modification to behaviour of existing methods (error marshalling)
> 4...n Other standard RFC section
> A (Appendix) Examples of how servers may implement quota
>
> I'm happy to help restructuring the document if this is just a  
> amount-of-work issue.
>
>
> 01-C02 DAV:quota-assigned-bytes
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
> 0425.html>
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
> 0436.html>
>
> The issue here seems to be that an additional property is required to  
> make the quota authorable. I honestly haven't understood yet why it's  
> needed. The problem seems to be that as the reported quota may be a  
> "best pick" by the server (there may be multiple quotas in place, but  
> only the most strict will be reported at any point of time). If this  
> is the case this could potentially be fixed by exposing all quotas to  
> the client.

The issue of supporting "many" quotas on a resource was discussed
and rejected.

>
> At the end of the day, unless we can agree about how this is supposed  
> to work I strongly suggest to leave it out of the base spec and use a  
> vendor-specific property for setting it.
>
>
> 01-C03 quota vs disk space
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
> 0439.html>
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
> 0460.html>
>
> The spec says that servers may expose physical disk limits as quota.
>
> a) This is incompatible with NFS from which we're borrowing the  
> semantics (it treats disk limits as a separate property, and so should  
> we)
> b) Stefan raised interesting usability issue that weren't resolved so  
> far  
> (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
> 0456.html>).

Perhaps you're still looking at an older version of the draft?
Addressing this issue was the biggest change between -01 and -02.

>
>
> 02-C01 Condition Name
>
> Use name of precondition, not failure description:  
> <quota-not-exceeded/> instead of <storage-quota-reached/>

Does anyone else want to vote on the necessity of this change?

>
>
> 02-C02 allprop marshalling
>
> Change to MUST NOT (to reflect current ACL/DeltaV/Ordering approach).

Could you provide the text?

>
>
>
> Editorial:
>
> 02-E01 non-ASCII characters in draft
>
> 02-E02 sample host names do not conform to RFC2606
>
> 02-E03 missing section numbers
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>
>
>
-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Sat, 08 Nov 2003 10:22:26 +0100

Brian Korver wrote:

>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0425.html>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0436.html>
>>

True. This is a simplification that works well as long as the quota is 
not authorable. If it becomes authorable (by means of this additional 
property), there's a big issue because the behavior of the server 
becomes completely unpredictable.

>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0439.html>
>> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 0460.html>
>>
>> semantics (it treats disk limits as a separate property, and so 
>> should  we)
>> far  (<http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/ 
>> 0456.html>).
> 
> 

Nope. Somewhere on page 3 it says:

"Note that there may be a number of distinct but overlapping limits, 
which may even include physical media limits."

(wouldn't it be nice to have section numbers?)

> Does anyone else want to vote on the necessity of this change?

Please.

> Could you provide the text?

Change:

     None of these properties need be returned in a <DAV:allprop> request
     though the server may include them.  However, these property names
     MUST be returned in a <DAV:propname> request for a resource that
     supports the properties, except in the case of infinite limits which
     are explained below.

to

"A DAV:allprop PROPFIND request SHOULD NOT return any of the properties 
defined by this document."

(or just refer to RFC3253, section 3.11)

Regards, Julian

---

From: Frank Lowney <[email-masked]>
Date: Sat, 8 Nov 2003 08:00:37 -0500

Re quotas, as an implementor (reliant on what server vendors make 
available) I'm not sure I understand the discussion very well so let 
me make a few general comments from my perspective and hope that you 
can see whether and how they fit.

The current bias of WebDAV implementation favors the single web site 
that has multiple authors.  In this context, a single, overriding 
quota makes sense.  Of course, this site could be one of many Virtual 
Hosts running on the same machine, served by the same webserver, etc. 
I have no quarrel with that scenario at all.

My problem is with the exclusion of another, very important class of 
website, the individual web site and this is not favored by the 
WebDAV bias.  While this class of web site may include personal web 
sites that may be considered frivolous, it also includes  many 
serious, professional web sites that need WebDAV even more that 
large, corporate/institutional web sites do.

For example, we currently host a Faculty Web Server where every 
faculty person is allocated 250 Mb of space with which to share 
information relevant to their teaching, service and research.  If 
they try to FTP upload beyond that limit, they are programmatically 
refused.  There is also a "soft" limit where they get a warning and 
we have a CGI that gives them a graphical and numeric representation 
of their allocation and how much of it has been used.

We would really like to replace FTP with WebDAV but to do so will 
require being able to set and enforce hard/soft limits and provide 
feedback such that account holders can regulate their own behavior.

At this point in history, WebDAV is like the Wild West.  The first 
person to grab disk space gets to keep it and the others have to make 
do with less.  We actually have one faculty person who managed to lay 
claim to more than a Gig of space before we implemented the limits.

Even more daunting is the prospect of a Student Web Server with 
5,000+ accounts that we are currently in the planning stages for. 
Students will be required to develop portfolios that will be used to 
evaluate their work prior to graduation and provide prospective 
employers with data to support employment decisions after graduation. 
Not frivolous at all.
-- 
=====================================================================
Dr. Frank Lowney  [email-masked]
     Director, Electronic Instructional Services, a unit of the
     Office of Information and Instructional Technology,
     Professional Pages: http://www.gcsu.edu/oiit/eis/
     Personal Pages: http://www.faculty.de.gcsu.edu/~flowney
Voice: (478) 445-5260
=====================================================================
We don't make instruction effective, we make effective instruction 
more accessible.

Please note that my new e-mail address is: [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Sat, 08 Nov 2003 14:46:49 +0100

Frank Lowney wrote:

> available) I'm not sure I understand the discussion very well so let me 
> make a few general comments from my perspective and hope that you can 
> see whether and how they fit.
>
 > ...

Frank, essentially what you're saying is that quotas are a good thing. I 
don't think anybody disagrees. As a matter of fact, some WebDAV servers 
indeed support quotas (for instance, the Xythos server or (I think) 
Apple's IDisk server).

The discussion that we're currently having is how a server can *expose* 
quota information to the client. This has little to do with actually 
*enforcing* the quota (as the current implementations show). All this 
new protocol is supposed to add is

- an interoperable way for clients to find out about their quota situation
- and possibly a way to modify quotas from the client (although it seems 
to be hard to define an interoperable way to do that)

Regards, Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 12 Nov 2003 10:01:49 -0800

> becomes completely unpredictable.

It should be simple to make things predictable by saying that the
server MUST (SHOULD?) support only one quota if it allows that quota
to be authored via the mechanism in this draft.

In practice, there is usually one important size limitation.  On a 
service like sharemation or Apple's iDisk, that's the quota.  On a
hard drive that's the drive size.  Even though in theory there may
be a size-limited hard drive behind a quota-limiting system, it won't
change how things work except in extremely rare cases.  And let's not 
design a system that is optimized for the extremely rare cases.

Lisa

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Nov 2003 17:08:32 +0100

> to be authored via the mechanism in this draft.

That would work, but seems like a hack. First we sell it as a feature 
that the server selects a specific quota, and then a feature is added 
that is incompatible with that.

> design a system that is optimized for the extremely rare cases.

We just reached agreement that physical disk limits should not be 
treated as quota, right Brian?

Julian

---

From: Brian Korver <[email-masked]>
Date: Wed, 12 Nov 2003 16:38:16 -0600

> treated as quota, right Brian?

That's news to me.

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Wed, 12 Nov 2003 23:52:08 +0100

Hmm. Then there was a misunderstanding here...:

 >should

---

From: Brian Korver <[email-masked]>
Date: Wed, 12 Nov 2003 17:30:31 -0600

> >Addressing this issue was the biggest change between -01 and -02.

Julian,

The "issue" I was referring to was the one immediately above my comment.
In other words, (b) is not valid.

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Nov 2003 10:08:46 +0100

> In other words, (b) is not valid.

Then please explain how the latest draft adresses the issue. Also 
explain why mixing physical disk limits and quota is ok, although it 
creates confusing behaviour *and* is incompatible with NFS.

Julian

---

From: Brian Korver <[email-masked]>
Date: Thu, 13 Nov 2003 08:32:26 -0600

> creates confusing behaviour *and* is incompatible with NFS.

Simple, we went with NFS's model rather than quota-limit.  So, if it's
still confusing to you, then blame NFS.

I didn't realize that compatibility with NFS was one of WebDAV's
requirements.  ;-)

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Nov 2003 15:51:15 +0100

> I didn't realize that compatibility with NFS was one of WebDAV's

Brian,

as far as I can tell, there's nothing confusing with what NFS says. The 
confusion arises because the quote spec

- marshalls disk limits and quota using the same mechanism (contrary to 
NFS) and
- the quota spec introduces a new property for authoring quota.

Why doesn't the quota spec just *copy* the relevant parts of NFS (all we 
  need to is map four property names)?

Julian

---

From: Brian Korver <[email-masked]>
Date: Thu, 13 Nov 2003 12:44:48 -0600

On Thursday, November 13, 2003, at 08:51  AM, Julian Reschke wrote:
> as far as I can tell, there's nothing confusing with what NFS says. 
> The confusion arises because the quote spec
>
> - marshalls disk limits and quota using the same mechanism (contrary 
> to NFS) and
> Why doesn't the quota spec just *copy* the relevant parts of NFS (all 
> we  need to is map four property names)?
>
> Julian

Julian,

The quota draft does differ from NFS, but that property alone
shouldn't mean that the quota draft is confusing.  Perhaps
you could state what you find confusing about the current
draft (and please, use the current draft, because this stuff
has changed).

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Nov 2003 20:14:22 +0100

Brian,

when I re-raised these issues, I *did* read the current draft. So I 
think it's up to you to go back to the mailing list discussion and 
explain why the concerns raised by Stefan and myself aren't valid.

Julian

---

From: Brian Korver <[email-masked]>
Date: Thu, 13 Nov 2003 15:06:12 -0600

Julian,

I'm planning to do so in today's meeting, but to restate for the 
mailing list,
Stefan pointed out that if we used quota-limit, then quota-limit would 
not be
a fixed value (which is the reason we defined things in terms of 
quota-limit
to begin with).  Thus, instead of quota-limit, the new draft uses NFS's
quota-available.  This has the semantics that it isn't fixed.  Problem 
solved.
Note, quota-available is consistent with the rest of the the quota 
definitions
we pulled from NFS, so it's conceptually attractive too.

I still don't know what you find confusing, so I can't comment on that 
yet.

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 13 Nov 2003 22:35:03 +0100

Brian Korver wrote:

> I'm planning to do so in today's meeting, but to restate for the mailing 
> list,
> I still don't know what you find confusing, so I can't comment on that yet.

Brian, you may be right -- I'll have to re-review the change.

I'M still not convinced that handling both quota and disk space limits 
using the same properties is a good idea, especially as NFS does it 
differently.

Minor editorial note: RFC3010 has been obsoleted by a newer revision.

Julian

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 14 Nov 2003 11:27:03 +0100

Brian,

I put my mind into blank slate mode and read the draft 2 for the first 
time.

I think it is a big improvment from where we started from. One item I 
found
confusing though and that is the example for DAV:quota-assigned-bytes
(and the mental model behind the example).

The draft seems to say that /A and /A/B have separate 
DAV:quota-assigned-bytes
properties, however they are in the same "set of collections" when the 
value
of DAV:quota-available-bytes/DAV:quota-used-bytes is computed.

(See definition of "set" in the explanation to DAV:quota-used-bytes - 
seems to
be a copy from the NFS spec.)

In NFS-Quota, the model seems to be simple: each quota applies to a set
of collections/files and each member of this set would report the same
quota properties.

In WebDAV-quota (draft-2): there is a separate quota for each collection
(e.g. the assigned-bytes), but available-/used-bytes are the same for
resources in the same set.

Two Problems come to my mind now:
1) If a collection of the "set" has the DAV:quota-assigned-bytes not
   explicitly set, what value would it report? Say for /A/C, /A/B/D and
   /E (all in the same set)?

2) If a client wants to increase DAV:quota-available-bytes in a certain
   collection, it has to increase the DAV:quota-assigned-bytes. But in
   your example: increasing assigned-bytes on /A/B will not have any
   effect on the DAV:quota-available-bytes. What is a generic client 
supposed
   to do then?

Best Regards, Stefan

---

From: Brian Korver <[email-masked]>
Date: Mon, 17 Nov 2003 14:23:30 -0600

> (and the mental model behind the example).

I agree on both counts.  Any help on making the example less confusing
would be appreciated.

> of collections/files and each member of this set would report the same

I'm not sure that I understand what you're saying.  On BSD, for 
instance,
quota is specified per-filesystem.  Therefore, if I've got the 
following mount
points and quota specified:

     /home/briank/           # my home directory, quota 1GB
     /home/briank/mp3s       # quota 100GB
     /home/briank/video      # quota 50GB
     /home/briank/small      # quota .25GB

So here, the 'set' is a filesystem.

>   /E (all in the same set)?

I presume the server would just not return DAV:quota-assigned-bytes
if it isn't set.  Hmm, that should be stated in the document.  Will fix.

>   effect on the DAV:quota-available-bytes. What is a generic client 

The generic client should allow the user to change quota wherever
it can be.  It is up to the user to understand the quota model.
I don't know what else can be done.

-brian
[email-masked]