Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt

From: Brian Korver <[email-masked]>
Date: Fri, 7 Mar 2003 11:36:41 -0800

The new version differs rather substantially from
the previous, incorporating the borrowed-from-NFS
model that we discussed at the last get together.

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 19 Mar 2003 17:07:48 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Brian Korver
> Sent: Friday, March 07, 2003 8:37 PM
> To: WebDAV
> Subject: Re: I-D ACTION:draft-ietf-webdav-quota-01.txt
>
>
>

Hi Brian,

I just re-read the current draft and I think it's a significant step into
the right direction.

However, I think the draft can be made much easier to read and more generic,
without harming the "client experience". Here's my proposal:

1) Properly define the technical term "quota space", and use it when
describing the live properties. The definition should be similar to what
RFC3010 uses, and I think the text from the description for
DAV:quota-used-bytes can be used as a basis:

"   The DAV:quota-used-bytes value is the value in octets representing
   the amount of space used by this file or directory and possibly a
   number of other similar files or directories, where the set of
   osimilaro meets at least the criterion that allocating space to any
   file or directory in the set will count against the quota-limit.  It
   MUST include the total count including usage derived from sub-
   resources if appropriate.  It SHOULD include metadata storage size
   if metadata storage is counted against the quota-limit.   "

2) Then simply define (for *any* resource):

DAV:quota-limit-bytes: number of octets that has been assigned to the
currently authenticated user in the quota-space in which the resource
identified by the request URL resides.

DAV:quota-used-bytes: number of octets that have been allocated towards the
limit above (again in the quota-space in which the resource identified by
the request URL resides).

(keeping the language that gives servers a lot of freedom how to count)

This should give clients all the information they need to display the
"percentage used" thingy.

3) The new draft introduces a new optional property DAV:quota-assigned-bytes
that seems to be used to support implementations where quota spaces can be
nested, so for example /A/B resides in a different quota space than /A. I'd
really like to understand whether this really requires a new property, or
whether the simple model above would suffice for this as well.

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Brian Korver <[email-masked]>
Date: Wed, 19 Mar 2003 15:17:12 -0800

On Wednesday, March 19, 2003, at 08:07  AM, Julian Reschke wrote:
> RFC3010 uses,

I couldn't find the term "quota space" in 3010 at all.  What definition
in 3010 are you thinking of?

> and I think the text from the description for

Personally, I think I'd rather we stick with the definitions
pulled from RFC3010.  They seem pretty clear to me.

> whether the simple model above would suffice for this as well.

Hmm, that was only intended as an example (and is identified as such), 
not
as an implementation requirement.  I'll add another example so that this
isn't confusing.

DAV:quota-assigned-bytes is merely to support implementations that allow
quota to be PROPPATCHed.  I'll try to make that clearer as well.

-brian
[email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 20 Mar 2003 09:38:32 +0100

> Sent: Thursday, March 20, 2003 12:17 AM
> To: Julian Reschke
> Cc: WebDAV
> ...

Right, RFC3010 doesn't define the term, but it uses the concept. I just
think that it makes sense to give the concept a name:

         The value in bytes which represent the amount of disc space
         used by this file or directory and possibly a number of other
         similar files or directories, where the set of "similar" meets
         at least the criterion that allocating space to any file or
         directory in the set will reduce the "quota_avail_hard" of
         every other file or directory in the set.

         Note that there may be a number of distinct but overlapping
         sets of files or directories for which a quota_used value is
         maintained. E.g. "all files with a given owner", "all files
         with a given group owner". etc.

         The server is at liberty to choose any of those sets but should
         do so in a repeatable way.  The rule may be configured per-
         filesystem or may be "choose the set with the smallest quota".

So basically, a "quota space" is the set of resources that share the same
quota.

> pulled from RFC3010.  They seem pretty clear to me.

For the record, i'm absolutely in favor to stick with the definitions from
RFC3010. Why don't we just steal them verbatim, or just refer to 3010?

IMHO,

         The value in bytes which represents the amount of additional
         disk space that can be allocated to this file or directory
         before the user may reasonably be warned.  It is understood
         that this space may be consumed by allocations to other files
         or directories though there is a rule as to which other files
         or directories.

is very clear (we may have to map some terms though). If we stick with this
language it's also much clearer why the distinction between plain resources
and collections (and other types) really doesn't make sense at all -- I'd
prfer the spec not to say anything about that.

> quota to be PROPPATCHed.  I'll try to make that clearer as well.

That didn't come through. Now it reads:

   The value of this property will usually be protected, although a
   user with sufficient privileges may be permitted to change the
   value.  The property is useful even if it is protected.  A 403
   Forbidden response is RECOMMENDED for attempts to write a protected
   property.

That sounds as if *usually* the property is read-only.

BTW: why do we need an additional property for that?

Julian

---

From: Brian Korver <[email-masked]>
Date: Fri, 21 Mar 2003 17:10:18 -0800

> So basically, a "quota space" is the set of resources that share the 

I'm not sure how important I think defining "quota space" is, but
I'd I'll add it since you think it would be helpful.

> RFC3010. Why don't we just steal them verbatim, or just refer to 3010?

They require minor tweaking, so I think it would be easier to
steal them.

> prfer the spec not to say anything about that.

I agree that it's clear.  The problem is that we defined things a little
differently from NFS:  DAV:quota-limit-bytes is different from
NFS's quota_avail_hard, in that

    DAV:quota-limit-bytes - DAV:quota-used-bytes = quota_avail_hard

We talked about doing this because we wanted the "amount free" that
is displayed to the user to be what the user expects rather than
a value computed by the client, which might not end up as a round
number.

I think the definition of DAV:quota-limit-bytes (and 
DAV:quota-assigned-bytes)
could be clearer, so any wordsmithing suggestions would be
appreciated.

> That sounds as if *usually* the property is read-only.

That makes sense.  For instance, most users shouldn't be able to
change my quota, as I shouldn't be able to change theirs.

> BTW: why do we need an additional property for that?

There are several instances where there are 2 numbers for
quota.  For instance, the quota system given in the example.
In the example, the assigned quota for B is 10,000,000 bytes,
while the limit is 1,000,000.  I'll try to make that clearer
in the example.

-brian
[email-masked]

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 24 Mar 2003 09:27:51 +0100

> a value computed by the client, which might not end up as a round

I wonder if this equation holds true when "disk space" gets low. Say you
have 10 GB of space on the server, you have 10 users and each user
has a quota of 1GB. You add an 11th user also with 1GB quota (or an
administrator puts a 1GB sized resource).

Now, when the free space on the server goes below 1GB, the above
equation will not tell you how large a file you can PUT. That problem
seems to be avoided in 3010 with "quota_avail_*".

//Stefan

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 24 Mar 2003 14:06:14 +0100

> Sent: Saturday, March 22, 2003 2:10 AM
> To: Julian Reschke
> Cc: WebDAV

I think it's useful if and only if we use it consistently to define the
quota properties (see below).

> ..

I think now we're confusing marshalling and implementations.

I agree that it would be confusing when the "available" value keeps changing
due to rounding issues. However, that's an effect of the underlying
implementation, not how the numbers are sent to the client. If a server
really decides to *compute* the total (I really can't imagine why it would),
changing the marshalling format will not change anything.

> change my quota, as I shouldn't be able to change theirs.

Why would a server allow a user to change his own quota??? That really seems
to be an adminstrator-only feature.

> while the limit is 1,000,000.  I'll try to make that clearer

If this is the case, there's still a major problem with the quota system you
describe.

Before we continue this thread, let's talk about whether the spec should
actually describe server behaviour at all. As far as I remember the
discussion in January, all that client implementors want is the ability to
describe a ratio of used / available, and possibly the ability to discover
the amount of storage a single resource takes. If we only need this, the
spec can be much shorter.

On the other hand, if the spec is going to define what quotas are and how
they behave, it needs to be compatible with more than a single
implementation, and you'll have to define why and how these two different
value may vary. Right now, I  honestly don't understand it.

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 24 Mar 2003 14:15:25 +0100

Brian,

here are two more issues I have:

1) During the discussion, I've seen soft limits (quotas) and hard limits
(disk space) used in the same context. I'm really not sure that it is a good
idea to use the same mechanism for both.

2) Related to that: I'm not sure that using 507 for failures due to quota
restrictions is a good idea. 5xx indicates a server error. In this case, the
problem is not causes by the server, but by the client (trying to take up
more space than allowed), so a 4xx with a new precondition code seems to be
more appropriate.

Julian

---

From: Brian Korver <[email-masked]>
Date: Wed, 26 Mar 2003 16:10:28 -0800

> seems to be avoided in 3010 with "quota_avail_*".

If the free spec on the server goes below 1GB, then the quota-used
will compensate.  I agree that isn't as intuitive as the "avail"
way of doing it, and this should probably be explained better
in the spec.

-brian
[email-masked]

---

From: Stefan Eissing <[email-masked]>
Date: Thu, 27 Mar 2003 12:19:18 +0100

Am Donnerstag, 27.03.03, um 01:10 Uhr (Europe/Berlin) schrieb Brian 

> way of doing it, and this should probably be explained better

If I understand you correctly the server will on low "disk space" tweak
the quota-used value so that the difference between quota-size
and quota-used matches the available space?

So a user with 5GB quota on a server with 4GB space left, will be told
that he already uses 1GB although he has no resources allocated?

//Stefan

---

From: Brian Korver <[email-masked]>
Date: Thu, 27 Mar 2003 11:36:15 -0800

> that he already uses 1GB although he has no resources allocated?

The server is free to do whatever it wants, but that is the idea.
We didn't think of this when we discussed deviating from the NFS
model.  I'm tempted to go back to the NFS model.  Does anyone
else have an opinion?

-brian
[email-masked]