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

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

Am 13.11.2003 um 22:06 schrieb Brian Korver:

>
> On Thursday, November 13, 2003, at 01:14  PM, Julian Reschke wrote:
>> 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
>
> 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
> briank@xythos.com

Received on Friday, 14 November 2003 05:28:17 UTC