- 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