I don't think that anyone is claiming that the two-maturity-levels draft solves every problem. This draft should not discourage you or anyone else from offering additional proposals to solve the problems that you are mentioning in your email below. There are two problems that Russ's draft may very well solve: One issue with our current system is that there is no incentive to go from Proposed Standard to Draft Standard (since you are only going from one "intermediate state" short of full standard to another "intermediate state" also short of full standard). Another issue is that increasingly each of our standards relies on multiple other standards, so that RFCs can only move to Draft Standard if multiple other drafts do also, and it is too much trouble to move multiple drafts all at the same time. The downside of Russ's draft is that it is possible that after approving it we might find that nothing changes: Protocol specifications still stay at Proposed Standard; The IESG still takes a lot of time in approving a request to publish a proposed standard RFC. This possible downside seems to be a valid argument that people should continue to think about other improvements to the system (and send comments to nomcom on the candidates for IESG positions). However, this potential possible downside doesn't strike me as a reason to refuse to make the modest step in the right direction that IMHO is expressed in Russ's draft. Ross -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Scott O. Bradner Sent: Tuesday, October 26, 2010 12:09 PM To: ietf@xxxxxxxx Subject: what is the problem bis while we are the topic of problems Russ basically proposes too change the maturity warning label on IETF standard track RFCs -- remove baby before folding carriage -- this hardly seems like our biggest problem The IETF publishes a lot of standards track RFCs each year. Mostly these are PS (186 in 2009), some DS (3 in 2009), and some S (6 in 2009). SOME of these technologies are just what the community needs and just when the community needs them. But too many are 1/ too late for the market - implementations based on IDs deployed or other technologies adopted 2/ unneeded by the market - does not meet a need that people think they have 3/ broken - flawed in some way that prevents actual deployment 4/ too complex - hard and costly to correctly implement 5/ unmanageable - cannot be run by humans Seems to me that the issue of how the IETF can be better at producing just what the community needs just when the community needs it is more important than maturity warning labels. Scott _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf