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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf