Network Working Group Internet Architecture Board
`Request for Comments: 1720 J. Postel, Editor
`Obsoletes: RFCs 1610, 1600, 1540, 1500, November 1994
`1410, 1360, 1280, 1250, 1100, 1083,
`1130, 1140, 1200
`STD: 1
`Category: Standards Track
`
` INTERNET OFFICIAL PROTOCOL STANDARDS
`
`Status of this Memo
`
` This memo describes the state of standardization of protocols used in
` the Internet as determined by the Internet Architecture Board (IAB).
` This memo is an Internet Standard. Distribution of this memo is
` unlimited.
`
`Table of Contents
`
` Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
` 1. The Standardization Process . . . . . . . . . . . . . . . . 3
` 2. The Request for Comments Documents . . . . . . . . . . . . . 5
` 3. Other Reference Documents . . . . . . . . . . . . . . . . . 6
` 3.1. Assigned Numbers . . . . . . . . . . . . . . . . . . . . . 6
` 3.2. Gateway Requirements . . . . . . . . . . . . . . . . . . . 6
` 3.3. Host Requirements . . . . . . . . . . . . . . . . . . . . 6
` 3.4. The MIL-STD Documents . . . . . . . . . . . . . . . . . . 6
` 4. Explanation of Terms . . . . . . . . . . . . . . . . . . . . 7
` 4.1. Definitions of Protocol State (Maturity Level) . . . . . . 8
` 4.1.1. Standard Protocol . . . . . . . . . . . . . . . . . . . 8
` 4.1.2. Draft Standard Protocol . . . . . . . . . . . . . . . . 9
` 4.1.3. Proposed Standard Protocol . . . . . . . . . . . . . . . 9
` 4.1.4. Experimental Protocol . . . . . . . . . . . . . . . . . 9
` 4.1.5. Informational Protocol . . . . . . . . . . . . . . . . . 9
` 4.1.6. Historic Protocol . . . . . . . . . . . . . . . . . . . 9
` 4.2. Definitions of Protocol Status (Requirement Level) . . . 9
` 4.2.1. Required Protocol . . . . . . . . . . . . . . . . . . 10
` 4.2.2. Recommended Protocol . . . . . . . . . . . . . . . . . 10
` 4.2.3. Elective Protocol . . . . . . . . . . . . . . . . . . 10
` 4.2.4. Limited Use Protocol . . . . . . . . . . . . . . . . . 10
` 4.2.5. Not Recommended Protocol . . . . . . . . . . . . . . . 10
` 5. The Standards Track . . . . . . . . . . . . . . . . . . . 10
` 5.1. The RFC Processing Decision Table . . . . . . . . . . . 10
` 5.2. The Standards Track Diagram . . . . . . . . . . . . . . 12
` 6. The Protocols . . . . . . . . . . . . . . . . . . . . . . 14
` 6.1. Recent Changes . . . . . . . . . . . . . . . . . . . . . 14
`
`Internet Architecture Board [Page 1]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 1
`
`Petitioner Valve - Ex. 1022, Page 1
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` 6.1.1. New RFCs . . . . . . . . . . . . . . . . . . . . . . . 14
` 6.1.2. Other Changes . . . . . . . . . . . . . . . . . . . . 23
` 6.2. Standard Protocols . . . . . . . . . . . . . . . . . . . 24
` 6.3. Network-Specific Standard Protocols . . . . . . . . . . 26
` 6.4. Draft Standard Protocols . . . . . . . . . . . . . . . . 27
` 6.5. Proposed Standard Protocols . . . . . . . . . . . . . . 28
` 6.6. Telnet Options . . . . . . . . . . . . . . . . . . . . . 31
` 6.7. Experimental Protocols . . . . . . . . . . . . . . . . . 32
` 6.8. Informational Protocols . . . . . . . . . . . . . . . . 33
` 6.9. Historic Protocols . . . . . . . . . . . . . . . . . . . 34
` 6.10 Obsolete Protocols . . . . . . . . . . . . . . . . . . . 36
` 7. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 37
` 7.1. IAB, IETF, and IRTF Contacts . . . . . . . . . . . . . . 37
` 7.1.1. Internet Architecture Board (IAB) Contact . . . . . . 37
` 7.1.2. Internet Engineering Task Force (IETF) Contact . . . . 38
` 7.1.3. Internet Research Task Force (IRTF) Contact . . . . . 39
` 7.2. Internet Assigned Numbers Authority (IANA) Contact . . . 39
` 7.3. Request for Comments Editor Contact . . . . . . . . . . 40
` 7.4. Network Information Center Contact . . . . . . . . . . . 40
` 7.5. Sources for Requests for Comments . . . . . . . . . . . 41
` 8. Security Considerations . . . . . . . . . . . . . . . . . 41
` 9. Author’s Address . . . . . . . . . . . . . . . . . . . . . 41
`
`Introduction
`
` A discussion of the standardization process and the RFC document
` series is presented first, followed by an explanation of the terms.
` Sections 6.2 - 6.10 contain the lists of protocols in each stage of
` standardization. Finally are pointers to references and contacts for
` further information.
`
` This memo is intended to be issued approximately quarterly; please be
` sure the copy you are reading is current. Current copies may be
` obtained from the Network Information Center (INTERNIC) or from the
` Internet Assigned Numbers Authority (IANA) (see the contact
` information at the end of this memo). Do not use this edition after
` 1-Mar-95.
`
` See Section 6.1 for a description of recent changes. In the official
` lists in sections 6.2 - 6.10, an asterisk (*) next to a protocol
` denotes that it is new to this document or has been moved from one
` protocol level to another, or differs from the previous edition of
` this document.
`
`Internet Architecture Board [Page 2]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 2
`
`Petitioner Valve - Ex. 1022, Page 2
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
`1. The Standardization Process
`
` The Internet Architecture Board maintains this list of documents that
` define standards for the Internet protocol suite. See RFC-1601 for
` the charter of the IAB and RFC-1160 for an explanation of the role
` and organization of the IAB and its subsidiary groups, the Internet
` Engineering Task Force (IETF) and the Internet Research Task Force
` (IRTF). Each of these groups has a steering group called the IESG
` and IRSG, respectively. The IETF develops these standards with the
` goal of co-ordinating the evolution of the Internet protocols; this
` co-ordination has become quite important as the Internet protocols
` are increasingly in general commercial use. The definitive
` description of the Internet standards process is found in RFC-1602.
`
` The majority of Internet protocol development and standardization
` activity takes place in the working groups of the IETF.
`
` Protocols which are to become standards in the Internet go through a
` series of states or maturity levels (proposed standard, draft
` standard, and standard) involving increasing amounts of scrutiny and
` testing. When a protocol completes this process it is assigned a STD
` number (see RFC-1311). At each step, the Internet Engineering
` Steering Group (IESG) of the IETF must make a recommendation for
` advancement of the protocol.
`
` To allow time for the Internet community to consider and react to
` standardization proposals, a minimum delay of 6 months before a
` proposed standard can be advanced to a draft standard and 4 months
` before a draft standard can be promoted to standard.
`
` It is general practice that no proposed standard can be promoted to
` draft standard without at least two independent implementations (and
` the recommendation of the IESG). Promotion from draft standard to
` standard generally requires operational experience and demonstrated
` interoperability of two or more implementations (and the
` recommendation of the IESG).
`
` In cases where there is uncertainty as to the proper decision
` concerning a protocol a special review committee may be appointed
` consisting of experts from the IETF, IRTF and the IAB with the
` purpose of recommending an explicit action.
`
` Advancement of a protocol to proposed standard is an important step
` since it marks a protocol as a candidate for eventual standardization
` (it puts the protocol "on the standards track"). Advancement to
` draft standard is a major step which warns the community that, unless
` major objections are raised or flaws are discovered, the protocol is
` likely to be advanced to standard in six months.
`
`Internet Architecture Board [Page 3]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 3
`
`Petitioner Valve - Ex. 1022, Page 3
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` Some protocols have been superseded by better ones or are otherwise
` unused. Such protocols are still documented in this memorandum with
` the designation "historic".
`
` Because it is useful to document the results of early protocol
` research and development work, some of the RFCs document protocols
` which are still in an experimental condition. The protocols are
` designated "experimental" in this memorandum. They appear in this
` report as a convenience to the community and not as evidence of their
` standardization.
`
` Other protocols, such as those developed by other standards
` organizations, or by particular vendors, may be of interest or may be
` recommended for use in the Internet. The specifications of such
` protocols may be published as RFCs for the convenience of the
` Internet community. These protocols are labeled "informational" in
` this memorandum.
`
` In addition to the working groups of the IETF, protocol development
` and experimentation may take place as a result of the work of the
` research groups of the Internet Research Task Force, or the work of
` other individuals interested in Internet protocol development. The
` the documentation of such experimental work in the RFC series is
` encouraged, but none of this work is considered to be on the track
` for standardization until the IESG has made a recommendation to
` advance the protocol to the proposed standard state.
`
` A few protocols have achieved widespread implementation without the
` approval of the IESG. For example, some vendor protocols have become
` very important to the Internet community even though they have not
` been recommended by the IESG. However, the IAB strongly recommends
` that the standards process be used in the evolution of the protocol
` suite to maximize interoperability (and to prevent incompatible
` protocol requirements from arising). The use of the terms
` "standard", "draft standard", and "proposed standard" are reserved in
` any RFC or other publication of Internet protocols to only those
` protocols which the IESG has approved.
`
` In addition to a state (like "Proposed Standard"), a protocol is also
` assigned a status, or requirement level, in this document. The
` possible requirement levels ("Required", "Recommended", "Elective",
` "Limited Use", and "Not Recommended") are defined in Section 4.2.
` When a protocol is on the standards track, that is in the proposed
` standard, draft standard, or standard state (see Section 5), the
` status shown in Section 6 is the current status.
`
` Few protocols are required to be implemented in all systems; this is
` because there is such a variety of possible systems, for example,
`
`Internet Architecture Board [Page 4]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 4
`
`Petitioner Valve - Ex. 1022, Page 4
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` gateways, routers, terminal servers, workstations, and multi-user
` hosts. The requirement level shown in this document is only a one
` word label, which may not be sufficient to characterize the
` implementation requirements for a protocol in all situations. For
` some protocols, this document contains an additional status paragraph
` (an applicability statement). In addition, more detailed status
` information may be contained in separate requirements documents (see
` Section 3).
`
`2. The Request for Comments Documents
`
` The documents called Request for Comments (or RFCs) are the working
` notes of the "Network Working Group", that is the Internet research
` and development community. A document in this series may be on
` essentially any topic related to computer communication, and may be
` anything from a meeting report to the specification of a standard.
`
` Notice:
`
` All standards are published as RFCs, but not all RFCs specify
` standards.
`
` Anyone can submit a document for publication as an RFC. Submissions
` must be made via electronic mail to the RFC Editor (see the contact
` information at the end of this memo, and see RFC 1543).
`
` While RFCs are not refereed publications, they do receive technical
` review from the task forces, individual technical experts, or the RFC
` Editor, as appropriate.
`
` The RFC series comprises a wide range of documents, ranging from
` informational documents of general interests to specifications of
` standard Internet protocols. In cases where submission is intended
` to document a proposed standard, draft standard, or standard
` protocol, the RFC Editor will publish the document only with the
` approval of the IESG. For documents describing experimental work,
` the RFC Editor will notify the IESG before publication, allowing for
` the possibility of review by the relevant IETF working group or IRTF
` research group and provide those comments to the author. See Section
` 5.1 for more detail.
`
` Once a document is assigned an RFC number and published, that RFC is
` never revised or re-issued with the same number. There is never a
` question of having the most recent version of a particular RFC.
` However, a protocol (such as File Transfer Protocol (FTP)) may be
` improved and re-documented many times in several different RFCs. It
` is important to verify that you have the most recent RFC on a
` particular protocol. This "Internet Official Protocol Standards"
`
`Internet Architecture Board [Page 5]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 5
`
`Petitioner Valve - Ex. 1022, Page 5
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` memo is the reference for determining the correct RFC for the current
` specification of each protocol.
`
` The RFCs are available from the INTERNIC, and a number of other
` sites. For more information about obtaining RFCs, see Sections 7.4
` and 7.5.
`
`3. Other Reference Documents
`
` There are three other reference documents of interest in checking the
` current status of protocol specifications and standardization. These
` are the Assigned Numbers, the Gateway Requirements, and the Host
` Requirements. Note that these documents are revised and updated at
` different times; in case of differences between these documents, the
` most recent must prevail.
`
` Also, one should be aware of the MIL-STD publications on IP, TCP,
` Telnet, FTP, and SMTP. These are described in Section 3.4.
`
`3.1. Assigned Numbers
`
` The "Assigned Numbers" document lists the assigned values of the
` parameters used in the various protocols. For example, IP protocol
` codes, TCP port numbers, Telnet Option Codes, ARP hardware types, and
` Terminal Type names. Assigned Numbers was most recently issued as
` RFC-1700.
`
`3.2. Gateway Requirements
`
` This document reviews the specifications that apply to gateways and
` supplies guidance and clarification for any ambiguities. Gateway
` Requirements is RFC-1009. A working group of the IETF is actively
` preparing a revision.
`
`3.3. Host Requirements
`
` This pair of documents reviews and updates the specifications that
` apply to hosts, and it supplies guidance and clarification for any
` ambiguities. Host Requirements was issued as RFC-1122 and RFC-1123.
`
`3.4. The MIL-STD Documents
`
` The Internet community specifications for IP (RFC-791) and TCP (RFC-
` 793) and the DoD MIL-STD specifications are intended to describe
` exactly the same protocols. Any difference in the protocols
` specified by these sets of documents should be reported to DISA and
` to the IESG. The RFCs and the MIL-STDs for IP and TCP differ in
` style and level of detail. It is strongly advised that the two sets
`
`Internet Architecture Board [Page 6]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 6
`
`Petitioner Valve - Ex. 1022, Page 6
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` of documents be used together, along with RFC-1122 and RFC-1123.
`
` The Internet and the DoD MIL-STD specifications for the FTP, SMTP,
` and Telnet protocols are essentially the same documents (RFCs 765,
` 821, 854). The MIL-STD versions have been edited slightly. Note
` that the current Internet specification for FTP is RFC-959 (as
` modified by RFC-1123).
`
` Note that these MIL-STD are now somewhat out of date. The Gateway
` Requirements (RFC-1009) and Host Requirements (RFC-1122, RFC-1123)
` take precedence over both earlier RFCs and the MIL-STDs.
`
` Internet Protocol (IP) MIL-STD-1777
` Transmission Control Protocol (TCP) MIL-STD-1778
` File Transfer Protocol (FTP) MIL-STD-1780
` Simple Mail Transfer Protocol (SMTP) MIL-STD-1781
` Telnet Protocol and Options (TELNET) MIL-STD-1782
`
` These documents are available from the Naval Publications and Forms
` Center. Requests can be initiated by telephone, telegraph, or mail;
` however, it is preferred that private industry use form DD1425, if
` possible.
`
` Naval Publications and Forms Center, Code 3015
` 5801 Tabor Ave
` Philadelphia, PA 19120
` Phone: 1-215-697-3321 (order tape)
` 1-215-697-4834 (conversation)
`
`4. Explanation of Terms
`
` There are two independent categorization of protocols. The first is
` the "maturity level" or STATE of standardization, one of "standard",
` "draft standard", "proposed standard", "experimental",
` "informational" or "historic". The second is the "requirement level"
` or STATUS of this protocol, one of "required", "recommended",
` "elective", "limited use", or "not recommended".
`
` The status or requirement level is difficult to portray in a one word
` label. These status labels should be considered only as an
` indication, and a further description, or applicability statement,
` should be consulted.
`
` When a protocol is advanced to proposed standard or draft standard,
` it is labeled with a current status.
`
`Internet Architecture Board [Page 7]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 7
`
`Petitioner Valve - Ex. 1022, Page 7
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` At any given time a protocol occupies a cell of the following matrix.
` Protocols are likely to be in cells in about the following
` proportions (indicated by the relative number of Xs). A new protocol
` is most likely to start in the (proposed standard, elective) cell, or
` the (experimental, not recommended) cell.
`
` S T A T U S
` Req Rec Ele Lim Not
` +-----+-----+-----+-----+-----+
` Std | X | XXX | XXX | | |
` S +-----+-----+-----+-----+-----+
` Draft | X | X | XXX | | |
` T +-----+-----+-----+-----+-----+
` Prop | | X | XXX | | |
` A +-----+-----+-----+-----+-----+
` Info | | | | | |
` T +-----+-----+-----+-----+-----+
` Expr | | | | XXX | |
` E +-----+-----+-----+-----+-----+
` Hist | | | | | XXX |
` +-----+-----+-----+-----+-----+
`
` What is a "system"?
`
` Some protocols are particular to hosts and some to gateways; a few
` protocols are used in both. The definitions of the terms below
` will refer to a "system" which is either a host or a gateway (or
` both). It should be clear from the context of the particular
` protocol which types of systems are intended.
`
`4.1. Definitions of Protocol State
`
` Every protocol listed in this document is assigned to a "maturity
` level" or STATE of standardization: "standard", "draft standard",
` "proposed standard", "experimental", or "historic".
`
` 4.1.1. Standard Protocol
`
` The IESG has established this as an official standard protocol for
` the Internet. These protocols are assigned STD numbers (see RFC-
` 1311). These are separated into two groups: (1) IP protocol and
` above, protocols that apply to the whole Internet; and (2)
` network-specific protocols, generally specifications of how to do
` IP on particular types of networks.
`
`Internet Architecture Board [Page 8]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 8
`
`Petitioner Valve - Ex. 1022, Page 8
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` 4.1.2. Draft Standard Protocol
`
` The IESG is actively considering this protocol as a possible
` Standard Protocol. Substantial and widespread testing and comment
` are desired. Comments and test results should be submitted to the
` IESG. There is a possibility that changes will be made in a Draft
` Standard Protocol before it becomes a Standard Protocol.
`
` 4.1.3. Proposed Standard Protocol
`
` These are protocol proposals that may be considered by the IESG
` for standardization in the future. Implementation and testing by
` several groups is desirable. Revision of the protocol
` specification is likely.
`
` 4.1.4. Experimental Protocol
`
` A system should not implement an experimental protocol unless it
` is participating in the experiment and has coordinated its use of
` the protocol with the developer of the protocol.
`
` Typically, experimental protocols are those that are developed as
` part of an ongoing research project not related to an operational
` service offering. While they may be proposed as a service
` protocol at a later stage, and thus become proposed standard,
` draft standard, and then standard protocols, the designation of a
` protocol as experimental may sometimes be meant to suggest that
` the protocol, although perhaps mature, is not intended for
` operational use.
`
` 4.1.5. Informational Protocol
`
` Protocols developed by other standard organizations, or vendors,
` or that are for other reasons outside the purview of the IESG, may
` be published as RFCs for the convenience of the Internet community
` as informational protocols.
`
` 4.1.6. Historic Protocol
`
` These are protocols that are unlikely to ever become standards in
` the Internet either because they have been superseded by later
` developments or due to lack of interest.
`
`4.2. Definitions of Protocol Status
`
` This document lists a "requirement level" or STATUS for each
` protocol. The status is one of "required", "recommended",
` "elective", "limited use", or "not recommended".
`
`Internet Architecture Board [Page 9]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 9
`
`Petitioner Valve - Ex. 1022, Page 9
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` 4.2.1. Required Protocol
`
` A system must implement the required protocols.
`
` 4.2.2. Recommended Protocol
`
` A system should implement the recommended protocols.
`
` 4.2.3. Elective Protocol
`
` A system may or may not implement an elective protocol. The
` general notion is that if you are going to do something like this,
` you must do exactly this. There may be several elective protocols
` in a general area, for example, there are several electronic mail
` protocols, and several routing protocols.
`
` 4.2.4. Limited Use Protocol
`
` These protocols are for use in limited circumstances. This may be
` because of their experimental state, specialized nature, limited
` functionality, or historic state.
`
` 4.2.5. Not Recommended Protocol
`
` These protocols are not recommended for general use. This may be
` because of their limited functionality, specialized nature, or
` experimental or historic state.
`
`5. The Standards Track
`
` This section discusses in more detail the procedures used by the RFC
` Editor and the IESG in making decisions about the labeling and
` publishing of protocols as standards.
`
`5.1. The RFC Processing Decision Table
`
` Here is the current decision table for processing submissions by the
` RFC Editor. The processing depends on who submitted it, and the
` status they want it to have.
`
`Internet Architecture Board [Page 10]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 10
`
`Petitioner Valve - Ex. 1022, Page 10
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` +==========================================================+
` |**************| S O U R C E |
` +==========================================================+
` | Desired | IAB | IESG | IRSG | Other |
` | Status | | | | |
` +==========================================================+
` | | | | | |
` | Standard | Bogus | Publish | Bogus | Bogus |
` | or | (2) | (1) | (2) | (2) |
` | Draft | | | | |
` | Standard | | | | |
` +--------------+----------+----------+----------+----------+
` | | | | | |
` | | Refer | Publish | Refer | Refer |
` | Proposed | (3) | (1) | (3) | (3) |
` | Standard | | | | |
` | | | | | |
` +--------------+----------+----------+----------+----------+
` | | | | | |
` | | Notify | Publish | Notify | Notify |
` | Experimental | (4) | (1) | (4) | (4) |
` | Protocol | | | | |
` | | | | | |
` +--------------+----------+----------+----------+----------+
` | | | | | |
` | Information | Publish | Publish |Discretion|Discretion|
` | or Opinion | (1) | (1) | (5) | (5) |
` | Paper | | | | |
` | | | | | |
` +==========================================================+
`
` (1) Publish.
`
` (2) Bogus. Inform the source of the rules. RFCs specifying
` Standard, or Draft Standard must come from the IESG, only.
`
` (3) Refer to an Area Director for review by a WG. Expect to see
` the document again only after approval by the IESG.
`
` (4) Notify both the IESG and IRSG. If no concerns are raised in
` two weeks then do Discretion (5), else RFC Editor to resolve
` the concerns or do Refer (3).
`
` (5) RFC Editor’s discretion. The RFC Editor decides if a review
` is needed and if so by whom. RFC Editor decides to publish or
` not.
`
`Internet Architecture Board [Page 11]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 11
`
`Petitioner Valve - Ex. 1022, Page 11
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` Of course, in all cases the RFC Editor can request or make minor
` changes for style, format, and presentation purposes.
`
` The IESG has designated the IESG Secretary as its agent for
` forwarding documents with IESG approval and for registering concerns
` in response to notifications (4) to the RFC Editor. Documents from
` Area Directors or Working Group Chairs may be considered in the same
` way as documents from "other".
`
`5.2. The Standards Track Diagram
`
` There is a part of the STATUS and STATE categorization that is called
` the standards track. Actually, only the changes of state are
` significant to the progression along the standards track, though the
` status assignments may change as well.
`
` The states illustrated by single line boxes are temporary states,
` those illustrated by double line boxes are long term states. A
` protocol will normally be expected to remain in a temporary state for
` several months (minimum six months for proposed standard, minimum
` four months for draft standard). A protocol may be in a long term
` state for many years.
`
` A protocol may enter the standards track only on the recommendation
` of the IESG; and may move from one state to another along the track
` only on the recommendation of the IESG. That is, it takes action by
` the IESG to either start a protocol on the track or to move it along.
`
` Generally, as the protocol enters the standards track a decision is
` made as to the eventual STATUS, requirement level or applicability
` (elective, recommended, or required) the protocol will have, although
` a somewhat less stringent current status may be assigned, and it then
` is placed in the the proposed standard STATE with that status. So
` the initial placement of a protocol is into state 1. At any time the
` STATUS decision may be revisited.
`
`Internet Architecture Board [Page 12]
`
`Petitioner Riot Games, Inc. - Ex. 1022, p. 12
`
`Petitioner Valve - Ex. 1022, Page 12
`
`

`

`
`RFC 1720 Internet Standards November 1994
`
` |
` +<----------------------------------------------+
` | ^
` V 0 | 4
` +-----------+ +===========+
` | enter |-->----------------+-------------->|experiment |
` +-----------+ | +=====+=====+
` | |
` V 1 |
` +-----------+ V
` | proposed |-------------->+
` +--->+-----+-----+ |
` | | |
` | V 2 |
` +<---+-----+-----+ V
` | draft std |-------------->+
` +--->+-----+-----+ |
` | | |
` | V 3 |
` +<---+=====+=====+ V
` | standard |-------------->+
` +=====+=====+ |
` |
` V 5
` +=====+=====+
` | historic |
` +===========+
`
` The transition from proposed standard (1) to draft standard (2) can
` only be by action of the IESG and only after the protocol has been
` proposed standard (1) for at least six months.
`
` The transition from draft standard (2) to standard (3) can only be by
` action of the IESG and only after the protocol has been draft
` standard (2) for at least four months.
`
` Occasionally, the decision may be that the protocol is not ready for
` standardization and will be assigned to the experimental state (4).
` This is off the standards track, and the protocol may be resubmitted
` to enter the standards track after further work. There are other
` paths into the experimental and historic states that do not involve
` IESG action.
`
` Sometimes one protocol is replaced by another and thus becomes
` historic, or it may happen that a protocol on the standards track is
` in a sense overtaken by another protocol (or other events) and
` becomes historic (state 5).
`
`Internet Architecture Board [Page 13]
`
`Pet