Network Working Group
`Request for Comments: 2026
`BCP: 9
`Obsoletes: 1602
`Category: Best Current Practice
`
`S. Bradner
`Harvard University
`October 1996
`
`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 (cid:9)
`1.1 Internet Standards (cid:9)
`1.2 The Internet Standards Process (cid:9)
`1.3 Organization of This Document (cid:9)
`2. INTERNET STANDARDS-RELATED PUBLICATIONS (cid:9)
`2.1 Requests for Comments (RFCs) (cid:9)
`2.2 Internet-Drafts (cid:9)
`3. INTERNET STANDARD SPECIFICATIONS (cid:9)
`3.1 Technical Specification (TS) (cid:9)
`3.2 Applicability Statement (AS) (cid:9)
`3.3 Requirement Levels (cid:9)
`4. THE INTERNET STANDARDS TRACK (cid:9)
`4.1 Standards Track Maturity Levels (cid:9)
`4.1.1 Proposed Standard (cid:9)
`4.1.2 Draft Standard (cid:9)
`4.1.3 Internet Standard (cid:9)
`4.2 Non-Standards Track Maturity Levels (cid:9)
`4.2.1 Experimental (cid:9)
`4.2.2 Informational (cid:9)
`4.2.3 Procedures for Experimental and Informational RFCs (cid:9)
`4.2.4 Historic (cid:9)
`
`2
`3
`3
`5
`5
`5
`7
`8
`8
`8
`9
`10
`11
`11
`12
`13
`13
`13
`14
`14
`15
`
`Bradner
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 1]
`
`Internet Standards Process (cid:9)
`
`October 1996
`
`5. Best Current Practice (BCP) RFCs (cid:9)
`5.1 BCP Review Process (cid:9)
`
`15
`16
`
`NOAC Ex. 1054 Page 1
`
`(cid:9)
`(cid:9)
`

`

`6. THE INTERNET STANDARDS PROCESS (cid:9)
`6.1 Standards Actions (cid:9)
`6.1.1 Initiation of Action (cid:9)
`6.1.2 IESG Review and Approval (cid:9)
`6.1.3 Publication (cid:9)
`6.2 Advancing in the Standards Track (cid:9)
`6.3 Revising a Standard (cid:9)
`6.4 Retiring a Standard (cid:9)
`6.5 Conflict Resolution and Appeals (cid:9)
`6.5.1 Working Group Disputes (cid:9)
`6.5.2 Process Failures (cid:9)
`6.5.3 Questions of Applicable Procedure (cid:9)
`6.5.4 Appeals Procedure (cid:9)
`7. EXTERNAL STANDARDS AND SPECIFICATIONS (cid:9)
`7.1 Use of External Specifications (cid:9)
`7.1.1 Incorporation of an Open Standard (cid:9)
`7.1.2 Incorporation of a Other Specifications (cid:9)
`7.1.3 Assumption (cid:9)
`8. NOTICES AND RECORD KEEPING (cid:9)
`9. VARYING THE PROCESS (cid:9)
`9.1 The Variance Procedure (cid:9)
`9.2 Exclusions (cid:9)
`10. INTELLECTUAL PROPERTY RIGHTS (cid:9)
`10.1. General Policy (cid:9)
`10.2 Confidentiality Obligations (cid:9)
`10.3. Rights and Permissions (cid:9)
`10.3.1. All Contributions (cid:9)
`10.3.2. Standards Track Documents (cid:9)
`10.3.3 Determination of Reasonable and
`Non-discriminatory Terms (cid:9)
`10.4. Notices (cid:9)
`11. ACKNOWLEDGMENTS (cid:9)
`12. SECURITY CONSIDERATIONS (cid:9)
`13. REFERENCES (cid:9)
`14. DEFINITIONS OF TERMS (cid:9)
`15. AUTHOR'S ADDRESS (cid:9)
`APPENDIX A: GLOSSARY OF ACRONYMS (cid:9)
`
`17
`17
`17
`17
`18
`19
`20
`20
`21
`21
`22
`22
`23
`23
`24
`24
`24
`25
`25
`26
`26
`27
`27
`27
`28
`28
`28
`29
`
`30
`30
`32
`32
`33
`33
`34
`35
`
`Bradner
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 2]
`
`Internet Standards Process (cid:9)
`
`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
`
`NOAC Ex. 1054 Page 2
`
`(cid:9)
`(cid:9)
`

`

`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
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 3]
`
`Internet Standards Process (cid:9)
`
`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.
`
`NOAC Ex. 1054 Page 3
`
`(cid:9)
`(cid:9)
`

`

`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
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 4]
`
`Internet Standards Process (cid:9)
`
`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.
`
`NOAC Ex. 1054 Page 4
`
`(cid:9)
`(cid:9)
`

`

`Bradner (cid:9)
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 5]
`
`Internet Standards Process (cid:9)
`
`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
`
`NOAC Ex. 1054 Page 5
`
`(cid:9)
`

`

`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
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 6]
`
`Internet Standards Process (cid:9)
`
`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 (cid:9)
`*
`* specifications: the ASCII text version is the (cid:9)
`*
`* definitive reference, and therefore it must be a (cid:9)
`* 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).
`
`NOAC Ex. 1054 Page 6
`
`(cid:9)
`(cid:9)
`

`

`Bradner (cid:9)
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 7]
`
`Internet Standards Process (cid:9)
`
`October 1996
`
`********************************************************
`*
`*
`*
`* It is important to remember that not all RFCs (cid:9)
`*
`* are standards track documents, and that not all (cid:9)
`*
`* standards track documents reach the level of (cid:9)
`*
`* Internet Standard. In the same way, not all RFCs (cid:9)
`*
`* which describe current practices have been given (cid:9)
`*
`* the review and approval to become BCPs. See (cid:9)
`* RFC-1796 [6] for further information. (cid:9)
`*
`*
`*
`********************************************************
`
`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 (cid:9)
`*
`* be referenced by any paper, report, or Request- (cid:9)
`* for-Proposal, nor should a vendor claim compliance *
`*
`* with an Internet-Draft. (cid:9)
`*
`*
`********************************************************
`
`Bradner
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 8]
`
`Internet Standards Process (cid:9)
`
`October 1996
`
`NOAC Ex. 1054 Page 7
`
`(cid:9)
`(cid:9)
`(cid:9)
`

`

`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
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 9]
`
`Internet Standards Process (cid:9)
`
`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.
`
`NOAC Ex. 1054 Page 8
`
`(cid:9)
`(cid:9)
`

`

`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
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 10]
`
`Internet Standards Process (cid:9)
`
`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
`
`NOAC Ex. 1054 Page 9
`
`(cid:9)
`(cid:9)
`

`

`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
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 11]
`
`Internet Standards Process (cid:9)
`
`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.
`
`NOAC Ex. 1054 Page 10
`
`(cid:9)
`(cid:9)
`

`

`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
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 12]
`
`Internet Standards Process (cid:9)
`
`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)
`
`NOAC Ex. 1054 Page 11
`
`(cid:9)
`(cid:9)
`

`

`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 (cid:9)
`
`[Page 13]
`
`RFC 2026
`
`Internet Standards Process (cid:9)
`
`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 intended
`for eventual standardization but not yet ready to enter the standards
`track. A specification may have been superseded by a more recent
`Internet Standard, or have otherwise fallen into disuse or disfavor.
`
`Specifications that are not on the standards track are labeled with
`one of three "off-track" maturity levels: "Experimental",
`"Informational", or "Historic". The documents bearing these labels
`are not Internet Standards in any sense.
`
`4.2.1 Experimental
`
`The "Experimental" designation typically denotes a specification that
`is part of some research or development effort. Such a specification
`is published for the general information of the Internet technical
`community and as an archival record of the work, subject only to
`editorial considerations and to verification that there has been
`adequate coordination with the standards process (see below). An
`Experimental specification may be the output of an organized Internet
`research effort (e.g., a Research Group of the IRTF), an IETF Working
`Group, or it may be an individual contribution.
`
`NOAC Ex. 1054 Page 12
`
`(cid:9)
`(cid:9)
`

`

`Bradner (cid:9)
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 14]
`
`Internet Standards Process (cid:9)
`
`October 1996
`
`4.2.2 Informational
`
`An "Informational" specification is published for the general
`information of the Internet community, and does not represent an
`Internet community consensus or recommendation. The Informational
`designation is intended to provide for the timely publication of a
`very broad range of responsible informational documents from many
`sources, subject only to editorial considerations and to verification
`that there has been adequate coordination with the standards process
`(see section 4.2.3).
`
`Specifications that have been prepared outside of the Internet
`community and are not incorporated into the Internet Standards
`Process by any of the provisions of section 10 may be published as
`Informational RFCs, with the permission of the owner and the
`concurrence of the RFC Editor.
`
`4.2.3 Procedures for Experimental and Informational RFC5
`
`Unless they are the result of IETF Working Group action, documents
`intended to be published with Experimental or Informational status
`should be submitted directly to the RFC Editor. The RFC Editor will
`publish any such documents as Internet-Drafts which have not already
`been so published. In order to differentiate these Internet-Drafts
`they will be labeled or grouped in the I-D directory so they are
`easily recognizable. The RFC Editor will wait two weeks after this
`publication for comments before proceeding further. The RFC Editor
`is expected to exercise his or her judgment concerning the editorial
`suitability of a document for publication with Experimental or
`Informational status, and may refuse to publish a document which, in
`the expert opinion of the RFC Editor, is unrelated to Internet
`activity or falls below the technical and/or editorial standard for
`RFC5.
`
`To ensure that the non-standards track Experimental and Informational
`designations are not misused to circumvent the Internet Standards
`Process, the IESG and the RFC Editor have agreed that the RFC Editor
`will refer to the IESG any document submitted for Experimental or
`Informational publication which, in the opinion of the RFC Editor,
`may be related to work being done, or expected to be done, within the
`IETF community. The IESG shall review such a referred document
`within a reasonable period of time, and recommend either that it be
`published as originally submitted or referred to the IETF as a
`contribution to the Internet Standards Process.
`
`If (a) the IESG recommends that the document be brought within the
`IETF and progressed within the IETF context, but the author declines
`to do so, or (b) the IESG considers that the document proposes
`
`Bradner
`
`RFC 2026
`
`Best Current Practice (cid:9)
`
`[Page 15]
`
`Internet Standards Process (cid:9)
`
`October 1996
`
`NOAC Ex. 1054 Page 13
`
`(cid:9)
`(cid:9)
`(cid:9)
`

`

`something that c