]> Stichting NLnet Labs

Science Park 400 1098 XH Amsterdam The Netherlands olaf@nlnetlabs.nl http://www.nlnetlabs.nl/

Harvard University Information Technology

Innovation and Architecture 1350 Mass Ave., Room 760 Cambridge MA 02138 United States of America +1 617 495 3864 sob@harvard.edu http://www.harvard.edu/huit

IECA, Inc.

turners@ieca.com

RFC 2026 describes the review performed by the IESG on IETF Proposed Standard RFCs and states the maturity level of those documents. This document clarifies those descriptions and updates RFC 2026 by providing a new characterization of Proposed Standards.

[Editor Note: ietf@ietf.org is the mailing-list for discussing this draft.] In the two decades after publication of RFC 2026 the IETF has evolved its review processes of Proposed Standard RFCs and thus RFC 2026 section 4.1.1 no longer accurately describes IETF Proposed Standards. This document exclusively 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. For complete understanding of the requirements for standardization those documents should be read in conjunction with this document.

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. Initially it was assumed that most IETF technical specifications would progress through a series of maturity stages starting with Proposed Standard, then progressing to Draft Standard then, finally, to Internet Standard (see RFC 2026 section 6). 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. 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.

of this document replaces RFC 2026 Section 4.1.1. is a verbatim copy of the characterization of Internet Standards from RFC 2026 Section 4.1.3 and is provided for convenient reference.

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, is well-understood, 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, 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.

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.

While less mature specifications will usually be published as Informational or Experimental RFCs, the IETF may, on occasion, publish a specification 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.

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

There are no actions for IANA.

Harvard University

1350 Mass. Ave.CambridgeMA02138US+1 617 495 3864sob@harvard.edu

This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.

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

This section is to assist reviewers of this document. [Editor Note: Please remove this section and its subsections at publication]

Introduction and motivation Verbatim copy from section 4.1.1 and 4.1.3 of of the Proposed and ant Internet Draft characterization into and 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: 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.

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.

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.

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

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

$Id: draft-kolkman-proposed-standards-clarified.xml 16 2013-10-17 13:22:30Z olaf $