Subject: Process on open RFC2518bis issues

From: Julian Reschke <[email-masked]>
Date: Fri, 06 Jan 2006 11:15:59 +0100

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 have agreed upon in early December do not show up in draft 09 (mid 
December) and draft 10 (end December).

- We are spending a lot of time discussing questions that don't even 
have a corresponding entry 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.

- 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). 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), and to back out any text that normatively changes 
the protocol.

Best regards,

Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 6 Jan 2006 07:27:40 -0500

I agree with all of Julian's comments below.

Cheers,
Geoff

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 09 Jan 2006 12:17:35 -0800

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" <[email-masked]> 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

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

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Jan 2006 21:55:57 +0100

> 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#rfc.issue.bz188>).

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

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

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

OK, again two examples:

- The question of putting new requirements on ETags never was mentioned 
in that original WGLC.

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

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

> previous WGLC unless some issue is truly critical to get agreement on the

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.

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

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

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 10 Jan 2006 08:07:30 -0500

> > On all remaining issues, I do encourage people to think about if we 
really
> what people have implemented, why move to B? I'd really like to 

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.

> > 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
> > wants to move the draft forward. Clearly we are working on it as 
aupdate of

> 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

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

---

From: "Tyler Batory" <[email-masked]>
Date: Tue, 10 Jan 2006 11:26:33 -0500

stop sending me these emails please!!!!! I do not work here!!!!

thank you

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 10 Jan 2006 23:27:45 -0800

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" <[email-masked]> wrote:

>>> that
This was one of the ones I was thinking about that seemed to require changes
in many sections of the draft.

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

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

> RFC2518 never has been last-called, as far as I can tell.

My apologies - I was wrong here.

> - The question of putting new requirements on ETags never was mentioned

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

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

> it. And, as a matter of fact, we have managed to come to agreement about

At the time, I was concerned about infinite explosion of never ending
issues, but looking back on this, you are right that it helped.
> what people have implemented, why move to B? I'd really like to

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.  

>>> made

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.

> requirements for which there currently is no consensus is to re-consider

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.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Jan 2006 10:17:11 +0100

Cullen Jennings wrote:
> ...

Three sections, basically. And the complete diff is available, it just 
needs to be applied.

> ...

I think *that* summary makes a lot of sense. The problem is that this 
falls into the generic HTTP area. So adding non-normative text 
(appendix) explaining authoring scenarios may be a good idea, but 
forcing (!) servers to do things they potentially can't do won't work. 
In particular, requiring servers to do something where RFC2616 is silent 
about what it means is problematic, unless we can gather consensus for 
an RFC2616 erratum on the HTTP mailing list.

> request (set X=1, set X=3), the editor decides to clarify this corner case

They are not contradictory. RFC2518 is clear about what it means 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.2.p.3>):

"Instruction processing MUST occur in the order instructions are 
received (i.e., from top to bottom). Instructions MUST either all be 
executed or none executed."

> to resolve it. Presumably the editor will fix to reflect consensus on next

I sure hope so, but the whole roundtrip could have been avoided.

> ...

Well, I *urge* people who want to make normative changes to RFC2518 and 
who can't get consensus for these changes to reconsider that change 
requirement, and to consider to stick with the original protocol. 
Otherwise it will indeed be hard to agree on a common document.

> ...

 From a practical point of view, I think we need to ask implementors of 
RFC2518 if they're willing/able/planning to implement RFC2518bis. If we 
can't get positive feedback from those implementors who *are* still 
active (so I'll explicitly exclude the Microsoft IIS developers here 
:-), then I think we have a problem.

> really do agree - we need to be trying to shrink no grow the scope of the

And that's why I was basically asking for a Feature Freeze.

Best regards, Julian

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Jan 2006 02:10:36 -0800

On 1/11/06 1:17 AM, "Julian Reschke" <[email-masked]> wrote:

>>> http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html
>>> #r
>>> fc.issue.bz188>).

Here you are pointing out why a particular solution can't be done by this WG
- but that does not seem to be a requirement issues.

> executed or none executed."

RFC2518 is clear about how to resolve this, but X=1 and X=3 are
contradictory statements by any reasonable definition of contradictory. Now
I'm not taking any position on we should allow this or should not, or
reasons we may or may not want it. The WG can figure that out. But I will
say that I don't think it was unreasonable for someone to think that we
might want to say not to do this and propose text to say that. It's also not
unreasonable to think that it was not be a big deal requiring significant
discussion. This turned out to be wrong but it was not unreasonable,
incompetent, or malicious.

> I sure hope so, but the whole roundtrip could have been avoided.

I'm not sure how it could have been avoided - If the solution is that Lisa
write some draft text and propose it to the email list to see if it is OK,
well, that is isomorphic to what happened.

> :-), then I think we have a problem.

Definitely. In the end this is what counts. Similarly if people think that
2518bis is not an improvement on 2518, then we are pretty unlikely to have
consensus on it. 

> And that's why I was basically asking for a Feature Freeze.

I think that Feature Freeze really is you key point you were trying to get
at all along and I encourage that. I separate that from a process problem.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 11 Jan 2006 08:08:25 -0500

> contradictory statements by any reasonable definition of contradictory.

No, they are not contradictory.  The user first set X=1, and then
set X=3.  It might be necessary to satisfy server constraints that
X first take on value 1 and then value 3 (for example, X cannot never
be increased by more than 2 by any particular request).  As Julian
says, RFC2518 makes it clear what a server must do in this case,
so it is not contradictory, undefined, or unclear.

> Now

I don't think anyone was suggesting this was malicious, but that at this
stage to make a normative change to the draft on a topic that has not even
been discussed on the mailing list wastes time that we don't have to 
waste.

> well, that is isomorphic to what happened.

Finding an unannounced change to the draft text takes a lot more time than 

responding to an email message.

> >> consensus on A.

Not in the limited amount of time we have available to us, since many of 
the
implementors can only participate at infrequent intervals, and since the 
current
full-time participants do not have time to run every suggested normative 
change against all existing implementations.

> >>> So in this case, it would be nice if those who push for new

> >> really do agree - we need to be trying to shrink not grow the scope 
of the
> >> work. 

Julian was suggesting what I believe is the only effective approach to
resolving the last few blocking issues in the time available to us.
So I continue to support his proposal that in this final stage,
if there are any remaining proposed changes to RFC2518 that do
not have consensus, that they be dropped for consideration
for RFC2518bis (without further discussion). 

The reason I believe that what is in (or not in) RFC2518 should by default
be preferred over some suggested change to RFC2518 is that RFC2518
was the result of years of discussion and consensus-building by a very
active working group, and that without compelling evidence to the 
contrary,
it is reasonable to assume that implementors implemented what was in
RFC2518, and implemented in idiosyncratic ways anything that was not 
defined
by RFC2518.  So any change to RFC2518 (including the addition of 
constraints
that were not previously there) are likely to break at least some
implementations, and therefore any change to RFC2518 should by
default be rejected unless there is at least consensus amoung the current
group of active participants that the change is needed and is an 
improvement.

Cheers,
Geoff

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Jan 2006 08:36:08 -0800

Somehow, we continue to seem to miscommunication - perhaps we are saying the
same thing

On 1/11/06 5:08 AM, "Geoffrey M Clemm" <[email-masked]> wrote:

>  and therefore any change to RFC2518 should by
> default be rejected unless there is at least consensus

Let me comment on this in the simplest form I can.

If bis is includes change A, yes we will need consensus for that change.

If many people think that bis should include some other change X to clarify
a problem/confusion seen with 2518 but bis does not include that, we will
need consensus that bis does not include X.

We need consensus on the document. Now to get to consensus, yes I encourage
the WG not to add new features, and not to be shy about removing features
that don't work.

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 11 Jan 2006 12:03:52 -0500

I don't think there is any communication problem,
I believe we just disagree on the appropriate way to resolve
the remaining disagreements in a limited time.

One way to do so is to play a game of "chicken" ...
set up the situation in which unless one party to each
disagreement gives in by the specified time, something
severely negative results (e.g. all the work on 2518bis
is wasted and no revision of 2518 is published).

Another way to achieve agreement is to instantiate a rule
that depends only on the facts of the issue, and not on the
personalities of the participants.

I believe Julian has proposed a sensible rule for this
situation that will produce a superior result (and be less
stressful on the participants) than would the game of chicken.

Cheers,
Geoff

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 13 Jan 2006 12:07:56 -0800

Unfortunately, this proposal would violate that idea that a WG needs to
determine that at least rough consensus exists within the WG for the
advancement of a document. It would change to where there was not consensus,
then we defaulted to what RFC 2518 says.

On 1/11/06 9:03 AM, "Geoffrey M Clemm" <[email-masked]> wrote:

>> > Somehow, we continue to seem to miscommunication - perhaps we are saying >>
the

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Jan 2006 21:15:07 +0100

Cullen Jennings wrote:
> advancement of a document. It would change to where there was not 
> consensus, then we defaulted to what RFC 2518 says.
> ...

Indeed. As a matter of fact that was my understanding about how revising 
an standards track document should work. If there's no consensus for a 
change, don't do it.

The question then is whether the agreed upon changes represent 
sufficient advance over the previous spec to make publishing it worthwhile.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 13 Jan 2006 15:39:48 -0500

I agree with Julian.  What needs consensus is that a given draft
should be published.  The approach one uses to reach such a draft
can vary greatly.  Getting working group consensus on every issue
is one approach to producing a draft, but it is not the only approach,
is not always the best approach, and sometimes is not even a feasible
approach in the presence of time constraints.

Cheers,
Geoff