wdiff rfc7127.original rfc7127.txt

Network Working Group
Internet Engineering Task Force (IETF) O. Kolkman
Internet-Draft
Request for Comments: 7127 NLnet Labs
Updates: 2026 (if approved)
BCP: 9 S. Bradner
Intended status:
Updates: 2026 Harvard University
Category: Best Current Practice Harvard University
Expires: May 06, 2014 S. Turner
ISSN: 2070-1721 IECA, Inc.
November 04, 2013
January 2014

Characterization of Proposed Standards
draft-kolkman-proposed-standards-clarified-06

Abstract

RFC 2026 describes the review performed by the IESG Internet Engineering
Steering Group (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.

Status of this This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working memo documents an Internet Best Current Practice.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It has been approved for publication by the Internet
Engineering Steering Group (IESG). Further information on BCPs is
available in Section 2 of RFC 5741.

Information about the current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 06, 2014.
http://www.rfc-editor.org/info/rfc7127.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info)
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IETF Review of Proposed Standards . . . . . . . . . . . . . . 2
3. Characterization of Specifications . . . . . . . . . . . . . . 3
3.1. Characterization of IETF Proposed Standard Specifications 3
3.2. Characteristics of Internet Standards . . . . . . . . . . 3 4
4. Further Considerations . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 4
Appendix B. Internet Draft Notes 5

1. Introduction

In the two decades after publication of RFC 2026 [RFC2026], the IETF
has evolved its review processes of Proposed Standard RFCs, and RFC Editor Instructions . . . 4
Appendix B.1. Version 00 . . . . . . . . . . . . . . . . . . . 4
Appendix B.2. Version 00->01 . . . . . . . . . . . . . . . . . 6
Appendix B.3. Version 01->02 . . . . . . . . . . . . . . . . . 6
Appendix B.4. Version 02->03 . . . . . . . . . . . . . . . . . 6
Appendix B.5. Version 03->04 . . . . . . . . . . . . . . . . . 6
Appendix B.6. Version 04->05 . . . . . . . . . . . . . . . . . 6
Appendix B.7. Version 05->06 . . . . . . . . . . . . . . . . . 8
Appendix B.8. Editors versioning info . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9

1. Introduction

[Editor Note: ietf@ietf.org is the mailing-list for discussing this
draft.]

In the two decades after publication of RFC 2026 [RFC2026] the IETF
has evolved its review processes of Proposed Standard RFCs and thus thus
Section 4.1.1 of RFC 2026 section 4.1.1 no longer accurately describes IETF
Proposed Standards.

This document only updates the characterization of Proposed Standards
from RFC2026 Section 4.1.1 of RFC 2026 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 standardization, those documents should be read in
conjunction with this document.

2. IETF Review of Proposed Standards

The entry-level maturity for the standards track is "Proposed
Standard". A specific action by the IESG is required to move a
specification onto the standards track Standards Track at the "Proposed Standard"
level.

Initially it was intended that most IETF technical specifications
would progress through a series of maturity stages starting with
Proposed Standard, then progressing to Draft Standard then, finally, Standard, then finally
to Internet Standard (see Section 6 of RFC 2026 section 6). 2026). For a number of
reasons this progression is not common. Many Proposed Standards are
actually deployed on the Internet and used extensively, as stable
protocols. This proves the point that the community often deems it
unnecessary to upgrade a specification to Internet Standard. Actual
practice has been that full progression through the sequence of
standards levels is typically quite rare, and most popular IETF
protocols remain at Proposed Standard. Over time, the IETF has
developed a more extensive review process.

IETF Proposed Standards documents have been subject to open
development and review by the Internet technical community, generally
including a number of formal cross-discipline reviews including, and,
specifically, a security review. This is further strengthened in
many cases by implementations and even the presence of interoperable
code. Hence Hence, IETF Proposed Standards are of such quality that they
are ready for the usual market-based product development and
deployment efforts into the Internet.

3. Characterization of Specifications

The text in the following section replaces RFC 2026 Section 4.1.1. 4.1.1 of RFC 2026.
Section 3.2 is a verbatim copy of the characterization of Internet
Standards from RFC 2026 Section 4.1.3 of RFC 2026 and is provided for
convenient reference. The text only provides the characterization, characterization;
process issues for Draft and Internet standards Standards are described in RFC2026 RFC
2026 and its updates, specifically RFC6410. RFC 6410.

3.1. Characterization of IETF Proposed Standard Specifications

The entry-level maturity for the standards track is "Proposed
Standard". A specific action by the IESG is required to move a
specification onto the standards track at the "Proposed Standard"
level.

A Proposed Standard specification is stable, has resolved known
design choices and choices, has received significant community review, and
appears to enjoy enough community interest to be considered valuable.

Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, desirable and will
usually represent a strong argument in favor of a Proposed Standard
designation.

The IESG may require implementation and/or operational experience
prior to granting Proposed Standard status to a specification that
materially affects the core Internet protocols or that specifies
behavior that may have significant operational impact on the
Internet.

A Proposed Standard will have no known technical omissions with
respect to the requirements placed upon it. Proposed Standards are
of such quality that implementations can be deployed in the Internet.
However, as with all technical specifications, Proposed Standards may
be revised if problems are found or better solutions are identified,
when experiences with deploying implementations of such technologies
at scale is gathered.

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.

4. Further Considerations

Occasionally

Occasionally, the IETF may choose to publish as Proposed Standard a
document that contains areas of known limitations or challenges. In
such cases cases, any known issues with the document will be clearly and
prominently communicated in the document, for example example, in the
abstract, the introduction, or a separate section or statement.

5. Security Considerations

This document does not directly affect the security of the Internet.

6. IANA Considerations

There are no actions for IANA.

7. Normative References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.

[RFC6410] Housley, R., Crocker, D. D., and E. Burger, "Reducing the
Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
October 2011.

Appendix A. Acknowledgements

This document is inspired by a discussion at the open microphone
session during the technical plenary at IETF 87. Thanks to, in
alphabetical order: order, Jari Arkko, Carsten Bormann, Scott Brim, Spencer
Dawkins, Randy
Bush, Benoit Claise, Dave Cridland, Spencer Dawkins, Adrian Farrel,
Stephen Farrel, Farrell, Subramanian Moonesamy, and Pete Resnick for
motivation, input, and review.

John Klensin and Dave Crocker have provided significant
contributions.

Appendix B. Internet Draft Notes and RFC Editor Instructions

This section is to assist reviewers of this document.

[Editor Note: Please remove this section and its subsections at
publication]

Appendix B.1. Version 00
Introduction and motivation

Verbatim copy from section 4.1.1 and 4.1.3 of [RFC2026] of the
Proposed and ant Internet Draft characterization into Section 3.1 and
Section 3.2

Modification of paragraphs of the Proposed Standards
characterization, namely:

OLD:

A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances.

NEW:

A Proposed Standard specification is stable, has resolved known
design choices, is well-understood, has received significant
community review, and appears to enjoy enough community interest to
be considered valuable. However, as with all technical standards,
further experience might result in a change or even retraction of the
specification in the future.

OLD:

A Proposed Standard should have no known technical omissions with
respect to the requirements placed upon it. However, the IESG may
waive this requirement in order to allow a specification to advance
to the Proposed Standard state when it is considered to be useful and
necessary (and timely) even with known technical omissions.

Implementors should treat Proposed Standards as immature
specifications. It is desirable to implement them in order to gain
experience and to validate, test, and clarify the specification.
However, since the content of Proposed Standards may be changed if
problems are found or better solutions are identified, deploying
implementations of such standards into a disruption-sensitive
environment is not recommended.

NEW:

Appendix B.2. Version 00->01

Added "Updates 2026" and added Sean's initial"

Copied the whole characterization paragraph for Internet Standards
from 2026, instead of only the line that is the actual
characterization itself.

Added the Further Consideration section based on discussion on the
mailinglist.

Appendix B.3. Version 01->02

Sharpened the 2nd paragraph of the Introduction to be clear that the
scope of the update is limited to section 4.1.1. and that this
document should not be read stand-alone.

Refined the "Further Considerations" Sections to express that as part
of the process less mature specs are sometimes approved as Proposed
Standards but that in those cases the documents should clearly
indicate that.

Minor editorial nits, and corrections.

Appendix B.4. Version 02->03

Changed a number of occurances where IESG review was used to the
intended IETF review.

Appendix B.5. Version 03->04

s/In fact, the IETF review is more extensive than that done in most
other SDOs/The IETF review is possibly more extensive than that done
in most other SDOs/

Minor spelling and style errors.

Appendix B.6. Version 04->05

Comments from the IESG are in: http://datatracker.ietf.org/doc/draft-
kolkman-proposed-standards-clarified/ballot/

Crocker's comment are in http://www.ietf.org/mail-archive/web/ietf/
current/msg83488.html

Refinement of the abstract text based on input by Dave Crocker and
Pete Resnick

In Section 2 Crocker suggested:

OLD:

Over time, for a number of reasons, this progression became less
common. In response, the IETF strengthened its review of Proposed
Standards, basically operating as if the Proposed Standard was the
last chance for the IETF to ensure the quality of the technology and
the clarity of the Standard Track document. The result was that IETF
Proposed Standards approved over the last decade or more have had
extensive reviews.

NEW:

For a number of reasons this progression is not common. Many
Proposed Standards are actually deployed on the Internet and used
extensively, as stable protocols. This proves the point that the
community often deems it unnecessary to upgrade a specification to
Internet Standard. Actual practice has been that full progression
through the sequence of standards levels is typically quite rare, and
most popular IETF protocols remain at Proposed Standard. Over time,
the IETF has developed a more extensive review process.

In the same section the comparisson with other SDOs triggered quite
some comments from the IESG. The following replacement was suggested
by Crocker, the reference to security review was based on the ballot
write-up by S. Farrel, the text also addresses Claise's point made in
his ballot write-up.

OLD:

Because of this change in review assumptions, IETF Proposed Standards
should be considered to be at least as mature as final standards from
other standards development organizations. The IETF review is
possibly more extensive than that done in most other SDOs owing to
the cross-area technical review performed by the IETF, exemplified by
technical review by the full IESG at the last stage of specification
development. That position is further strengthened by the common
presence of interoperable running code and implementation before
publication as a Proposed Standard.

NEW:

IETF Proposed Standards documents have been subject to open
development and review by the Internet technical community, generally
including a number of formal cross-discipline reviews including,
specifically, a security review. This is further strengthened in
many cases by implementations and even the presence of interoperable
code. Hence IETF Proposed Standards are of such quality that they
are ready for the usual market-based product development and
deployment efforts into the Internet.

In section Section 3.1:

OLD:

design choices, is well-understood, has received significant
NEW:

design choices and has received significant

RATIONALE: see Crocker's review.

In Section 4:

OLD:

the IETF may, on occasion, publish a specification that still
contains areas

NEW:

the IETF may publish a Proposed Standard that still contains

FURTHER:

Minor spelling and style errors

Appendix B.7. Version 05->06

OLD (in section Section 3:

NEW:

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. The text only provides the characterization, process
issues for Draft and Internet standards are described in RFC2028 and
its updates, specifically RFC6410.

OLD (in section Section 4:

While less mature specifications will usually be published as
Informational or Experimental RFCs, the IETF may publish a Proposed
Standard that still contains areas for improvement or certain
uncertainties about whether the best engineering choices are made.
In those cases that fact will be clearly and prominently communicated
in the document e.g. in the abstract, the introduction, or a
separate section or statement.

NEW:

Occasionally the IETF may choose to publish as Proposed Standard a
document that contains areas of known limitations or challenges. In
such cases any known issues with the document will be clearly and
prominently communicated in the document, for example in the
abstract, the introduction, or a separate section or statement.

Appendix B.8. Editors versioning info

$Id: draft-kolkman-proposed-standards-clarified.xml 21 2013-11-04
19:37:28Z olaf $

Authors' Addresses

Olaf Kolkman
Stichting NLnet Labs
Science Park 400
Amsterdam, 1098 XH
The Netherlands

Email: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl/

Scott O. Bradner
Harvard University Information Technology
Innovation

Authors' Addresses

Olaf Kolkman
Stichting NLnet Labs
Science Park 400
Amsterdam 1098 XH
The Netherlands

EMail: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl/

Scott O. Bradner
Harvard University Information Technology
Innovation and Architecture
1350 Mass Ave.,
8 Story St., Room 760 5014
Cambridge, MA 02138
United States of America

Phone: +1 617 495 3864
Email:
EMail: sob@harvard.edu
URI: http://www.harvard.edu/huit

Sean Turner
IECA, Inc.

Email:

EMail: turners@ieca.com