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

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

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:05:29 UTC