On Wed, Jul 27, 2011 at 07:02:07PM -0700, The IESG wrote: > The IESG has received a request from an individual submitter to consider > the following document: > - 'Reducing the Standards Track to Two Maturity Levels' > <draft-housley-two-maturity-levels-08.txt> as a BCP I have reviewed this version of the document and also the changes since -07. While i am not sure that there is really a problem to solve, the current version appears reasonable and an improvement over -07. However, it would benefit from a few clarifications before publication. Also, even if it will become part of BCP 9, i consider it a bit undesirable to distribute the core IETF standards process across more than one document. For the short term, that should be OK, though. > 1. Introduction > This document proposes several changes to the Internet Standards > Process defined in RFC 2026 [1]. In recent years, the Internet > Engineering Task Force (IETF) has witnessed difficulty in advancing > documents through the maturity levels: Proposed Standard, Draft > Standard, and finally Standard. These changes are designed to > simplify the Standards Process and reduce impediments to standards > progression while preserving the most important benefits of the IETF > engineering approach. In addition, the requirement for annual review > of standards-track documents that have not reached the top of the > maturity ladder is removed from the Internet Standards Process. this informal language is a nice read, but consistency with RFC 2026 would suggest to say "standards track" instead of "maturity ladder". > 2. Two Maturity Levels > This document, once approved, replaces the three-tier maturity ladder > defined in RFC 2026 [1] with a two-tier maturity ladder. > Specifications become Internet Standards through a set of two > maturity levels known as the "standards track". These maturity > levels are "Proposed Standard" and "Internet Standard". > A specification may be, and indeed, is likely to be, revised as it > advances from Proposed Standard to Internet Standard. When a revised > specification is proposed for advancement to Internet Standard, the > IESG shall determine the scope and significance of the changes to the > specification, and, if necessary and appropriate, modify the > recommended action. Minor revisions and the removal of unused > features are expected, but a significant revision may require that > the specification accumulate more experience at Proposed Standard > before progressing. Suggest to add a reference to section 6.1.1 of RFC 2026 to clarify that "recommended action" is actually the WG's request for advancement. > 2.2. The Second Maturity Level: Internet Standard > This maturity level is a merger of Draft Standard and Standard as > specified in RFC 2026 [1]. The chosen name avoids confusion between > "Draft Standard" and "Internet-Draft". > The characterization of an Internet Standard remains as described in > RFC 2026 [1], which says: > An Internet Standard is characterized by a high degree of > technical maturity and by a generally held belief that the > specified protocol or service provides significant benefit > to the Internet community. > The criteria for advancing from Proposed Standard to Internet > Standard are confirmed by the IESG in an IETF-wide Last Call of at > least four weeks. The request for reclassification is sent to the > IESG along with an explanation of how the criteria have been met. > The criteria are: > (1) There are at least two independent interoperating implementations > with widespread deployment and successful operational experience. > (2) There are no errata against the specification that would cause a > new implementation to fail to interoperate with deployed ones. > (3) There are no unused features in the specification that greatly > increase implementation complexity. Operational complexity should be of equal concern. > (4) If patented or otherwise controlled technology is required for > implementation, the implementations demonstrate at least two > separate and successful uses of the licensing process. > After review and consideration of significant errata, the IESG will > perform an IETF-wide Last Call of at least four weeks on the > requested reclassification. Is this another four weeks or the same as mentioned above? In case of the latter the first occurence could be removed to maintain chronological ordering. > requested reclassification. If there is consensus for > reclassification, the RFC will be reclassified without publication of > a new RFC. So, how would a modified specification (say, with unused features not passing criterion 3) be advanced? > As stated in RFC 2026 [1], in a timely fashion after the expiration > of the Last Call period, the IESG shall make its final determination > and notify the IETF of its decision via electronic mail to the IETF > Announce mailing list. No changes are made to Section 6.1.2 of RFC > 2026 [1]. Except for the extension of the LC period from two to four weeks, which is good - but makes this an ambiguous statement. > 2.3. Transition to a Standards Track with Two Maturity Levels > Any protocol or service that is currently at the Proposed Standard > maturity level remains so. > Any protocol or service that is currently at the Standard maturity > level shall be immediately reclassified as an Internet Standard. > Any protocol or service that is currently at the abandoned Draft > Standard maturity level will retain that classification, absent > explicit actions. Two possible actions are available: > (1) A Draft Standard may be reclassified as an Internet Standard as > soon as the criteria in Section 2.2 are satisfied. > (2) At any time after two years from the approval of this document as > a BCP, the IESG may choose to reclassify any Draft Standard > document as Proposed Standard. > 3. Removal of Requirement for Annual Review > In practice the annual review of Proposed Standard and Draft Standard > documents after two years called for in RFC 2026 [1] has not taken > place. Lack of this review has not revealed any ill effects on the > Internet Standards Process. As a result, the requirement for this > review is dropped. No review cycle is imposed on standards track > documents at any maturity level. I disagree with this analysis. Lack of review (for whatever reason) has lead to a perceived failure of the three-level standards track and thus _had_ an effect on the standards process. So, the reason to remove this requirement is to bring it in line with reality and to deal with the limited work force. -Peter _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf