- From: Cullen Jennings <fluffy@cisco.com>
- Date: Sun, 10 Jul 2005 09:01:48 -0400
- To: WebDav <w3c-dist-auth@w3.org>
The text below is what I plan to send off with the request for publication.
---------------------------------------------
1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?
Yes
1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?
The document has had significant review and discussion over several years.
The active participants in the WG is currently very small and thought only
two people made comments during WGLC, it is probably not possible to get
wider review at this point. This has been implemented.
1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?
The quota concept is very simple and unlikely to need wider review.
1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.
The WG is very small - See 1.e. Not clear if it should reference current
webdav RFC or the bis version of it - See 1.h
1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?
Two people commented during WGLC - the authors think it is OK. The WG
probably has between 5 and 10 people that post on the list. The work looks
reasonable, some people want it, it's effectively been done for a long time.
It is unlikely to cause harm. I am recommending that we decide a handful of
people looks like rough consensus in this case and we move this draft along
to proposed standard.
1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email to the Responsible Area Director.
Not that I (the chair) am aware of.
1.g) Have the chairs verified that the document adheres to all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).
Yes
1.h) Is the document split into normative and informative references?
Yes
Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
No
This documents extends the base WebDav protocol defined in RFC2518. The WG
is currently close to finishing a 2518bis document. Some thought should go
into if this document should reference 2518 or 2518bis. I do not believe and
the mechanism described in this quota ID would change in any way if the
reference to 2518 was change to 2518bis so I don't view this as too critical
one way or the other.
1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:
* Technical Summary
WebDAV servers are frequently deployed with quota (size) limitations that
limit the amount of information a particular user can store on the server.
This document discusses the properties and minor behaviors needed for
clients to interoperate with quota (size) implementations on WebDAV
repositories. Specifically it defines a way to find the space used and space
available on a given store by defining two new properties. It also defines
an error to indicate that an operation is not possible because it would
exceed a quota limitation and a separate error to differentiate this from
when the quota was not exceed but there was not enough space to do the
operation.
* Working Group Summary
The WebDav Working Group came to consensus on this document.
* Protocol Quality
Some vendors have implemented this protocol.
Received on Sunday, 10 July 2005 13:02:01 UTC