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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf