Re: Process on open RFC2518bis issues

Julian wrote on 01/09/2006 03:55:57 PM:

> Cullen Jennings wrote:

> > On all remaining 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 second Julian's question.  Revising a standard should be an inherently
conservative process.  Unless there is consensus that there is a bug, and
unless there is consensus on how to fix the bug, the standard should be 
left
alone.

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

I have seen no evidence that anyone has been acting in that fashion, and 
this
is the first I've heard even a suggestion that this has been taking place.
Given the amount of voluntary work that the principals have contributed to
achieving consensus, it is hard for me to take this accusation seriously.

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

I vigorously second Julian's disagreement.  Revising a standard is an 
inherently
disruptive process, since any substantive change is likely to break some 
existing
implementation that carefully implemented the first specification.  Unless 
there
is consensus for a change (which I believe there will be, for a serious 
problem
that needs to be fixed, and that has a fix), the original state of the 
spec should
always be maintained.

> > ... the idea that "if we can't agree, we use what
> > is in 2518" is not how consensus works. 

My response to that is "yes it is" (:-).

> > Like all WG drafts,  we can't come
> > to some form of consensus, it won't move forward.

I am baffled by this position.  We have dozens of significant issues that 
we
have achieved consensus, both that they are an issue, and what the fix 
should
be.   During this process, we have identified a very small number of 
issues
that either do not have consensus that they are a problem, or do not have
consensus on how to fix the problem.  That will always be the case, and I 
am
personally am pleasantly surprised by how few issues are in this category,
and applaud Julian/Lisa/Elias/Jim for achieving this.  Throwing all this 
work
away because we cannot artificially force consensus on a few remaining 
issues
seems like a less than ideal process.

Cheers,
Geoff