Network Working Group Internet Architecture Board and
`Request for Comments: 1602 Internet Engineering Steering Group
`Obsoletes: 1310 March 1994
`Category: Informational
`
` The Internet Standards Process -- Revision 2
`
`Status of this Memo
`
` This memo provides information for the Internet community. This memo
` does not specify an Internet standard of any kind. Distribution of
` this memo is unlimited.
`
`Notice
`
` This informational memo presents the current procedures for creating
` and documenting Internet Standards. This document is provisional,
` pending legal review and concurrence of the Internet Society
` Trustees. It is being published in this form to keep the Internet
` Community informed as to the current status of policies and
` procedures for Internet Standards work.
`
`Abstract
`
` This document is a revision of RFC 1310, which defined the official
` procedures for creating and documenting Internet Standards.
`
` This revision (revision 2) includes the following major changes:
`
` (a) The new management structure arising from the POISED Working
` Group is reflected. These changes were agreed to by the IETF
` plenary and by the IAB and IESG in November 1992 and accepted by
` the ISOC Board of Trustees at their December 1992 meeting.
`
` (b) Prototype status is added to the non-standards track maturity
` levels (Section 2.4.1).
`
` (c) The Intellectual Property Rights section is completely revised,
` in accordance with legal advice. Section 5 of this document
` replaces Sections 5 and 6 of RFC-1310. The new section 5 has
` been reviewed by legal counsel to the Internet Society.
`
`IAB - IESG [Page 1]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 1
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` (d) An appeals procedure is added (Section 3.6).
`
` (e) The wording of sections 1 and 1.2 has been changed to clarify
` the relationships that exist between the Internet Society and
` the IAB, the IESG, the IETF, and the Internet Standards process.
`
` (f) An Appendix B has been added, listing the contact points for the
` RFC editor, the IANA, the IESG, the IAB and the ISOC. The
` "future issues" are now listed in Appendix C.
`
`IAB - IESG [Page 2]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 2
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
`TABLE OF CONTENTS
`
` 1. INTRODUCTION ................................................. 3
` 1.1 Internet Standards. ...................................... 4
` 1.2 Organizations ............................................ 6
` 1.3 Standards-Related Publications ........................... 8
` 1.4 Internet Assigned Number Authority (IANA) ................ 10
` 2. NOMENCLATURE ................................................. 11
` 2.1 The Internet Standards Track ............................. 11
` 2.2 Types of Specifications .................................. 12
` 2.3 Standards Track Maturity Levels .......................... 13
` 2.4 Non-Standards Track Maturity Levels ...................... 15
` 2.5 Requirement Levels ....................................... 17
` 3. THE INTERNET STANDARDS PROCESS ............................... 19
` 3.1 Review and Approval ...................................... 19
` 3.2 Entering the Standards Track ............................. 20
` 3.3 Advancing in the Standards Track ......................... 21
` 3.4 Revising a Standard ...................................... 22
` 3.5 Retiring a Standard ...................................... 22
` 3.6 Conflict Resolution and Appeals .......................... 23
` 4. EXTERNAL STANDARDS AND SPECIFICATIONS ........................ 24
` 5. INTELLECTUAL PROPERTY RIGHTS ................................. 26
` 5.1. General Policy .......................................... 26
` 5.2. Definitions ............................................. 26
` 5.3 Trade Secret Rights ...................................... 27
` 5.4. Rights and Permissions .................................. 27
` 5.5. Notices ................................................. 30
` 5.6. Assurances .............................................. 31
` 6. REFERENCES ................................................... 34
` APPENDIX A: GLOSSARY OF ACRONYMS ................................. 35
` APPENDIX B: CONTACT POINTS ....................................... 35
` APPENDIX C: FUTURE ISSUES ........................................ 36
` Security Considerations .......................................... 37
` Authors’ Addresses ............................................... 37
`
`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.
`
`IAB - IESG [Page 3]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 3
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` 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 internets, i.e., sets of interconnected networks, which
` are not connected to the Internet but use the Internet Standards.
`
` Internet Standards were once limited to those protocols composing
` what has been commonly known as the "TCP/IP protocol suite".
` However, the Internet has been evolving towards the support of
` multiple protocol suites, especially the Open Systems
` Interconnection (OSI) suite. 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 may apply
` only 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.
`
` The procedures described in this document are designed to be fair,
` open and objective; to reflect existing (proven) practice; and to
` be flexible.
`
`IAB - IESG [Page 4]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 4
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` 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 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.
`
` 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
` places an urgency on timely development of standards. The
` Internet standardization rules described here are intended to
` balance these conflicting goals. The process is believed to be as
` short and simple as possible without undue sacrifice of technical
` competence, prior testing, or openness and fairness.
`
` In summary, the goals for the Internet standards process are:
`
` * technical excellence;
`
` * prior implementation and testing;
`
` * clear, short, and easily understandable documentation;
`
` * openness and fairness; and
`
` * timeliness.
`
` 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
`
`IAB - IESG [Page 5]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 5
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` 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.
`
` 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.
`
` 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 improving these
` procedures.
`
` The remainder of this section describes the organizations and
` publications involved in Internet standardization. Section 2
` presents the nomenclature for different kinds and levels of
` Internet standard technical specifications and their
` applicability. Section 3 describes the process and rules for
` Internet standardization. Section 4 defines how relevant
` externally-sponsored specifications and practices, developed and
` controlled by other standards bodies or by vendors, are handled in
` the Internet standardization process. Section 5 presents the
` rules that are required to protect intellectual property rights
` and to assure unrestricted ability for all interested parties to
` practice Internet Standards.
`
` 1.2 Organizations
`
` The following organizations are involved in the Internet standards
` process.
`
` * IETF
`
` The Internet Engineering Task Force (IETF) is a loosely self-
` organized group of people who make technical and other
` contributions to the engineering and evolution of the
` Internet and its technologies. It is the principal body
`
`IAB - IESG [Page 6]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 6
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` engaged in the development of new Internet Standard
` specifications, although it is not itself a part of the
` Internet Society. The IETF is composed of individual Working
` Groups, which are grouped into Areas, each of which is
` coordinated by one or more Area Directors. Nominations to
` the Internet Architecture Board and the Internet Engineering
` Steering Group are made by a nominating committee selected at
` random from the ranks of regular IETF meeting attendees who
` have volunteered to serve as nominating committee members.
`
` * ISOC
`
` Internet standardization is an organized activity of the
` Internet Society (ISOC). The ISOC is a professional society
` that is concerned with the growth and evolution of the
` worldwide Internet, with the way in which the Internet is and
` can be used, and with the social, political, and technical
` issues that arise as a result. The ISOC Board of Trustees is
` responsible for approving appointments to the Internet
` Architecture Board from among the nominees submitted by the
` IETF nominating committee.
`
` * IESG
`
` The Internet Engineering Steering Group (IESG) is responsible
` for technical management of IETF activities and the Internet
` Standards process. As part of the Internet Society, it
` administers the Internet Standards process according to the
` rules and procedures given in this document, which have been
` accepted and ratified by the Internet Society Trustees. The
` IESG is directly responsible for the actions associated with
` entry into and movement along the "standards track", as
` described in section 3 of this document, including final
` approval of specifications as Internet Standards. The IESG
` is composed of the IETF Area Directors and the chairperson of
` the IETF, who also serves as the chairperson of the IESG.
`
` * IAB
`
` The Internet Architecture Board (IAB) is a technical advisory
` group of the Internet Society. It is chartered by the
` Internet Society Trustees to provide oversight of the
` architecture of the Internet and its protocols, and to serve
` in the context of the Internet Standards process as a body to
` which the decisions of the IESG may be appealed (as described
` in section 3.6 of this document). The IAB is responsible for
`
`IAB - IESG [Page 7]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 7
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` approving appointments to the IESG from among the nominees
` submitted by the IETF nominating committee.
`
` Any member of the Internet community with the time and interest is
` urged to participate actively in one or more IETF Working Groups
` and to attend IETF meetings. In many cases, active Working Group
` participation is possible through email alone; furthermore,
` Internet video conferencing is being used experimentally to allow
` remote participation. 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;
` IETF participants recognize that the greatest benefit for all
` members of the Internet community results from cooperative
` development of technically superior protocols and services.
`
` Members of the IESG and IAB are nominated for two-year terms by a
` committee that is drawn from the roll of recent participation in
` the IETF and chartered by the ISOC Board of Trustees. The
` appointment of IESG and of IAB members are made from these
` nominations by the IAB and by the ISOC Board of Trustees,
` respectively.
`
` The Internet Research Task Force (IRTF) is not directly part of
` the standards process. It 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, the specification is
` processed through the IETF using the rules in this document.
`
` 1.3 Standards-Related Publications
`
` 1.3.1 Requests for Comments (RFCs)
`
` Each distinct version of a 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 are available for
` anonymous FTP from a number of Internet hosts.
`
` 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, from early discussion of new research concepts
`
`IAB - IESG [Page 8]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 8
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` to status memos about the Internet. RFC publication is the
` direct responsibility of the RFC Editor, under the general
` direction of the IAB.
`
` The rules for formatting and submitting an RFC are defined in
` reference [5]. Every RFC is available in ASCII text, but some
` RFCs are also available in PostScript. The PostScript version
` 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.1.3 below.
`
` 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 "STDxxxx", but it keeps its RFC number and its
` place in the RFC series.
`
` 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 and the
` IESG. These RFCs will be marked "Prototype", "Experimental" or
` "Informational" as appropriate (see section 2.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 *
` * Internet Standard. *
` ********************************************************
`
`IAB - IESG [Page 9]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 9
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` 1.3.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
` Draft 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, are not part of the permanent archival
` record of Internet activity, 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. *
` ********************************************************
`
` 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.
`
` 1.4 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" [3].
`
`IAB - IESG [Page 10]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 10
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` 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. Note that assignment of a
` number to a protocol is independent of, and does not imply,
` acceptance of that protocol as a standard.
`
` 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 to guess the next unassigned value of a
` parameter; both are hazardous.
`
` The IANA is expected 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.
`
`2. NOMENCLATURE
`
` 2.1 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.
`
`IAB - IESG [Page 11]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 11
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` 2.2 Types of Specifications
`
` Specifications subject to the Internet standardization process
` fall into two categories: Technical Specifications (TS) and
` Applicability Statements (AS).
`
` 2.2.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 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.
`
` 2.2.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
`
`IAB - IESG [Page 12]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 12
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` 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 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 by
` an AS at the Standard level.
`
` An AS may refer to a TS that is either a standards-track speci-
` fication or is "Informational", but not to a TS with a maturity
` level of "Prototype", "Experimental", or "Historic" (see
` section 2.4).
`
` 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.
`
` 2.3 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.
`
` 2.3.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. However, further experience might result in a change
` or even retraction of the specification before it advances.
`
`IAB - IESG [Page 13]
`
`Petitioner Apple Inc., IPR2015-01010, Ex. 1050, p. 13
`
`

`
`
`RFC 1602 Internet Standards Process March 1994
`
` 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. Typically, such a
` specification will be published initially with Experimental or
` Prototype status (see below), 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. However, the
` IESG may recomme