Re: Process on open RFC2518bis issues

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.

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.

> - 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
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.

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. 

> 
> - 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.


> 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.


> and to back out any text that normatively changes the protocol.
> 
> Best regards,
> 
> Julian

Received on Monday, 9 January 2006 20:17:54 UTC