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]
`
`Petitioner Apple Inc. - Ex. 1036, p. 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]
`
`Petitioner Apple Inc. - Ex. 1036, p. 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]
`
`Petitioner Apple Inc. - Ex. 1036, p. 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]
`
`Petitioner Apple Inc. - Ex. 1036, p. 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]
`
`Petitioner Apple Inc. - Ex. 1036, p. 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]
`
`Petitioner Apple Inc. - Ex. 1036, p. 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]
`
`Petitioner Apple Inc. - Ex. 1036, p. 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]
`
`Petitioner Apple Inc. - Ex. 1036, p. 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.
`
`3.2 Applicability Statement (AS)
`
` An Applicability Statement specifies how, and under what
` circumstances, one or more TSs may be applied to support a particular
` Internet capability. An AS may specify uses for TSs that are not
` Internet Standards, as discussed in Section 7.
`
` An AS identifies the relevant TSs and the specific way in which they
` are to be combined, and may also specify particular values or ranges
` of TS parameters or subfunctions of a TS protocol that must be
` implemented. An AS also specifies the circumstances in which the use
` of a particular TS is required, recommended, or elective (see section
` 3.3).
`
`Bradner Best Current Practice [Page 9]
`
`Petitioner Apple Inc. - Ex. 1036, p. 9
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` An AS may describe particular methods of using a TS in a restricted
` "domain of applicability", such as Internet routers, terminal
` servers, Internet systems that interface to Ethernets, or datagram-
` based database servers.
`
` The broadest type of AS is a comprehensive conformance specification,
` commonly called a "requirements document", for a particular class of
` Internet systems, such as Internet routers or Internet hosts.
`
` An AS may not have a higher maturity level in the standards track
` than any standards-track TS on which the AS relies (see section 4.1).
` For example, a TS at Draft Standard level may be referenced by an AS
` at the Proposed Standard or Draft Standard level, but not by an AS at
` the Standard level.
`
`3.3 Requirement Levels
`
` An AS shall apply one of the following "requirement levels" to each
` of the TSs to which it refers:
`
` (a) Required: Implementation of the referenced TS, as specified by
` the AS, is required to achieve minimal conformance. For example,
` IP and ICMP must be implemented by all Internet systems using the
` TCP/IP Protocol Suite.
`
` (b) Recommended: Implementation of the referenced TS is not
` required for minimal conformance, but experience and/or generally
` accepted technical wisdom suggest its desirability in the domain
` of applicability of the AS. Vendors are strongly encouraged to
` include the functions, features, and protocols of Recommended TSs
` in their products, and should omit them only if the omission is
` justified by some special circumstance. For example, the TELNET
` protocol should be implemented by all systems that would benefit
` from remote access.
`
` (c) Elective: Implementation of the referenced TS is optional
` within the domain of applicability of the AS; that is, the AS
` creates no explicit necessity to apply the TS. However, a
` particular vendor may decide to implement it, or a particular user
` may decide that it is a necessity in a specific environment. For
` example, the DECNET MIB could be seen as valuable in an
` environment where the DECNET protocol is used.
`
`Bradner Best Current Practice [Page 10]
`
`Petitioner Apple Inc. - Ex. 1036, p. 10
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` As noted in section 4.1, there are TSs that are not in the
` standards track or that have been retired from the standards
` track, and are therefore not required, recommended, or elective.
` Two additional "requirement level" designations are available for
` these TSs:
`
` (d) Limited Use: The TS is considered to be appropriate for use
` only in limited or unique circumstances. For example, the usage
` of a protocol with the "Experimental" designation should generally
` be limited to those actively involved with the experiment.
`
` (e) Not Recommended: A TS that is considered to be inappropriate
` for general use is labeled "Not Recommended". This may be because
` of its limited functionality, specialized nature, or historic
` status.
`
` Although TSs and ASs are conceptually separate, in practice a
` standards-track document may combine an AS and one or more related
` TSs. For example, Technical Specifications that are developed
` specifically and exclusively for some particular domain of
` applicability, e.g., for mail server hosts, often contain within a
` single specification all of the relevant AS and TS information. In
` such cases, no useful purpose would be served by deliberately
` distributing the information among several documents just to preserve
` the formal AS/TS distinction. However, a TS that is likely to apply
` to more than one domain of applicability should be developed in a
` modular fashion, to facilitate its incorporation by multiple ASs.
`
` The "Official Protocol Standards" RFC (STD1) lists a general
` requirement level for each TS, using the nomenclature defined in this
` section. This RFC is updated periodically. In many cases, more
` detailed descriptions of the requirement levels of particular
` protocols and of individual features of the protocols will be found
` in appropriate ASs.
`
`4. THE INTERNET STANDARDS TRACK
`
` Specifications that are intended to become Internet Standards evolve
` through a set of maturity levels known as the "standards track".
` These maturity levels -- "Proposed Standard", "Draft Standard", and
` "Standard" -- are defined and discussed in section 4.1. The way in
` which specifications move along the standards track is described in
` section 6.
`
` Even after a specification has been adopted as an Internet Standard,
` further evolution often occurs based on experience and the
` recognition of new requirements. The nomenclature and procedures of
` Internet standardization provide for the replacement of old Internet
`
`Bradner Best Current Practice [Page 11]
`
`Petitioner Apple Inc. - Ex. 1036, p. 11
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` Standards with new ones, and the assignment of descriptive labels to
` indicate the status of "retired" Internet Standards. A set of
` maturity levels is defined in section 4.2 to cover these and other
` specifications that are not considered to be on the standards track.
`
`4.1 Standards Track Maturity Levels
`
` Internet specifications go through stages of development, testing,
` and acceptance. Within the Internet Standards Process, these stages
` are formally labeled "maturity levels".
`
` This section describes the maturity levels and the expected
` characteristics of specifications at each level.
`
`4.1.1 Proposed Standard
`
` 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 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.
`
` 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 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.
`
`Bradner Best Current Practice [Page 12]
`
`Petitioner Apple Inc. - Ex. 1036, p. 12
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` 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.
`
`4.1.2 Draft Standard
`
` A specification from which at least two independent and interoperable
` implementations from different code bases have been developed, and
` for which sufficient successful operational experience has been
` obtained, may be elevated to the "Draft Standard" level. For the
` purposes of this section, "interoperable" means to be functionally
` equivalent or interchangeable components of the system or process in
` which they are used. If patented or otherwise controlled technology
` is required for implementation, the separate implementations must
` also have resulted from separate exercise of the licensing process.
` Elevation to Draft Standard is a major advance in status, indicating
` a strong belief that the specification is mature and will be useful.
`
` The requirement for at least two independent and interoperable
` implementations applies to all of the options and features of the
` specification. In cases in which one or more options or features
` have not been demonstrated in at least two interoperable
` implementations, the specification may advance to the Draft Standard
` level only if those options or features are removed.
`
` The Working Group chair is responsible for documenting the specific
` implementations which qualify the specification for Draft or Internet
` Standard status along with documentation about testing of the
` interoperation of these implementations. The documentation must
` include information about the support of each of the individual
` options and features. This documentation should be submitted to the
` Area Director with the protocol action request. (see Section 6)
`
` A Draft Standard must be well-understood and known to be quite
` stable, both in its semantics and as a basis for developing an
` implementation. A Draft Standard may still require additional or
` more widespread field experience, since it is possible for
` implementations based on Draft Standard specifications to demonstrate
` unforeseen behavior when subjected to large-scale use in production
` environments.
`
`Bradner Best Current Practice [Page 13]
`
`Petitioner Apple Inc. - Ex. 1036, p. 13
`
`

`

`
`RFC 2026 Internet Standards Process October 1996
`
` A Draft Standard is normally considered to be a final specification,
` and changes are likely to be made only to solve specific problems
` encountered. In most circumstances, it is reasonable for vendors to
` deploy implementations of Draft Standards into a disruption sensitive
` environment.
`
`4.1.3 Internet Standard
`
` 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.
`
` A specification that reaches the status of Standard is assigned a
` number in the STD series while retaining its RFC number.
`
`4.2 Non-Standards Track Maturity Levels
`
` Not every specification is on the standards track. A specification
` may not be intended to be an Internet Standard, or it may be inte