> On Feb 19, 2015, at 5:59 PM, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
>
>
> {I've changed the subject}
>
> Yoav Nir <ynir.ietf@xxxxxxxxx> wrote:
>>> I'm very concerned about this part:
>>>
>>>> A key point in the protocol development process was the iteration the
>>>> working group did between protocol updates, and implementations and
>>>> testing. Certain draft protocol versions were labelled by the working
>>>> group as "implementation drafts", and the participants -- many web
>>>> browser and web server providers -- updated their implementations and
>>>> tested out the protocol changes. Most of the interim meetings
>>>> included part of a day spent on hands-on interoperability testing and
>>>> discussion. The result is a thoroughly validated protocol that has
>>>> been shown to interoperate and that meets the needs of many major
>>>> stakeholders.
>>>
>>> It sure seems to me like those "implementation drafts" are what used
>>> to be called proposed standards.
>
>> Proposed standards also have to go through working group last call, AD
>> review, IETF last call, IESG review, SecDir review, GenArt review, a
>> six-week waiting period in the RFC editor’s queue, and AUTH48. I don’t
>> think we can afford to do that for a single document every 4-6 months,
>> like httpbis did for HTTP/2.
>
> Thank you, you see to have found a list of things that we could "not do"
> prior to PS, and that would reduce a huge amount of work.
I think you expect implementors to work with documents that has had no review outside the working group, specifically no security review, no review about the use of SHOULD vs MUST, no thought necessarily given to interaction with other parts of the Internet technologies. Worst of all, drafts with not enough attention given to appropriate use of language and clarity. The HTTP/2 draft is very well-written, partially because all the authors speak very good English. This perhaps was the norm in the “good old days’, but it is often an exception today.
For the most part, intermediary drafts are good enough for implementers within the working group, but not so much for people outside the “inner circle”.
>>> What I see is a new step in the standardization process, along with a
>>> view that the step after internet-draft seems to include proven
>>> interoperability.
>
>> Running code has always been part of the deal, at least as something we
>> would like to have. Besides, the process continued even when some
>> implementations did not interoperate.
>
> Running code is usually the bar between PS and IS.
> Of course, we like running-code, and the earlier the better.
We’ve had running code and shipping products for RFC 4306/5995 long before Sean got the idea to advance them to full standard. The working group should be commended for producing a document that has some interoperating lab implementations, but that does not mean that it has proven itself well enough for Internet Standard. I’d like to see some real deployment and shipping products before that.
>>> I propose that this document skip PS, and go straight to Internet
>>> Standard to accurately reflect the status of this document.
>
>> There is currently pretty close to zero deployment in the real world. A
>> bunch of lab implementations that managed to interoperate in a bake-off
>> is not an indication of something ready for Internet Standard. But
>> don’t you agree that publishing a document with the bunch of lab
>> implementations is better than publishing it without them?
>
> Of course; I also worry that we are our own worst enemies: we raise the bar
> very high, and then we become overworked, and can't find superheroes that can
> do everything.
And yet we manage to produce many hundreds of RFCs a year.
Yoav