Re: Process on open RFC2518bis issues

I think there is a lot in this that we agree on but a few points worth
reading. More inline...

On 1/9/06 12:55 PM, "Julian Reschke" <julian.reschke@gmx.de> wrote:

> Cullen Jennings wrote:
>> 
>> I marked this email important. I think folks should read it and think about
>> how are we going to get to agreement on 2518bis.
>> 
>> Thank you, Cullen with my WG Chair hat on. Now on to the message ....
>> 
>> 
>> On 1/6/06 2:15 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
>> 
>>> Hi,
>>> 
>>> here's a comment on how I see the working group's process, understanding
>>> that
>>> there are only a few weeks left allocated for completion.
>>> 
>>> - The drafts that the WG publish lag behind; for instance, changes that we
>>> Just to make sure there is no confusion on the "we" for people reading this,
>>> that is the "we" of the group of people joing the conference calls not WG
>>> consensus. have agreed upon in early December do not show up in draft 09
>>> (mid
>>> December) and draft 10 (end December).
>>> 
>> 
>> I may be very confused but my read of the drafts brought me to the following
>> conclusion .... When rev 10  of 2518bis was published, it incorporated all
>> but a few of the the changes we had come to a proposal on. The ones that had
>> not been included require significant work to make changes throughout the
>> document. There had been no proposed diffs that could have been quickly
>> incorporated for all of these.
> 
> OK, let me point to two specific ones:
> 
> Bug 188 (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188>),
> agreed upon on 2005-12-07
> (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=188#c2>),
> proposed text is in
> http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#r
> fc.issue.bz188>).
This was one of the ones I was thinking about that seemed to require changes
in many sections of the draft.

> 
> Bug 48 (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48>),
> agreement on 2005-12-12 by some of us, no other feedback, proposed text
> in 
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#
> rfc.issue.bz048> 
> and in <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=48#c5>.
Uh, I not sure on this one but I thought we assigned this to Lisa after rev
10 was out.

> 
>> I have been encouraging a "publish early, publish often" approach to this
>> draft. It still seem to me that are bottleneck is coming to agreement about
>> what we want the draft to say, not getting the text into the draft. If I'm
>> totally missing the situation here, please do enlighten me.
> 
> I'm not sure about which one is the bottleneck, but it certainly would
> be good to have those things in the spec that there was consensus for.

Agree - but my take of it is that we have been doing a pretty good job of
that so far.

> 
>>> - We are spending a lot of time discussing questions that don't even have a
>>> corresponding entry in the issue tracker. Really, I have was not aware of
>>> this
>>> - I don't think this actually is the case. Next time we get onto one of
>>> these
>>> on the conference call, please bring it to my attention and I will instantly
>>> get us focused back on the items in the issue tracker.
>>> 
>>> I would propose that for the time being, we restrict all discussions and
>>> changes to (1) issues that have been entered before today and (2) problems
>>> with changes in RFC2518bis as compared to RFC2518. For the working group to
>>> consider any other question relevant enough for RFC2518bis, there should be
>>> a
>>> broad consensus to discuss it in the given time frame.
>>> 
>> 
>> We are trying to focus on issues that we need to agree on to get WG
>> consensus that the WG wants to publish the document as an RFC. I think
>> that pretty much all the relevant ones came up before or during the previous
>> WGLC. Now in resolving these, some times they have been further broken in to
> 
> I'll assume that by WGLC you mean RFC2518's working group last call.
> RFC2518 never has been last-called, as far as I can tell.

My apologies - I was wrong here.

> 
> OK, again two examples:
> 
> - The question of putting new requirements on ETags never was mentioned
> in that original WGLC.

It's very clear that the meaning of strong and weak ETags and how to
implement them and what clients can rely on has been unclear to many, if not
all, people for a long time. I'm not trying to put new requirements on
ETags, I am trying to get ETags to a point where the WG agrees that
1) they are useful for clients
2) it is clear how clients can use them
3) and it is clear enough what they need to do that servers will implement
them correctly

> 
> - The proposal to change the semantics for PROPPATCH (new issue 210,
> <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=210>) as far as
> I can tell, even never have been raised *anywhere* until it suddenly
> showed up in a recent draft -- and that's exactly the kind of change
> discussion I'd like to avoid at this stage.
> 

Oddly, I view this as an example where I pretty happy with how things went.
The editor of the document is writing down the details and considers the
corner case where a client sent two contradictory statements in the same
request (set X=1, set X=3), the editor decides to clarify this corner case
and puts in text suggesting that a client should not sent that. The draft
gets published, some people read it and realize there may be reasons that a
client does want to do that. Some quick discussion ensues and we decide how
to resolve it. Presumably the editor will fix to reflect consensus on next
draft.  

> 
>> more issues in the bug tracker - I was not overly keen about this but it did
>> seem the best way to use the tool to help accelerate the work.
> 
> I think that was the right thing to do. If eight issues about locking
> are summarized under one single entry, it becomes very hard to control
> it. And, as a matter of fact, we have managed to come to agreement about
> all of these, I think.

At the time, I was concerned about infinite explosion of never ending
issues, but looking back on this, you are right that it helped.
> 
>> On all reaming issues, I do encourage people to think about if we really
>> have to resolve issues X in form A or B or if they could live with either A
>> or B. I would like to see focus on issues that came up during or before the
>> previous WGLC unless some issue is truly critical to get agreement on the
>> draft. 
> 
> Yes. But if A and B are acceptable, and A was in RFC2518 and this is
> what people have implemented, why move to B? I'd really like to
> understand that.

I think you are missing my point on this one - If A and B are acceptable,
and A is what people have implemented, I'm sure the WG would come to
consensus on A. However, if neither A or B have consensus, then we don't
have consensus. And if we don't have consensus, then we don't have consensus
regardless of if the previous RFC did A,B, something else, or nothing at
all.  

> 
>>> - There are a few issues that obviously are "hard", and where we haven't
>>> made
>>> any progress in the last few weeks. A good example is the discussion about
>>> new
>>> requirements for ETag handling (which is a normative change compared to
>>> RFC2518).
>>> 
>> 
>> Some people have tried to game the system the and are assuming that anything
>> we 
>> could not agree upon would stay the same as 2518 so if they like the text in
>> 2518, they just make sure no one every comes to agreement on the topic. This
>> won't work - the problem is that the WG needs to come to consensus that it
>> wants to move the draft forward. Clearly we are working on it as a update of
>> 2518 but if half the group things we change ETags and half things we should
>> not, I am going to have to decide if we have consensus or not and
>> unfortunately I will have to say half wants A and half wants B so no
>> consensus. The fact that 2518 had A instead of B might influence which
>> people want A or B but it does not influence my role of having to point out
>> that half want A and half want B.
> 
> I think I clearly disagree here. If half of the people thinks the
> original requirements (A) are just fine, and the other half wants to add
> new requirements (B), going for (B) creates a spec that half of the
> people aren't happy with and may not implement. Sticking with (A) on the
> other hand means that we can go on as before, and those in favor of (B)
> still have the freedom to come up with a way to describe (B), and let
> clients discover that. Yes, that's a profile. Yes, I'm aware that
> profiles should be avoided. But if the cost of not having the profíle is
> that half of the implementors will either not implement the spec, and
> implement it incorrectly (claiming compliance when they don't), that's
> not better.

Yes, and in that case you need to get consensus that going with A is the
best path. I'm not disagree with you about why you might use the above
argument in favor of A - that is fine, it is appropriate to make, and the WG
might agree or disagree. But in the end I have to try and figure out if we
have consensus for A, B, or no consensus. Lack of consensus for B will not
imply a consensus for A. Only consensus for A will imply a consensus for A.

> 
>>> Unless somebody can explain why it's likely that we can resolve these issues
>>> between now and the end of the month, I propose to stop the discussion for
>>> now
>>> (as far as it affects RFC2518bis),
>>> 
>> 
>> Back in December I asked the people on the conference calls if we were going
>> to be able to come to consensus on these issues. No one could guarantee
>> anything but they all felt we could. Based on that, Ted decided to keep the
>> working group open beyond the 2005. I sincerely hope we can come to
>> consensus on these hard issues. However, I encourage people to come to
>> agreement on something we can all live with - if that happens to be the same
>> as what is in 2518, fine, but the idea that "if we can't agree, we use what
>> is in 2518" is not how consensus works. Like all WG drafts,  we can't come
>> to some form of consensus, it won't move forward.
> 
> Understood. So in this case, it would be nice if those who push for new
> requirements for which there currently is no consensus is to re-consider
> this.

Yes, I agree. Perhaps I should say this in all caps or something but I
really do agree - we need to be trying to shrink no grow the scope of the
work. 

> 
> Best regards, Julian
> 
>

Received on Wednesday, 11 January 2006 07:27:39 UTC