Re: draft-housley-two-maturity-levels

[Martin Rex <[e-mail]>]

James M. Polk wrote:
> 
> I'm not in love with the 3 maturity levels, especially when I was 
> asked by an AD during Maastricht to provide proof of 2 independent 
> implementations just to have an ID I was presenting be considered to 
> become a WG item.
> 
> That bar is just WAY too high.

Were you document author or WG chair?

I think that the problem is not about the maturity levels, but more
about the document maturity when processing it.

Making a document an official WG item can make any further changes
to the document extremely painful because of the formal "WG consensus"
prodecure, especially if there is bias in the system (AD, WG chair,
document editor or several of them have a personal interest).

When an I-D is still fairly immature, it makes sense to fill out
the white spaces with little bureaucratic overhead (and more author
discretion, and optionally counter-proposals), before formally
adopting the document as a WG item.

I'm not at all surprised that applying maintenance mode change control
at the prototyping stage significantly impairs the evolvement of
new proposals/documents/I-Ds.


Eric Burger wrote:
>
>       since Proposed Standard is the new Draft Standard, and since the
> IESG has to make sure any proposal is beyond bullet-proof, the industry
> has long since implemented draft-mumble-21, which has not changed for
> over a year, and few in industry cares if the document publishes as an
> RFC, because from their point of view, if something has been working in
> the field for three years, has 18 independent implementations, and has
> not yet crashed the Internet, it is probably ready, whether the IETF
> formally says so or not. That is the fast track to making the IETF
> irrelevant.


The only way to make non-trivial technical proposals bullet-proof
is to implement them!  Look at how many documents the IESG has to
review--it is simply possible for the IESG to make an interop
assessment and/or a proof-of-concept for a non-trivial technical I-D.

What they're probably looking at is
 - overall architectural issues touched by the I-D
 - clarity and consistency of the document (structure and language)
 - references to other standards


What worries *me* is why there are 18 independent implementations
of a draft, but none of the implementors has helped getting the
document ready for publication.  Getting the I-D finalized should
be more important for vendors than shipping implementations of it.
Unfortunately, it seems to be the other way round.  That is not
something the IETF can change, it is vendors which have to
change their attitude about participating the standardization
process if they have an interest in that technology.


-Martin