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.
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.
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
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
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
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
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. *
********************************************************
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.
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].
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.
