Subject: Coments, please (was Re: Working group process and the future of the WG.)

From: Ted Hardie <[email-masked]>
Date: Fri, 3 Jun 2005 11:24:32 -0700

Howdy,
	I've gotten a very small number of comments back
to this either on-list or in private; if you have a comment,
even a short "My level of interest is ....", I would appreciate
your taking the time to send it.
			thanks,
				Ted

At 1:12 PM -0700 5/27/05, Ted Hardie wrote:
>Several folks have asked where the discussion of the updated
>role of the WG Chair is documented.  This is an output of the
>PROTO team in the General area, and it is documented in
>http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt.
>
>Though this is not yet an RFC, the IESG agreed to work using
>these rules on an interim basis in February, and Scott Hollenbeck
>announced that the APPs area would be using it at the most
>recent Minneapolis IETF.  As most of you know, I was not at
>the meeting because of family commitments, but he did so
>with my full agreement.
>
>Though this updates the methodologies by which a working group
>chair and AD split the work of shepherding, it in some ways
>codifies the way good working groups have always worked--active
>working group chairs have always been involved in assuring that
>adequate review inside and outside the working group has been
>completed, that issues raised in Last Call or in IESG deliberation
>are handled, and so.  It has also long been the case that the
>IESG's reading of RFC 2418 on the role of the WG chair has seen
>a Working Group chair as responsible for assuring the community
>that a document put forward to meet a working group milestone
>is appropriate to the task (see Section 6.1).  Chairs can do that
>in multiple ways, but their own technical judgement is always
>expected to form a part of that assessment.  It is entirely appropriate
>for a chair to state a technical problem  with a spec and expect
>the working group and editors to either resolve the problem or
>document why the problem isn't an issue (usually in the spec).
>
>In cases where the working group chair has to call whether or not
>there is working group consensus on a particular resolution to
>a technical issue raised in this way, we can run into problems.
>The usual way of doing that is to have at least two chairs, so that
>one can handle the process call for technical issues raised by
>the other.   That strategy has been in place for this group since
>I came on as AD, though I have to say a series of time commitment
>issues has made it very hard to implement:  Jim had very few cycles
>at the time he stepped down; Patrik had to withdraw very shortly
>after agreeing to take the role; Joe has had issues with his organization
>supporting the time required.  Joe attempted to augment the usual
>mechanism by implementing a ticketing system, but those using
>it seem to have plural opinions even on what it takes to close a ticket
>so that it takes more, rather than less, effort to use it effectively.
>
>The forward progress in the face of that strategy's failure has not 
>been great.
>At this point, I want to reiterate that Lisa's actions as Chair have been
>both within my expectations as the AD for the group and that they have
>had my support; we have discussed the working group's progress
>on many occasions and the actions she and her co-chairs have taken
>have had gone forward with my knowledge and consent.
>She would be the first, I believe, to agree we have a problem in making
>forward progress.  She's also had the brunt of trying to resolve it,
>and I thank her for her efforts.
>
>The question I have now is how to make that progress
>when the existing strategy has failed multiple times.  We can change
>chairs, of course, and this might help clarify the process role vs.
>the contributor roles.  I am concerned, though, that is will not
>be enough given the very small size of the working group's active
>membership.  Judging rough consensus on a technical topic among
>only a few people when even one disagrees is tricky; if you solve
>that problem by ensuring that the chair has sufficient technical
>depth in the subject to adjudicate, you are back exactly where we
>are now.
>
>We can decide that the problem of size does not admit of solution,
>and we can shut down the working group.  This leaves a lot of
>WebDav's published specs augmented by unpublished "lore" that
>is needed to get things done.   I'm not thrilled by that, but if
>there is no way to get further, we may have to do it.  I will
>be very reluctant to accept individual submissions for the
>standards track on WebDav core issues if we go this route,
>since that forces the IESG to resolve issues the WG could
>not.  It might happen, but it would take work on the
>part of the proposers that is probably easier to accomplish
>in a working group setting.
>
>We can also try to radically limit what the working group is trying
>to accomplish and set out a firm deadline, after which the working
>group MUST shut down.  This helps focus energy and may encourage
>folks who cannot commit to long term energy to commit to the short
>term working group program.  If we go this route, I strongly suggest
>the working group consider a very draconian approach to reaching
>compromise.  One example I have seen outside the IETF that worked
>was to say that if an issue could not be resolved within a set period
>of time, the whole document involved sank to the bottom of the
>WG's agenda--so everyone is clear that the failure to compromise
>may mean that the document does not get out at all.  This
>requires a great deal of discipline and forces everyone to ask
>a new question ("Is this issue big enough that the document should
>not go forward at all if it is not fixed").  It can, however, work to
>get out the documents for which the WG is close to consensus
>and to focus work on others.
>
>I'd like to see the working group discuss these or other future paths.
>I do remind folks to remain professional in their discussion and
>that ad hominem comments are not tolerated; please think constructively
>about what *you* can do to move us forward and especially about
>what commitments *you* can take on.
>			regards,
>				Ted Hardie
>				as Area Advisor.

---

From: Eric Sedlar <[email-masked]>
Date: Fri, 03 Jun 2005 11:31:55 -0700

We'd certainly like to see the WG complete the specs it has been working 
on.  We are
planning on implementing other DAV specs in our next database release.  
Quota and BIND
are certainly very nice to standardize as well.

Thanks,

  Eric Sedlar
  Architect
  XML Database / Server Technologies
  Oracle Corporation

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 3 Jun 2005 14:51:33 -0400

I agree with Eric.  We are adding WebDAV access to a variety of our 
repositories, and plan on using the BIND protocol.  We also are eager to 
see the locking protocol officially cleaned up.

Cheers,
Geoff

---

From: Jim Luther <[email-masked]>
Date: Fri, 3 Jun 2005 14:16:31 -0700

We already have a variant of Quota implemented in .Mac iDisk server  
and the Mac OS X WebDAV file system and plan to conform to the real  
Quota spec.

BIND would allow us to implement hard links in our WebDAV file  
system, but that's not really that useful.

More useful would be support for Redirect resources which would look  
like symlinks to file system clients. We've been asked to support  
symlinks in the WebDAV file system many times.

The only other HTTP extension method we are interested in is PATCH  
(which was discussed on the HTTP mailing list for a while) because  
the lack of a way to modify part of a resource is a big performance  
problem for a WebDAV file system.

Jim Luther
Apple

On Jun 3, 2005, at 11:24 AM, Ted Hardie wrote:

>> The forward progress in the face of that strategy's failure has  
>> not been great.

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 6 Jun 2005 17:19:34 -0700

My recommendation for a future direction for the working group is:

* Move Bind and Quota to the IESG for consideration as Proposed Standards by
July 15. These specs. are essentially complete right now. 

* Work on completing 2518bis by December 31. Plan on shipping whatever
version of 2518bis exists as of early January, 2006. Issues that are
important, and pain-causing, will be addressed by then. Those that aren't as
important may or may not, depending on the willingness of the WG to address
them.
  - An important aspect of finishing 2518bis is adopting a process 
    for considering and resolving issues in a priority ordered and
    timely fashion.

* If work on 2518bis is going well, complete Redirect. Otherwise, encourage
work as an individual submission.

* Have the chairs be active in communicating current goals and progress to
the working group.

* In any event, have the WG close in early January 2006. Nine and a half
years is really enough :-)

I am willing and able to actively contribute to this effort in whatever way
is most helpful to the WG.

- Jim

---

From: John Baumgarten <[email-masked]>
Date: Fri, 24 Jun 2005 10:31:46 -0700

The server-side perspective from Apple is as follows:

1.  We often have weeks to implement a feature, so waiting months for  
an RFC is not practical.  That said, we're strong supporters of  
standards and endeavor to implement them as accurately as possible.   
When we have implemented a feature in a custom way, and a subsequent  
standard is released, we again endeavor to expose the feature also  
via the standard mechanism.

2.  We currently support a fairly complete and compliant ACL  
implementation that includes the 3744 framework.

3.  We find BIND overly complex for our needs and have implemented a  
much simpler linking mechanism that maps well onto the concept of  
iDisk ("rooted subtrees") ownership by paying customers that wish to  
share resources.  (Note our recent "family pack" offerings.)

4.  Investigation of Redirect is on our to-do list.

5.  We support a "ranged PUTs" custom extension, which seems to be  
adequate for out needs.  But would probably implement the PATCH  
mechanism if completed.

6.  We have abandoned DeltaV for now.

7.  Jim stated out position on Quota.

WebDAV and related protocols are and will continue to be essential to  
the .Mac service offerings.

JS "Jake" Baumgarten
.Mac Backend Server Engineering
Apple Computer

On Jun 3, 2005, at 2:16 PM, Jim Luther wrote:

> More useful would be support for Redirect resources which would  
> look like symlinks to file system clients. We've been asked to  
> support symlinks in the WebDAV file system many times.
>