On Feb 19, 2015, at 5:59 PM, Michael Richardson
<mcr+ietf(_at_)sandelman(_dot_)ca> wrote:
{I've changed the subject}
Yoav Nir <ynir(_dot_)ietf(_at_)gmail(_dot_)com> 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