RFC 2026: BCP 9: The Internet Standards Process -- Revision 3
- S. Bradner
Best Current Practice
Network Working Group S. Bradner Request for Comments: 2026 Harvard University BCP: 9 October 1996 Obsoletes: 1602 Category: Best Current Practice The Internet Standards Process -- Revision 3 Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Abstract 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. Table of Contents 1. INTRODUCTION....................................................2 1.1 Internet Standards...........................................3 1.2 The Internet Standards Process...............................3 1.3 Organization of This Document................................5 2. INTERNET STANDARDS-RELATED PUBLICATIONS.........................5 2.1 Requests for Comments (RFCs).................................5 2.2 Internet-Drafts..............................................7 3. INTERNET STANDARD SPECIFICATIONS................................8 3.1 Technical Specification (TS).................................8 3.2 Applicability Statement (AS).................................8 3.3 Requirement Levels...........................................9 4. THE INTERNET STANDARDS TRACK...................................10 4.1 Standards Track Maturity Levels.............................11 4.1.1 Proposed Standard.......................................11 4.1.2 Draft Standard..........................................12 4.1.3 Internet Standard.......................................13 4.2 Non-Standards Track Maturity Levels.........................13 4.2.1 Experimental............................................13 4.2.2 Informational...........................................14 4.2.3 Procedures for Experimental and Informational RFCs......14 4.2.4 Historic................................................15 Bradner Best Current Practice [Page 1]
RFC 2026 Internet Standards Process October 1996 5. Best Current Practice (BCP) RFCs...............................15 5.1 BCP Review Process..........................................16 6. THE INTERNET STANDARDS PROCESS.................................17 6.1 Standards Actions...........................................17 6.1.1 Initiation of Action....................................17 6.1.2 IESG Review and Approval................................17 6.1.3 Publication.............................................18 6.2 Advancing in the Standards Track............................19 6.3 Revising a Standard.........................................20 6.4 Retiring a Standard.........................................20 6.5 Conflict Resolution and Appeals.............................21 6.5.1 Working Group Disputes...................................21 6.5.2 Process Failures.........................................22 6.5.3 Questions of Applicable Procedure........................22 6.5.4 Appeals Procedure........................................23 7. EXTERNAL STANDARDS AND SPECIFICATIONS..........................23 7.1 Use of External Specifications..............................24 7.1.1 Incorporation of an Open Standard.......................24 7.1.2 Incorporation of a Other Specifications.................24 7.1.3 Assumption..............................................25 8. NOTICES AND RECORD KEEPING......................................25 9. VARYING THE PROCESS.............................................26 9.1 The Variance Procedure.......................................26 9.2 Exclusions...................................................27 10. INTELLECTUAL PROPERTY RIGHTS..................................27 10.1. General Policy............................................27 10.2 Confidentiality Obligations...............................28 10.3. Rights and Permissions....................................28 10.3.1. All Contributions......................................28 10.3.2. Standards Track Documents..............................29 10.3.3 Determination of Reasonable and Non-discriminatory Terms................................30 10.4. Notices...................................................30 11. ACKNOWLEDGMENTS................................................32 12. SECURITY CONSIDERATIONS........................................32 13. REFERENCES.....................................................33 14. DEFINITIONS OF TERMS...........................................33 15. AUTHOR'S ADDRESS...............................................34 APPENDIX A: GLOSSARY OF ACRONYMS...................................35 Bradner Best Current Practice [Page 2]
RFC 2026 Internet Standards Process October 1996 1. INTRODUCTION This memo documents the process currently used by the Internet community for the standardization of protocols and procedures. The Internet Standards process is an activity of the Internet Society that is organized and managed on behalf of the Internet community by the Internet Architecture Board (IAB) and the Internet Engineering Steering Group (IESG). 1.1 Internet Standards The Internet, a loosely-organized international collaboration of autonomous, interconnected networks, supports host-to-host communication through voluntary adherence to open protocols and procedures defined by Internet Standards. There are also many isolated interconnected networks, which are not connected to the global Internet but use the Internet Standards. The Internet Standards Process described in this document is concerned with all protocols, procedures, and conventions that are used in or by the Internet, whether or not they are part of the TCP/IP protocol suite. In the case of protocols developed and/or standardized by non-Internet organizations, however, the Internet Standards Process normally applies to the application of the protocol or procedure in the Internet context, not to the specification of the protocol itself. In general, an Internet Standard is a specification that is stable and well-understood, is technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet. 1.2 The Internet Standards Process In outline, the process of creating an Internet Standard is straightforward: a specification undergoes a period of development and several iterations of review by the Internet community and revision based upon experience, is adopted as a Standard by the appropriate body (see below), and is published. In practice, the process is more complicated, due to (1) the difficulty of creating specifications of high technical quality; (2) the need to consider the interests of all of the affected parties; (3) the importance of establishing widespread community consensus; and (4) the difficulty of evaluating the utility of a particular specification for the Internet community. Bradner Best Current Practice [Page 3]
RFC 2026 Internet Standards Process October 1996 The goals of the Internet Standards Process are: o technical excellence; o prior implementation and testing; o clear, concise, and easily understood documentation; o openness and fairness; and o timeliness. The procedures described in this document are designed to be fair, open, and objective; to reflect existing (proven) practice; and to be flexible. o These procedures are intended to provide a fair, open, and objective basis for developing, evaluating, and adopting Internet Standards. They provide ample opportunity for participation and comment by all interested parties. At each stage of the standardization process, a specification is repeatedly discussed and its merits debated in open meetings and/or public electronic mailing lists, and it is made available for review via world-wide on-line directories. o These procedures are explicitly aimed at recognizing and adopting generally-accepted practices. Thus, a candidate specification must be implemented and tested for correct operation and interoperability by multiple independent parties and utilized in increasingly demanding environments, before it can be adopted as an Internet Standard. o These procedures provide a great deal of flexibility to adapt to the wide variety of circumstances that occur in the standardization process. Experience has shown this flexibility to be vital in achieving the goals listed above. The goal of technical competence, the requirement for prior implementation and testing, and the need to allow all interested parties to comment all require significant time and effort. On the other hand, today's rapid development of networking technology demands timely development of standards. The Internet Standards Process is intended to balance these conflicting goals. The process is believed to be as short and simple as possible without sacrificing technical excellence, thorough testing before adoption of a standard, or openness and fairness. From its inception, the Internet has been, and is expected to remain, an evolving system whose participants regularly factor new requirements and technology into its design and implementation. Users of the Internet and providers of the equipment, software, and services that support it should anticipate and embrace this evolution as a major tenet of Internet philosophy. Bradner Best Current Practice [Page 4]
RFC 2026 Internet Standards Process October 1996 The procedures described in this document are the result of a number of years of evolution, driven both by the needs of the growing and increasingly diverse Internet community, and by experience. Bradner Best Current Practice [Page 5]
RFC 2026 Internet Standards Process October 1996 1.3 Organization of This Document Section 2 describes the publications and archives of the Internet Standards Process. Section 3 describes the types of Internet standard specifications. Section 4 describes the Internet standards specifications track. Section 5 describes Best Current Practice RFCs. Section 6 describes the process and rules for Internet standardization. Section 7 specifies the way in which externally- sponsored specifications and practices, developed and controlled by other standards bodies or by others, are handled within the Internet Standards Process. Section 8 describes the requirements for notices and record keeping Section 9 defines a variance process to allow one-time exceptions to some of the requirements in this document Section 10 presents the rules that are required to protect intellectual property rights in the context of the development and use of Internet Standards. Section 11 includes acknowledgments of some of the people involved in creation of this document. Section 12 notes that security issues are not dealt with by this document. Section 13 contains a list of numbered references. Section 14 contains definitions of some of the terms used in this document. Section 15 lists the author's email and postal addresses. Appendix A contains a list of frequently-used acronyms. 2. INTERNET STANDARDS-RELATED PUBLICATIONS 2.1 Requests for Comments (RFCs) Each distinct version of an Internet standards-related specification is published as part of the "Request for Comments" (RFC) document series. This archival series is the official publication channel for Internet standards documents and other publications of the IESG, IAB, and Internet community. RFCs can be obtained from a number of Internet hosts using anonymous FTP, gopher, World Wide Web, and other Internet document-retrieval systems. The RFC series of documents on networking began in 1969 as part of the original ARPA wide-area networking (ARPANET) project (see Appendix A for glossary of acronyms). RFCs cover a wide range of topics in addition to Internet Standards, from early discussion of new research concepts to status memos about the Internet. RFC publication is the direct responsibility of the RFC Editor, under the general direction of the IAB. Bradner Best Current Practice [Page 6]
RFC 2026 Internet Standards Process October 1996 The rules for formatting and submitting an RFC are defined in [5]. Every RFC is available in ASCII text. Some RFCs are also available in other formats. The other versions of an RFC may contain material (such as diagrams and figures) that is not present in the ASCII version, and it may be formatted differently. ********************************************************* * * * A stricter requirement applies to standards-track * * specifications: the ASCII text version is the * * definitive reference, and therefore it must be a * * complete and accurate specification of the standard, * * including all necessary diagrams and illustrations. * * * ********************************************************* The status of Internet protocol and service specifications is summarized periodically in an RFC entitled "Internet Official Protocol Standards" [1]. This RFC shows the level of maturity and other helpful information for each Internet protocol or service specification (see section 3). Some RFCs document Internet Standards. These RFCs form the 'STD' subseries of the RFC series [4]. When a specification has been adopted as an Internet Standard, it is given the additional label "STDxxx", but it keeps its RFC number and its place in the RFC series. (see section 4.1.3) Some RFCs standardize the results of community deliberations about statements of principle or conclusions about what is the best way to perform some operations or IETF process function. These RFCs form the specification has been adopted as a BCP, it is given the additional label "BCPxxx", but it keeps its RFC number and its place in the RFC series. (see section 5) Not all specifications of protocols or services for the Internet should or will become Internet Standards or BCPs. Such non-standards track specifications are not subject to the rules for Internet standardization. Non-standards track specifications may be published directly as "Experimental" or "Informational" RFCs at the discretion of the RFC Editor in consultation with the IESG (see section 4.2). Bradner Best Current Practice [Page 7]
RFC 2026 Internet Standards Process October 1996 ******************************************************** * * * It is important to remember that not all RFCs * * are standards track documents, and that not all * * standards track documents reach the level of * * Internet Standard. In the same way, not all RFCs * * which describe current practices have been given * * the review and approval to become BCPs. See * * RFC-1796 [6] for further information. * * * ******************************************************** 2.2 Internet-Drafts During the development of a specification, draft versions of the document are made available for informal review and comment by placing them in the IETF's "Internet-Drafts" directory, which is replicated on a number of Internet hosts. This makes an evolving working document readily available to a wide audience, facilitating the process of review and revision. An Internet-Draft that is published as an RFC, or that has remained unchanged in the Internet-Drafts directory for more than six months without being recommended by the IESG for publication as an RFC, is simply removed from the Internet-Drafts directory. At any time, an Internet-Draft may be replaced by a more recent version of the same specification, restarting the six-month timeout period. An Internet-Draft is NOT a means of "publishing" a specification; specifications are published through the RFC mechanism described in the previous section. Internet-Drafts have no formal status, and are subject to change or removal at any time. ******************************************************** * * * Under no circumstances should an Internet-Draft * * be referenced by any paper, report, or Request- * * for-Proposal, nor should a vendor claim compliance * * with an Internet-Draft. * * * ******************************************************** Bradner Best Current Practice [Page 8]
RFC 2026 Internet Standards Process October 1996 Note: It is acceptable to reference a standards-track specification that may reasonably be expected to be published as an RFC using the phrase "Work in Progress" without referencing an Internet-Draft. This may also be done in a standards track document itself as long as the specification in which the reference is made would stand as a complete and understandable document with or without the reference to the "Work in Progress". 3. INTERNET STANDARD SPECIFICATIONS Specifications subject to the Internet Standards Process fall into one of two categories: Technical Specification (TS) and Applicability Statement (AS). 3.1 Technical Specification (TS) A Technical Specification is any description of a protocol, service, procedure, convention, or format. It may completely describe all of the relevant aspects of its subject, or it may leave one or more parameters or options unspecified. A TS may be completely self- contained, or it may incorporate material from other specifications by reference to other documents (which might or might not be Internet Standards). A TS shall include a statement of its scope and the general intent for its use (domain of applicability). Thus, a TS that is inherently specific to a particular context shall contain a statement to that effect. However, a TS does not specify requirements for its use within the Internet; these requirements, which depend on the particular context in which the TS is incorporated by different system configurations, are defined by an Applicability Statement.