Network Working Group Internet Activities Board
`Request for Comments: 1310 Lyman Chapin, Chair
` March 1992
`
` The Internet Standards Process
`
`Status of this Memo
`
` This informational memo presents the current procedures for creating
` and documenting Internet Standards. Distribution of this memo is
` unlimited.
`
`TABLE OF CONTENTS
`
` 1. INTRODUCTION ................................................. 2
` 1.1. Internet Standards ....................................... 2
` 1.2. Organization ............................................. 3
` 2. THE INTERNET STANDARDS PROCESS ............................... 4
` 2.1. Introduction ............................................. 4
` 2.2. The Internet Standards Track ............................. 5
` 2.3. Requests for Comments (RFCs) ............................. 5
` 2.4. Internet Drafts .......................................... 6
` 2.5. Internet Assigned Number Authority (IANA) ................ 7
` 2.6. Review and Approval ...................................... 8
` 2.7. Entering the Standards Track ............................. 9
` 2.8. Advancing in the Standards Track ......................... 9
` 2.9. Revising a Standard ...................................... 10
` 3. NOMENCLATURE ................................................. 10
` 3.1 Types of Specifications .................................. 10
` 3.2 Standards Track Maturity Levels .......................... 12
` 3.3 Non-Standards Track Maturity Levels ...................... 13
` 3.4 Requirement Levels ....................................... 14
` 4. EXTERNAL STANDARDS AND SPECIFICATIONS ........................ 15
` 5. INTELLECTUAL PROPERTY RIGHTS ................................. 17
` 6. PATENT POLICY ................................................ 17
` 6.1 Statement from Patent Holder ............................. 18
` 6.2 Record of Statement ...................................... 18
` 6.3 Notice ................................................... 18
` 6.4 Identifying Patents ...................................... 19
` 7. ACKNOWLEDGMENTS AND REFERENCES ............................... 19
` APPENDIX A: GLOSSARY ............................................. 20
` APPENDIX B: UNRESOLVED ISSUES .................................... 21
` Security Considerations .......................................... 23
` Author’s Address ................................................. 23
`
`IAB [Page 1]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 1
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
`1. INTRODUCTION
`
` 1.1 Internet Standards
`
` This memo documents the process currently used for the
` standardization of Internet protocols and procedures.
`
` 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 internets, i.e., sets of interconnected networks, that
` are not connected to the Internet but use the Internet Standards.
` The architecture and technical specifications of the Internet are
` the result of numerous research and development activities
` conducted over a period of two decades, performed by the network
` R&D community, by service and equipment vendors, and by government
` agencies around the world.
`
` In general, an Internet Standard is a specification that is stable
` and well-understood, is technically competent, has multiple,
` independent, and interoperable implementations with operational
` experience, enjoys significant public support, and is recognizably
` useful in some or all parts of the Internet.
`
` The principal set of Internet Standards is commonly known as the
` "TCP/IP protocol suite". As the Internet evolves, new protocols
` and services, in particular those for Open Systems Interconnection
` (OSI), have been and will be deployed in traditional TCP/IP
` environments, leading to an Internet that supports multiple
` protocol suites. This document concerns all protocols,
` procedures, and conventions used in the Internet, not just the
` TCP/IP protocols.
`
` 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
` perhaps revision based upon experience, is adopted as a Standard
` by the appropriate body (see below), and is published.
`
` In practice, the process is somewhat more complicated, due to (1)
` the number and type of possible sources for specifications; (2)
` the need to prepare and revise a specification in a manner that
` preserves the interests of all of the affected parties; (3) the
` importance of establishing widespread community agreement on its
` technical content; and (4) the difficulty of evaluating the
` utility of a particular specification for the Internet community.
`
`IAB [Page 2]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 2
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
` Some specifications that are candidates for Internet
` standardization are the result of organized efforts directly
` within the Internet community; others are the result of work that
` was not originally organized as an Internet effort, but which was
` later adopted by the Internet community.
`
` From its inception, the Internet has been, and is expected to
` remain, an evolving system whose participants regularly factor new
` requirements and technology into the design and implementation of
` the global Internet. Users of the Internet and providers of the
` equipment, software, and services that support it should
` anticipate and embrace this adaptability as a major tenet of
` Internet philosophy.
`
` The procedures described in this document are the result of three
` years of evolution, driven both by the needs of the growing and
` increasingly diverse Internet community, and by experience.
` Comments and suggestions are invited for improvement in these
` procedures.
`
` 1.2 Organization
`
` The Internet Activities Board (IAB) is the primary coordinating
` committee for Internet design, engineering, and management [1].
` The IAB has delegated to its Internet Engineering Task Force
` (IETF) the primary responsibility for the development and review
` of potential Internet Standards from all sources. The IETF forms
` Working Groups to pursue specific technical issues, frequently
` resulting in the development of one or more specifications that
` are proposed for adoption as Internet Standards.
`
` Final decisions on Internet standardization are made by the IAB,
` based upon recommendations from the Internet Engineering Steering
` Group (IESG), the leadership body of the IETF. IETF Working
` Groups are organized into areas, and each area is coordinated by
` an Area Director. The Area Directors and the IETF Chairman are
` included in the IESG.
`
` Any member of the Internet community with the time and interest is
` urged to attend IETF meetings and to participate actively in one
` or more IETF Working Groups. Participation is by individual
` technical contributors, rather than formal representatives of
` organizations. The process works because the IETF Working Groups
` display a spirit of cooperation as well as a high degree of
` technical maturity; most IETF members agree that the greatest
` benefit for all members of the Internet community results from
` cooperative development of technically superior protocols and
` services.
`
`IAB [Page 3]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 3
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
` A second body under the IAB, the Internet Research Task Force
` (IRTF), investigates topics considered to be too uncertain, too
` advanced, or insufficiently well-understood to be the subject of
` Internet standardization. When an IRTF activity generates a
` specification that is sufficiently stable to be considered for
` Internet standardization, it is processed through the IETF.
`
` Section 2 of this document describes the process and rules for
` Internet standardization. Section 3 presents the nomenclature for
` different kinds and levels of Internet standard technical
` specifications and their applicability. Section 4 defines how
` relevant externally-sponsored specifications and practices that
` are developed and controlled by other bodies or by vendors are
` handled in the Internet standardization process. Section 5
` presents the requirement for prior disclosure of the existence of
` intellectual property rights. Section 6 describes the rules for
` Internet Standards that involve patents.
`
`2. THE INTERNET STANDARDS PROCESS
`
` 2.1. Introduction
`
` The procedures described in this document are intended to provide
` a clear, open, and objective basis for developing, evaluating, and
` adopting Internet Standards for protocols and services. The
` procedures provide ample opportunity for participation and comment
` by all interested parties. Before an Internet Standard is
` adopted, it is repeatedly discussed (and perhaps debated) in open
` open meetings and/or public electronic mailing lists, and it is
` available for review via world-wide on-line directories.
`
` These procedures are explicitly aimed at developing and adopting
` generally-accepted practices. Thus, a candidate for Internet
` standardization is 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.
`
` The procedures that are described here provide a great deal of
` flexibility to adapt to the wide variety of circumstances that
` occur in the Internet standardization process. Experience has
` shown this flexibility to be vital in achieving the following
` goals for Internet standardization:
`
`IAB [Page 4]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 4
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
` * high quality,
`
` * prior implementation and testing,
`
` * openness and fairness, and
`
` * timeliness.
`
` 2.2. The Internet Standards Track
`
` Specifications that are destined 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 below in
` Section 3.2.
`
` 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 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 3.3 to
` cover these and other "off-track" specifications.
`
` 2.3. Requests for Comments (RFCs)
`
` Each distinct version of a specification is published as part of
` the "Request for Comments" (RFC) document series.
`
` RFCs form a series of publications of networking technical
` documents, begun in 1969 as part of the original DARPA wide-area
` networking (ARPANET) project (see Appendix A for glossary of
` acronyms). RFCs cover a wide range of topics, from early
` discussion of new research concepts to status memos about the
` Internet. The IAB views the RFC publication process to be
` sufficiently important to warrant including the RFC Editor in the
` IAB membership.
`
` The status of specifications on the Internet standards track is
` summarized periodically in a summary RFC entitled "IAB Official
` Protocol Standards" [2]. This RFC shows the level of maturity and
` other helpful information for each Internet protocol or service
` specification.
`
`IAB [Page 5]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 5
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
` ********************************************************
` * The "IAB Official Protocol Standards" RFC is the *
` * authoritative statement of the status of any *
` * particular Internet specification, *
` ********************************************************
`
` and it is the "Publication of Record" with respect to Internet
` standardization.
`
` The STD documents form a subseries of the RFC series. When a
` specification has been adopted as a Standard, its RFC is labeled
` with a STDxxx number [9] in addition to its RFC number.
`
` Not all specifications of protocols or services for the Internet
` should or will become Internet Standards. Such non-standards
` track specifications are not subject to the rules for Internet
` standardization; generally, they will be published directly as
` RFCs at the discretion of the RFC editor. These RFCs will be
` marked as "Experimental" or "Informational" (see section 3.3).
`
` ********************************************************
` * It is important to remember that not all RFCs *
` * are standards track documents, and that not all *
` * standards track documents reach the level of *
` * Standard. *
` ********************************************************
`
` 2.4. 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.
`
` After completion to the satisfaction of its author and the
` cognizant Working Group, a document that is expected to enter or
` advance in the Internet standardization process shall be made
` available as an Internet Draft. It shall remain as an Internet
` Draft for a period of time that permits useful community review,
` at least two weeks, before submission to the IESG.
`
` An Internet Draft that is published as an RFC is removed from the
` Internet Draft directory. A document 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 Draft directory. At any time, an
`
`IAB [Page 6]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 6
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
` Internet Draft may be replace 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 next section. Internet Drafts have no formal status, and
` are not part of the permanent archival record of Internet
` activity, and they 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.
`
` 2.5. Internet Assigned Number Authority (IANA)
`
` Many protocol specifications include numbers, keywords, and other
` parameters that must be uniquely assigned. Examples include
` version numbers, protocol numbers, port numbers, and MIB numbers.
` The IAB has delegated to the Internet Assigned Numbers Authority
` (IANA) the task of assigning such protocol parameters for the
` Internet. The IANA publishes tables of all currently assigned
` numbers and parameters in RFCs titled "Assigned Numbers" [8].
`
` Each category of assigned numbers typically arises from some
` protocol that is on the standards track or is an Internet
` Standard. For example, TCP port numbers are assigned because TCP
` is a Standard. A particular value within a category may be
` assigned in a variety of circumstances; the specification
` requiring the parameter may be in the standards track, it may be
` Experimental, or it may be private.
`
` Chaos could result from accidental conflicts of parameter values,
` so we urge that every protocol parameter, for either public or
` private usage, be explicitly assigned by the IANA. Private
` protocols often become public. Programmers are often tempted to
` choose a "random" value, or guess the next unassigned value of a
` parameter; both are hazardous.
`
` The IANA is tasked to avoid frivolous assignments and to
` distinguish different assignments uniquely. The IANA accomplishes
` both goals by requiring a technical description of each protocol
` or service to which a value is to be assigned. Judgment on the
` adequacy of the description resides with the IANA. In the case of
` a standards track or Experimental protocol, the corresponding
` technical specifications provide the required documentation for
` IANA. For a proprietary protocol, the IANA will keep confidential
` any writeup that is supplied, but at least a short (2 page)
` writeup is still required for an assignment.
`
` To contact the IANA for information or to request a number,
`
`IAB [Page 7]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 7
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
` keyword or parameter assignment send an email message to
` "iana@isi.edu".
`
` 2.6. Review and Approval
`
` A standards action -- entering a particular specification into, or
` advancing it within, the standards track -- shall be recommended
` to the appropriate IETF Area Director, or to the Chairman of the
` IETF, by the individual or group that is responsible for the
` specification. Usually, the recommendation will come from an IETF
` Working Group. The Area Director or IETF chairman, in
` consultation with the IESG, shall determine if an independent
` technical review of the specification is required, and shall
` commission one if necessary.
`
` When a specification is sufficiently important in terms of its
` potential impact on the Internet or on the suite of Internet
` protocols, the IESG shall form a special review and analysis
` committee to prepare an evaluation of the specification. Such a
` committee is commissioned to provide an objective basis for
` agreement within the Internet community that the specification is
` ready for advancement. Furthermore, when the criteria for
` advancement along the standards track for an important class of
` specifications (e.g., routing protocols [6]) are not universally
` recognized, the IESG shall commission the development and
` publication of category-specific acceptance criteria.
`
` The IESG shall determine whether a specification satisfies the
` applicable criteria for the recommended action (see Sections 3.2
` and 3.3 of this document) and shall communicate its findings to
` the IETF to permit a final review by the general Internet
` community. This IETF notification shall be via electronic mail to
` the IETF mailing list; in addition, there will often be a
` presentation or statement by the appropriate working group or Area
` Director during an IETF plenary meeting. Any significant issues
` that have not been resolved satisfactorily during the development
` of the specification may be raised at this time for final
` resolution by the IESG.
`
` The IESG shall communicate to the IAB its recommendation for
` action, with a citation to the most current version of the
` document. The IETF shall be notified by email of any such
` recommendation. If the IAB finds a significant problem, or needs
` clarification on a particular point, it shall resolve the matter
` with the Working Group and its chairperson and/or the document
` author, with the assistance and concurrence of the IESG and the
` relevant IETF Area Director.
`
`IAB [Page 8]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 8
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
` Following IAB approval and any necessary editorial work, the RFC
` Editor shall publish the specification as an RFC. The
` specification shall then be removed from the Internet Drafts
` directory.
`
` 2.7. Entering the Standards Track
`
` A specification that is potentially an Internet Standard may
` originate from:
`
` (a) an IAB-sponsored effort (typically an IETF Working Group),
`
` (b) independent activity by individuals, or
`
` (c) an external organization.
`
` In cases (b) and (c), the work might be tightly integrated with
` the work of an existing IETF Working Group, or it might be offered
` for standardization without prior IETF involvement. In most
` cases, a specification resulting from an effort that took place
` outside of an IETF Working Group context will be submitted to an
` appropriate Working Group for evaluation and refinement; if
` necessary, an appropriate Working Group will be created.
`
` For externally-developed specifications that are well-integrated
` with existing Working Group efforts, a Working Group is assumed to
` afford adequate community review of the accuracy and applicability
` of the specification. If a Working Group is unable to resolve all
` technical and usage questions, additional independent review may
` be necessary. Such reviews may be done within a Working Group
` context, or by an ad hoc review committee established specifically
` for that purpose. It is the responsibility of the appropriate
` IETF Area Director to determine what, if any, review of an
` external specification is needed and how it shall be conducted.
`
` 2.8. Advancing in the Standards Track
`
` A specification shall remain at the Proposed Standard level for at
` least 6 months and at the Draft Standard level for at least 4
` months.
`
` A specification may be (indeed, is likely to be) revised as it
` advances through the standards track. At each stage, the IESG
` shall determine the scope and significance of the revision to the
` specification, and, if necessary and appropriate, modify the
` recommended action. Minor revisions are expected, and they will
` not affect advancement through the standards track. A significant
` revision may require that the specification accumulate more
`
`IAB [Page 9]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 9
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
` experience at its current maturity level before progressing.
` Finally, if the specification has been changed very significantly,
` the IESG may decide to treat the revision as if it were a new
` document, re-entering the standards track at the beginning.
`
` A specification that has not reached the maturity level of
` Standard within twenty-four months of first becoming a Proposed
` Standard shall be reviewed for viability by the IESG, which shall
` recommend either termination or continuation of the development
` effort to the IAB. Such a recommendation shall be communicated to
` the IETF via electronic mail to the IETF mailing list, to allow
` the Internet community an opportunity to comment. This provision
` is not intended to threaten legitimate and active Working Group
` efforts, but rather to provide an administrative mechanism for
` terminating a moribund effort.
`
` 2.9. Revising a Standard
`
` A recommendation to revise an established Internet Standard shall
` be evaluated by the IESG with respect to the operational impact of
` introducing a new version while the previous version is still in
` use. If the IESG accepts the recommendation, the new version must
` progress through the full Internet standardization process as if
` it were a completely new specification.
`
` Once the new version has reached the Standard level, it may
` immediately replace the previous version. In some cases, both
` versions may remain as Internet Standards to honor the
` requirements of an installed base; however, the relationship
` between the previous and the new versions must be explicitly
` stated in the text of the new version or in another appropriate
` document (e.g., an Applicability Statement; see Section 3.1.2).
`
`3. NOMENCLATURE
`
` 3.1. Types of Specifications
`
` The specifications subject to the Internet standardization process
` fall into two categories: Technical Specifications (TS) and
` Applicability Statements (AS).
`
` 3.1.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
`
`IAB [Page 10]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 10
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
` from other specifications by reference to other documents
` (which may or may 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, is
` defined by an Applicability Statement.
`
` 3.1.2. Applicability Statement (AS)
`
` An Applicability Statement specifies how, and under what
` circumstances, one or more TSs are to be applied to support a
` particular Internet capability. An AS may specify uses for TSs
` that are not Internet Standards, as discussed in Section 4.
`
` 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.
`
` 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 [3,4,5], such as Internet
` routers or Internet hosts.
`
` An AS may not have a higher maturity level in the standards
` track than any TS to which the AS applies. For example, a TS
` at Draft Standard level may be referenced by an AS at the
` Proposed Standard or Draft Standard level, but not an AS at the
` Standard level. Like a TS, an AS does not come into effect
` until it reaches Standard level.
`
` Although TSs and ASs are conceptually separate, in practice an
` Internet Standard RFC may include elements of both an AS and one
` or more TSs in a single document. For example, Technical
` Specifications that are developed specifically and exclusively for
` some particular domain of applicability, e.g., for mail server
`
`IAB [Page 11]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1051, p. 11
`
`

`
`
`RFC 1310 Internet Standards Process March 1992
`
` 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.
`
` 3.2. Standards Track Maturity Levels
`
` ASs and TSs 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. The general
` procedures for developing a specification and processing it
` through the maturity levels along the standards track were
` discussed in Section 2 above.
`
` 3.2.1. Proposed Standard
`
` The entry-level maturity for the standards track is "Proposed
` Standard". 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.
`
` 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. Furthermore, the IAB 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.
` Typically, such a specification will be published initially in
` the Experimental state (see below), which is not part of the
` standards track, and moved to the standards track only after
` sufficient implementation or operational experience has been
` obtained.
`
` A Proposed Standard should have no known technical omissions
` with respect to the requirements placed upon it. In some
` cases, the IESG may recommend that the requirements be
` explicitly reduced in order to allow a protocol to advance into
`
`IAB [Page 12]
`
`Pet