> On the Sec 3.2 point, I think Olaf is getting somewhere in his reply: make
> this the definitive source, which should eliminate the issue of duplication
> and also merge in the 6410 stuff. I'll work up text on the plane (en route
> to EWR now.
OK, so...
Here's what I suggest, which has us explicitly replacing all of the
definitions of Proposed Standard and Internet Standard from both 2026
and 6410. This leaves us with the new document being the definitive
place, and there's no duplication.
Abstract
OLD
RFC 2026 describes the review performed by the IESG on IETF Proposed
Standard RFCs and characterizes the maturity level of those
documents. This document updates RFC 2026 by providing a current and
more accurate characterization of Proposed Standards.
NEW
RFC 2026 describes the review performed by the IESG on IETF Standards
Track RFCs and characterizes the maturity level of those documents.
RFC 6410 updates those characterizations. This document updates RFCs
2026 and 6410 by providing a current and more accurate characterization
of Proposed Standard, and merging the changes made to Internet Standard
by RFC 6410.
END
1. Introduction
OLD
This document only updates the characterization of Proposed Standards
from RFC2026 Section 4.1.1 and does not speak to or alter the
procedures for the maintenance of Standards Track documents from RFC
2026 and RFC 6410 [RFC6410]. For complete understanding of the
requirements for standardization those documents should be read in
conjunction with this document.
NEW
This document only updates the characterization of Proposed Standards
from RFC2026 Section 4.1.1 and merges the changes made to RFC 2026
Section 4.1.3 by RFC 6410. While this document now provides a complete
current characterization of the Standards Track maturity levels, for a
complete understanding of the requirements for standardization it is
necessary to read RFCs 2026 and 6410 in conjunction with this document.
END
3. Characterization of Specifications
OLD
The text in the following section replaces RFC 2026 Section 4.1.1.
Section 3.2 is a verbatim copy of the characterization of Internet
Standards from RFC 2026 Section 4.1.3 and is provided for convenient
reference.
NEW
Internet specifications go through stages of development, testing,
and acceptance. Within the Internet Standards Process, there are
two stages, formally labeled "maturity levels" in the "Standards
Track". These maturity levels are "Proposed Standard" and
"Internet Standard".
This section describes the maturity levels and the expected
characteristics of specifications at each level. It replaces
Section 4.1 of RFC 2026, and its subsections, and Sections 2,
2.1, and 2.2 of RFC 6410.
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.
END
OLD
3.2. Characteristics of Internet Standards
A specification for which significant implementation and successful
operational experience has been obtained may be elevated to the
Internet Standard level. An Internet Standard (which may simply be
referred to as a 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.
NEW
3.2. Characterization of IETF Internet Standard Specifications
A specification for which significant implementation and successful
operational experience has been obtained may be elevated to the
Internet Standard level. An Internet Standard (which may simply be
referred to as a 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 IESG, in an IETF-wide Last Call of at least four weeks, confirms
that a document advances from Proposed Standard to Internet Standard.
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.
(4) If the technology required to implement the specification
requires patented or otherwise controlled technology, then the
set of implementations must demonstrate at least two independent,
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. If there is consensus for
reclassification, the RFC will be reclassified without publication of
a new RFC.
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. See
Section 6.1.2 of RFC 2026.
A specification that reaches the status of Standard is assigned a
number in the STD series while retaining its RFC number.
END
--
Barry