< draft-kolkman-proposed-standards-clarified-04.txt		draft-kolkman-proposed-standards-clarified-05.txt >
	Network Working Group O. Kolkman		Network Working Group O. Kolkman
	Internet-Draft NLnet Labs		Internet-Draft NLnet Labs
	Updates: 2026 (if approved) S. Bradner		Updates: 2026 (if approved) S. Bradner
	Intended status: Best Current Practice Harvard University		Intended status: Best Current Practice Harvard University
	Expires: April 18, 2014 S. Turner		Expires: May 02, 2014 S. Turner
	IECA, Inc.		IECA, Inc.
	October 17, 2013		October 31, 2013
	Characterization of Proposed Standards		Characterization of Proposed Standards
	draft-kolkman-proposed-standards-clarified-04		draft-kolkman-proposed-standards-clarified-05
	Abstract		Abstract
	RFC 2026 describes the review performed by the IESG on IETF Proposed		RFC 2026 describes the review performed by the IESG on IETF Proposed
	Standard RFCs and states the maturity level of those documents. This		Standard RFCs and characterizes the maturity level of those
	document clarifies those descriptions and updates RFC 2026 by		documents. This document updates RFC 2026 by providing a current and
	providing a new characterization of Proposed Standards.		more accurate characterization of Proposed Standards.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 18, 2014.		This Internet-Draft will expire on May 02, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (http://trustee.ietf.org/		Provisions Relating to IETF Documents (http://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. IETF Review of Proposed Standards . . . . . . . . . . . . . . 2		2. IETF Review of Proposed Standards . . . . . . . . . . . . . . 2
	3. Characterization of Specification . . . . . . . . . . . . . . 3		3. Characterization of Specifications . . . . . . . . . . . . . . 3
	3.1. Characterization of IETF Proposed Standard Specifications 3		3.1. Characterization of IETF Proposed Standard Specifications 3
	3.2. Characteristics of Internet Standards . . . . . . . . . . 4		3.2. Characteristics of Internet Standards . . . . . . . . . . 3
	4. Further Considerations . . . . . . . . . . . . . . . . . . . . 4		4. Further Considerations . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 4		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 4
	Appendix B. Internet Draft Notes and RFC Editor Instructions . . . 5		Appendix B. Internet Draft Notes and RFC Editor Instructions . . . 4
	Appendix B.1. Version 00 . . . . . . . . . . . . . . . . . . . 5		Appendix B.1. Version 00 . . . . . . . . . . . . . . . . . . . 5
	Appendix B.2. Version 00->01 . . . . . . . . . . . . . . . . . 6		Appendix B.2. Version 00->01 . . . . . . . . . . . . . . . . . 6
	Appendix B.3. Version 01->02 . . . . . . . . . . . . . . . . . 6		Appendix B.3. Version 01->02 . . . . . . . . . . . . . . . . . 6
	Appendix B.4. Version 02->03 . . . . . . . . . . . . . . . . . 6		Appendix B.4. Version 02->03 . . . . . . . . . . . . . . . . . 6
	Appendix B.5. Version 03->04 . . . . . . . . . . . . . . . . . 6		Appendix B.5. Version 03->04 . . . . . . . . . . . . . . . . . 6
	Appendix B.6. Editors versioning info . . . . . . . . . . . . . 6		Appendix B.6. Version 04->05 . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6		Appendix B.7. Editors versioning info . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	[Editor Note: ietf@ietf.org is the mailing-list for discussing this		[Editor Note: ietf@ietf.org is the mailing-list for discussing this
	draft.]		draft.]
	In the two decades after publication of RFC 2026 [RFC2026] the IETF		In the two decades after publication of RFC 2026 [RFC2026] the IETF
	has evolved its review processes of Proposed Standard RFCs and thus		has evolved its review processes of Proposed Standard RFCs and thus
	RFC 2026 section 4.1.1 no longer accurately describes IETF Proposed		RFC 2026 section 4.1.1 no longer accurately describes IETF Proposed
	Standards.		Standards.
	This document exclusively updates the characterization of Proposed		This document only updates the characterization of Proposed Standards
	Standards from RFC2026 Section 4.1.1 and does not speak to or alter		from RFC2026 Section 4.1.1 and does not speak to or alter the
	the procedures for the maintenance of Standards Track documents from		procedures for the maintenance of Standards Track documents from RFC
	RFC 2026 and RFC 6410 [RFC6410]. For complete understanding of the		2026 and RFC 6410 [RFC6410]. For complete understanding of the
	requirements for standardization those documents should be read in		requirements for standardization those documents should be read in
	conjunction with this document.		conjunction with this document.
	2. IETF Review of Proposed Standards		2. IETF Review of Proposed Standards
	The entry-level maturity for the standards track is "Proposed		The entry-level maturity for the standards track is "Proposed
	Standard". A specific action by the IESG is required to move a		Standard". A specific action by the IESG is required to move a
	specification onto the standards track at the "Proposed Standard"		specification onto the standards track at the "Proposed Standard"
	level.		level.
	Initially it was assumed that most IETF technical specifications		Initially it was intended that most IETF technical specifications
	would progress through a series of maturity stages starting with		would progress through a series of maturity stages starting with
	Proposed Standard, then progressing to Draft Standard then, finally,		Proposed Standard, then progressing to Draft Standard then, finally,
	to Internet Standard (see RFC 2026 section 6). Over time, for a		to Internet Standard (see RFC 2026 section 6). For a number of
	number of reasons, this progression became less common. In response,		reasons this progression is not common. Many Proposed Standards are
	the IETF strengthened its review of Proposed Standards, basically		actually deployed on the Internet and used extensively, as stable
	operating as if the Proposed Standard was the last chance for the		protocols. This proves the point that the community often deems it
	IETF to ensure the quality of the technology and the clarity of the		unnecessary to upgrade a specification to Internet Standard. Actual
	Standard Track document. The result was that IETF Proposed Standards		practice has been that full progression through the sequence of
	approved over the last decade or more have had extensive reviews.		standards levels is typically quite rare, and most popular IETF
	Because of this change in review assumptions, IETF Proposed Standards		protocols remain at Proposed Standard. Over time, the IETF has
	should be considered to be at least as mature as final standards from		developed a more extensive review process.
	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.
	3. Characterization of Specification		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.
	Section 3.1 of this document replaces RFC 2026 Section 4.1.1. Section		3. Characterization of Specifications
	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 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.
	3.1. Characterization of IETF Proposed Standard Specifications		3.1. Characterization of IETF Proposed Standard Specifications
	The entry-level maturity for the standards track is "Proposed		The entry-level maturity for the standards track is "Proposed
	Standard". A specific action by the IESG is required to move a		Standard". A specific action by the IESG is required to move a
	specification onto the standards track at the "Proposed Standard"		specification onto the standards track at the "Proposed Standard"
	level.		level.
	A Proposed Standard specification is stable, has resolved known		A Proposed Standard specification is stable, has resolved known
	design choices, is well-understood, has received significant		design choices and has received significant community review, and
	community review, and appears to enjoy enough community interest to		appears to enjoy enough community interest to be considered valuable.
	be considered valuable.
	Usually, neither implementation nor operational experience is		Usually, neither implementation nor operational experience is
	required for the designation of a specification as a Proposed		required for the designation of a specification as a Proposed
	Standard. However, such experience is highly desirable, and will		Standard. However, such experience is highly desirable, and will
	usually represent a strong argument in favor of a Proposed Standard		usually represent a strong argument in favor of a Proposed Standard
	designation.		designation.
	The IESG may require implementation and/or operational experience		The IESG may require implementation and/or operational experience
	prior to granting Proposed Standard status to a specification that		prior to granting Proposed Standard status to a specification that
	materially affects the core Internet protocols or that specifies		materially affects the core Internet protocols or that specifies
	skipping to change at page 4, line 14 ¶		skipping to change at page 4, line 4 ¶
	A Proposed Standard will have no known technical omissions with		A Proposed Standard will have no known technical omissions with
	respect to the requirements placed upon it. Proposed Standards are		respect to the requirements placed upon it. Proposed Standards are
	of such quality that implementations can be deployed in the Internet.		of such quality that implementations can be deployed in the Internet.
	However, as with all technical specifications, Proposed Standards may		However, as with all technical specifications, Proposed Standards may
	be revised if problems are found or better solutions are identified,		be revised if problems are found or better solutions are identified,
	when experiences with deploying implementations of such technologies		when experiences with deploying implementations of such technologies
	at scale is gathered.		at scale is gathered.
	3.2. Characteristics of Internet Standards		3.2. Characteristics of Internet Standards
	A specification for which significant implementation and successful		A specification for which significant implementation and successful
	operational experience has been obtained may be elevated to the		operational experience has been obtained may be elevated to the
	Internet Standard level. An Internet Standard (which may simply be		Internet Standard level. An Internet Standard (which may simply be
	referred to as a Standard) is characterized by a high degree of		referred to as a Standard) is characterized by a high degree of
	technical maturity and by a generally held belief that the specified		technical maturity and by a generally held belief that the specified
	protocol or service provides significant benefit to the Internet		protocol or service provides significant benefit to the Internet
	community.		community.
	4. Further Considerations		4. Further Considerations
	While less mature specifications will usually be published as		While less mature specifications will usually be published as
	Informational or Experimental RFCs, the IETF may, on occasion,		Informational or Experimental RFCs, the IETF may publish a Proposed
	publish a specification that still contains areas for improvement or		Standard that still contains areas for improvement or certain
	certain uncertainties about whether the best engineering choices are		uncertainties about whether the best engineering choices are made.
	made. In those cases that fact will be clearly and prominently		In those cases that fact will be clearly and prominently communicated
	communicated in the document e.g. in the abstract, the introduction,		in the document e.g. in the abstract, the introduction, or a
	or a separate section or statement.		separate section or statement.
	5. Security Considerations		5. Security Considerations
	This document does not directly affect the security of the Internet.		This document does not directly affect the security of the Internet.
	6. IANA Considerations		6. IANA Considerations
	There are no actions for IANA.		There are no actions for IANA.
	7. References		7. References
	skipping to change at page 4, line 56 ¶		skipping to change at page 4, line 45 ¶
	[RFC6410] Housley, R., Crocker, D. and E. Burger, "Reducing the		[RFC6410] Housley, R., Crocker, D. and E. Burger, "Reducing the
	Standards Track to Two Maturity Levels", BCP 9, RFC 6410,		Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
	October 2011.		October 2011.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	This document is inspired by a discussion at the open microphone		This document is inspired by a discussion at the open microphone
	session during the technical plenary at IETF 87. Thanks to, in		session during the technical plenary at IETF 87. Thanks to, in
	alphabetical order: Jari Arkko, Carsten Bormann, Scott Brim, Spencer		alphabetical order: Jari Arkko, Carsten Bormann, Scott Brim, Spencer
	Dawkins, Randy Bush, Benoit Claise, Dave Cridland, Adrian Farrel,		Dawkins, Randy Bush, Benoit Claise, Dave Cridland, Adrian Farrel,
	John Klensin, Subramanian Moonesamy for motivation, input, and		Stephen Farrel, Subramanian Moonesamy, and Pete Resnick for
	review.		motivation, input, and review.
			John Klensin and Dave Crocker have provided significant
			contributions.
	Appendix B. Internet Draft Notes and RFC Editor Instructions		Appendix B. Internet Draft Notes and RFC Editor Instructions
	This section is to assist reviewers of this document.		This section is to assist reviewers of this document.
	[Editor Note: Please remove this section and its subsections at		[Editor Note: Please remove this section and its subsections at
	publication]		publication]
	Appendix B.1. Version 00		Appendix B.1. Version 00
	skipping to change at page 6, line 50 ¶		skipping to change at page 6, line 48 ¶
	Changed a number of occurances where IESG review was used to the		Changed a number of occurances where IESG review was used to the
	intended IETF review.		intended IETF review.
	Appendix B.5. Version 03->04		Appendix B.5. Version 03->04
	s/In fact, the IETF review is more extensive than that done in most		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		other SDOs/The IETF review is possibly more extensive than that done
	in most other SDOs/		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		Minor spelling and style errors
	Appendix B.6. Editors versioning info		Appendix B.7. Editors versioning info
	$Id: draft-kolkman-proposed-standards-clarified.xml 16 2013-10-17		$Id: draft-kolkman-proposed-standards-clarified.xml 18 2013-10-31
	13:22:30Z olaf $		08:05:25Z olaf $
	Authors' Addresses		Authors' Addresses
	Olaf Kolkman		Olaf Kolkman
	Stichting NLnet Labs		Stichting NLnet Labs
	Science Park 400		Science Park 400
	Amsterdam, 1098 XH		Amsterdam, 1098 XH
	The Netherlands		The Netherlands
	Email: olaf@nlnetlabs.nl		Email: olaf@nlnetlabs.nl
	URI: http://www.nlnetlabs.nl/		URI: http://www.nlnetlabs.nl/
	Scott O. Bradner		Scott O. Bradner
	Harvard University Information Technology		Harvard University Information Technology
	Innovation and Architecture		Innovation and Architecture
	1350 Mass Ave., Room 760		1350 Mass Ave., Room 760
	Cambridge, MA 02138		Cambridge, MA 02138
	United States of America		United States of America
	Phone: +1 617 495 3864		Phone: +1 617 495 3864
	Email: sob@harvard.edu		Email: sob@harvard.edu
	URI: http://www.harvard.edu/huit		URI: http://www.harvard.edu/huit
End of changes. 23 change blocks.
	53 lines changed or deleted		147 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/