W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2003

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

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 12 Dec 2003 16:16:41 +0100
Message-Id: <3025829C-2CB6-11D8-BA59-00039384827E@greenbytes.de>
Cc: w3c-dist-auth@w3.org
To: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>

Finally someone is paying attention!

Am 12.12.2003 um 16:05 schrieb Geoffrey M Clemm:

>
> I assume in Corollary2, by "all resources",
> you mean "all non-collection resources" ?

Yes, of course, as usual, you are right.

Newly created collections also belong to the same
quota space as their parents.

BR, Stefan

> Cheers,
> Geoff
>
> Stefan wrote on 12/12/2003 04:32:10 AM:
>
>>
>> Chris,
>>
>> I agree to your analysis that the current definitions lead to
>> confusion. The way out
>> is to simplify the underlying model.
>>
>> Definition: a "quota space" is a storage area on the server where
>> allocation can
>> be restricted. All collections on a server either belong to a
>> particular quota space
>> or to no quota space at all (in which case storage allocation, if
>> possible, in such
>> collections cannot be controlled by quotas).
>>
>> Corollary1: all collections of a particular quota space report the 
>> same
>> values for
>> their DAV:quota* properties.
>>
>> Corollary2: all resources belong to the same quota space as their
>> parent collection(s).
>>
>> Corollary3: all collections which may contain bindings to the same
>> resource do
>> belong to the same quota space. Collections in different quota spaces
>> cannot
>> have bindings to the same resource.
>>
>> With this model, /A and /A/UploadDirectory will either have the same
>> DAV:quota*
>> values or totally unrelated ones, depending if the two collections
>> belong to the
>> same or to different quota spaces. Thus the problem of "it does not 
>> sum
>> up" is
>> avoided. Also, server side implementation can be much simpler, as the
>> hiearchies
>> (e.g. bindings) of collections and resources do *not* influence the
>> quota values.
>>
>> //Stefan
>>
>> Am 11.12.2003 um 19:30 schrieb Chris Sharp:
>>
>>> Just getting around to understanding this thread. I totally agree, 
>>> the
>
>>> quota-assigned-bytes seems unnecessary and confusing.
>>>
>>> On another note, I think there needs to be some clarification the way
>>> quota-available-bytes and quota-used-bytes work.
>>>
>>> Example:
>>>
>>> Initial State of Repository with a Quota management system:
>>>
>>>
>>> DAV:quota-available-bytes   DAV:quota-used-bytes
>>>         /A                                                     95MB
>>>                                      5MG <--- used for somewhere for
>>> something
>>>         /A/UploadDirectory                      10MB
>>>                        0
>>>
>>> A new 5MB resource is created at  /A/UploadDirectory/new5MBFile:
>>>
>>> DAV:quota-available-bytes   DAV:quota-used-bytes
>>>         /A                                                     90MB
>>>                                      10MB
>>>         /A/UploadDirectory                      5MB
>>>                         5MB
>>>
>>> Pretty clear, however, if there is no quota differentiation on
>>> /A/UploadDirectory, the current draft of the RFC makes
>>> quota-used-bytes, which is really inherited from its parent,
>>> incongruent with quota-available-bytes on the same resource. A 
>>> diagram
>
>>> is in order:
>>>
>>> Initial State of Repository with a Quota management system:
>>> (quota system on /A only)
>>>
>>> DAV:quota-available-bytes   DAV:quota-used-bytes
>>>         /A                                                     95MB
>>>                                      5MG
>>>
>>> A new 5MB resource is created at  /A/UploadDirectory/new5MBFile:
>>>
>>> DAV:quota-available-bytes   DAV:quota-used-bytes
>>>         /A                                                     90MB
>>>                                      10MB
>>>        /A/UploadDirectory                       90MB
>>>                       5MB
>>>
>>> The sum of quota-available-bytes and quota-used-bytes is 95 on
>>> /A/UploadDirectory and not 100! Logically, if you get a request for
>>> quota-available-bytes on a resource /A/UploadDirectory and the quota
>>> is actually enforced on the parent, that you would essentially walk 
>>> up
>
>>> the tree until you found an appropriate "mount point" based quota
>>> requirement. If this is true, the quota-used-bytes should do the same
>>> thing. Meaning, quota-used-bytes on  /A/UploadDirectory would be the
>>> same as quota-used-bytes /A if /A/UploadDirectory did not contain a
>>> more specific quota rule.
>>>
>>> This is also an efficiency win for implementors. If an implementation
>>> has to support quota-used-bytes on an arbitrary URL, it is 
>>> impractical
>
>>> to think that quota-used-bytes could be incrementally adjusted and
>>> would necessarily need to be calculated on-the-fly, which does not
>>> scale well for most implementations.
>>>
>>> How NFSv4 handles this situation?
>>>
>>>
>>> Also, under the "Notes" section, "What clients should expect" seems 
>>> to
>
>>> have a sentence which is not grammatically correct.
>>> "This allows the space used by /~milele/public/ to be as
>>>     large as the quota on /~milele/ allows (depending on the other
>>>     contents of /~milele/) even if the quota on /~milele/ is 
>>> changed."
>>>
>>> Regards,
>>>
>>> Chris.
>>> On Nov 14, 2003, at 2:27 AM, Stefan Eissing wrote:
>>>
>>>>
>>>> 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, 12 December 2003 10:19:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:05 GMT