As per Relevance of the word specific, we have this rfc below:
Network Working Group S.
Request for Comments: 2026 Harvard
BCP: 9 October 1996
Obsoletes: 1602
Category: Best Current
The Internet Standards Process -- Revision 3
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
This memo documents the process used by the Internet community
the standardization of protocols and procedures. It defines
stages in the standardization process, the requirements for moving
document between stages and the types of documents used during
process. It also addresses the intellectual property rights
copyright issues associated with the standards process
Table of
1. INTRODUCTION....................................................2
1.1 Internet Standards...........................................3
1.2 The Internet Standards Process...............................3
1.3 Organization of This Document................................5
2. INTERNET STANDARDS-RELATED PUBLICATIONS.........................5
2.1 Requests for Comments (RFCs).................................5
2.2 Internet-Drafts..............................................7
3. INTERNET STANDARD SPECIFICATIONS................................8
3.1 Technical Specification (TS).................................8
3.2 Applicability Statement (AS).................................8
3.3 Requirement Levels...........................................9
4. THE INTERNET STANDARDS TRACK...................................10
4.1 Standards Track Maturity Levels.............................11
4.1.1 Proposed Standard.......................................11
4.1.2 Draft Standard..........................................12
4.1.3 Internet Standard.......................................13
4.2 Non-Standards Track Maturity Levels.........................13
4.2.1 Experimental............................................13
4.2.2 Informational...........................................14
4.2.3 Procedures for Experimental and Informational RFCs......14
4.2.4 Historic................................................15
Bradner Best Current Practice [Page 1]
RFC 2026 Internet Standards Process October 1996
5. Best Current Practice (BCP) RFCs...............................15
5.1 BCP Review Process..........................................16
6. THE INTERNET STANDARDS PROCESS.................................17
6.1 Standards Actions...........................................17
6.1.1 Initiation of Action....................................17
6.1.2 IESG Review and Approval................................17
6.1.3 Publication.............................................18
6.2 Advancing in the Standards Track............................19
6.3 Revising a Standard.........................................20
6.4 Retiring a Standard.........................................20
6.5 Conflict Resolution and Appeals.............................21
6.5.1 Working Group Disputes...................................21
6.5.2 Process Failures.........................................22
6.5.3 Questions of Applicable Procedure........................22
6.5.4 Appeals Procedure........................................23
7. EXTERNAL STANDARDS AND SPECIFICATIONS..........................23
7.1 Use of External Specifications..............................24
7.1.1 Incorporation of an Open Standard.......................24
7.1.2 Incorporation of a Other Specifications.................24
7.1.3 Assumption..............................................25
8. NOTICES AND RECORD KEEPING......................................25
9. VARYING THE PROCESS.............................................26
9.1 The Variance Procedure.......................................26
9.2 Exclusions...................................................27
10. INTELLECTUAL PROPERTY RIGHTS..................................27
10.1. General Policy............................................27
10.2 Confidentiality Obligations...............................28
10.3. Rights and Permissions....................................28
10.3.1. All Contributions......................................28
10.3.2. Standards Track Documents..............................29
10.3.3 Determination of Reasonable
Non-discriminatory Terms................................30
10.4. Notices...................................................30
11. ACKNOWLEDGMENTS................................................32
12. SECURITY CONSIDERATIONS........................................32
13. REFERENCES.....................................................33
14. DEFINITIONS OF TERMS...........................................33
15. AUTHOR'S ADDRESS...............................................34
APPENDIX A: GLOSSARY OF ACRONYMS...................................35
Bradner Best Current Practice [Page 2]
RFC 2026 Internet Standards Process October 1996
1.
This memo documents the process currently used by the
community for the standardization of protocols and procedures.
Internet Standards process is an activity of the Internet
that is organized and managed on behalf of the Internet community
the Internet Architecture Board (IAB) and the Internet
Steering Group (IESG).
1.1 Internet
The Internet, a loosely-organized international collaboration
autonomous, interconnected networks, supports host-to-
communication through voluntary adherence to open protocols
procedures defined by Internet Standards. There are also
isolated interconnected networks, which are not connected to
global Internet but use the Internet Standards
The Internet Standards Process described in this document
concerned with all protocols, procedures, and conventions that
used in or by the Internet, whether or not they are part of
TCP/IP protocol suite. In the case of protocols developed and/
standardized by non-Internet organizations, however, the
Standards Process normally applies to the application of the
or procedure in the Internet context, not to the specification of
protocol itself
In general, an Internet Standard is a specification that is
and well-understood, is technically competent, has multiple
independent, and interoperable implementations with
operational experience, enjoys significant public support, and
recognizably useful in some or all parts of the Internet
1.2 The Internet Standards
In outline, the process of creating an Internet Standard
straightforward: a specification undergoes a period of
and several iterations of review by the Internet community
revision based upon experience, is adopted as a Standard by
appropriate body (see below), and is published. In practice,
process is more complicated, due to (1) the difficulty of
specifications of high technical quality; (2) the need to
the interests of all of the affected parties; (3) the importance
establishing widespread community consensus; and (4) the
of evaluating the utility of a particular specification for
Internet community
Bradner Best Current Practice [Page 3]
RFC 2026 Internet Standards Process October 1996
The goals of the Internet Standards Process are
o technical excellence
o prior implementation and testing
o clear, concise, and easily understood documentation
o openness and fairness;
o timeliness
The procedures described in this document are designed to be fair
open, and objective; to reflect existing (proven) practice; and
be flexible
o These procedures are intended to provide a fair, open,
objective basis for developing, evaluating, and adopting
Standards. They provide ample opportunity for participation
comment by all interested parties. At each stage of
standardization process, a specification is repeatedly
and its merits debated in open meetings and/or public
mailing lists, and it is made available for review via world-
on-line directories
o These procedures are explicitly aimed at recognizing and
generally-accepted practices. Thus, a candidate
must be implemented and tested for correct operation
interoperability by multiple independent parties and utilized
increasingly demanding environments, before it can be adopted
an Internet Standard
o These procedures provide a great deal of flexibility to adapt
the wide variety of circumstances that occur in
standardization process. Experience has shown this flexibility
be vital in achieving the goals listed above
The goal of technical competence, the requirement for
implementation and testing, and the need to allow all
parties to comment all require significant time and effort. On
other hand, today's rapid development of networking
demands timely development of standards. The Internet
Process is intended to balance these conflicting goals. The
is believed to be as short and simple as possible without
technical excellence, thorough testing before adoption of a standard
or openness and fairness
From its inception, the Internet has been, and is expected to remain
an evolving system whose participants regularly factor
requirements and technology into its design and implementation.
of the Internet and providers of the equipment, software,
services that support it should anticipate and embrace this
as a major tenet of Internet philosophy
Bradner Best Current Practice [Page 4]
RFC 2026 Internet Standards Process October 1996
The procedures described in this document are the result of a
of years of evolution, driven both by the needs of the growing
increasingly diverse Internet community, and by experience
Bradner Best Current Practice [Page 5]
RFC 2026 Internet Standards Process October 1996
1.3 Organization of This
Section 2 describes the publications and archives of the
Standards Process. Section 3 describes the types of
standard specifications. Section 4 describes the Internet
specifications track. Section 5 describes Best Current
RFCs. Section 6 describes the process and rules for
standardization. Section 7 specifies the way in which externally
sponsored specifications and practices, developed and controlled
other standards bodies or by others, are handled within the
Standards Process. Section 8 describes the requirements for
and record keeping Section 9 defines a variance process to
one-time exceptions to some of the requirements in this
Section 10 presents the rules that are required to
intellectual property rights in the context of the development
use of Internet Standards. Section 11 includes acknowledgments
some of the people involved in creation of this document. Section 12
notes that security issues are not dealt with by this document
Section 13 contains a list of numbered references. Section 14
contains definitions of some of the terms used in this document
Section 15 lists the author's email and postal addresses. Appendix
contains a list of frequently-used acronyms
2. INTERNET STANDARDS-RELATED
2.1 Requests for Comments (RFCs
Each distinct version of an Internet standards-related
is published as part of the "Request for Comments" (RFC)
series. This archival series is the official publication channel
Internet standards documents and other publications of the IESG, IAB
and Internet community. RFCs can be obtained from a number
Internet hosts using anonymous FTP, gopher, World Wide Web, and
Internet document-retrieval systems
The RFC series of documents on networking began in 1969 as part
the original ARPA wide-area networking (ARPANET) project (
Appendix A for glossary of acronyms). RFCs cover a wide range
topics in addition to Internet Standards, from early discussion
new research concepts to status memos about the Internet.
publication is the direct responsibility of the RFC Editor, under
general direction of the IAB
Bradner Best Current Practice [Page 6]
RFC 2026 Internet Standards Process October 1996
The rules for formatting and submitting an RFC are defined in [5].
Every RFC is available in ASCII text. Some RFCs are also
in other formats. The other versions of an RFC may contain
(such as diagrams and figures) that is not present in the
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
summarized periodically in an RFC entitled "Internet
Protocol Standards" [1]. This RFC shows the level of maturity
other helpful information for each Internet protocol or
specification (see section 3).
Some RFCs document Internet Standards. These RFCs form the 'STD
subseries of the RFC series [4]. When a specification has
adopted as an Internet Standard, it is given the additional
"STDxxx", but it keeps its RFC number and its place in the
series. (see section 4.1.3)
Some RFCs standardize the results of community deliberations
statements of principle or conclusions about what is the best way
perform some operations or IETF process function. These RFCs
the specification has been adopted as a BCP, it is given
additional label "BCPxxx", but it keeps its RFC number and its
in the RFC series. (see section 5)
Not all specifications of protocols or services for the
should or will become Internet Standards or BCPs. Such non-
track specifications are not subject to the rules for
standardization. Non-standards track specifications may be
directly as "Experimental" or "Informational" RFCs at the
of the RFC Editor in consultation with the IESG (see section 4.2).
Bradner Best Current Practice [Page 7]
RFC 2026 Internet Standards Process October 1996
********************************************************
* *
* 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. In the same way, not all RFCs *
* which describe current practices have been given *
* the review and approval to become BCPs. See *
* RFC-1796 [6] for further information. *
* *
********************************************************
2.2 Internet-
During the development of a specification, draft versions of
document are made available for informal review and comment
placing them in the IETF's "Internet-Drafts" directory, which
replicated on a number of Internet hosts. This makes an
working document readily available to a wide audience,
the process of review and revision
An Internet-Draft that is published as an RFC, or that has
unchanged in the Internet-Drafts directory for more than six
without being recommended by the IESG for publication as an RFC,
simply removed from the Internet-Drafts directory. At any time,
Internet-Draft may be replaced by a more recent version of the
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
the previous section. Internet-Drafts have no formal status, and
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. *
* *
********************************************************
Bradner Best Current Practice [Page 8]
RFC 2026 Internet Standards Process October 1996
Note: It is acceptable to reference a standards-track
that may reasonably be expected to be published as an RFC using
phrase "Work in Progress" without referencing an Internet-Draft
This may also be done in a standards track document itself as
as the specification in which the reference is made would stand as
complete and understandable document with or without the reference
the "Work in Progress".
3. INTERNET STANDARD
Specifications subject to the Internet Standards Process fall
one of two categories: Technical Specification (TS)
Applicability Statement (AS).
3.1 Technical Specification (TS
A Technical Specification is any description of a protocol, service
procedure, convention, or format. It may completely describe all
the relevant aspects of its subject, or it may leave one or
parameters or options unspecified. A TS may be completely self
contained, or it may incorporate material from other
by reference to other documents (which might or might not be
Standards).
A TS shall include a statement of its scope and the general
for its use (domain of applicability). Thus, a TS that is
specific to a particular context shall contain a statement to
effect. However, a TS does not specify requirements for its
within the Internet; these requirements, which depend on
particular context in which the TS is incorporated by
system configurations, are defined by an Applicability Statement
3.2 Applicability Statement (AS
An Applicability Statement specifies how, and under
circumstances, one or more TSs may be applied to support a
Internet capability. An AS may specify uses for TSs that are
Internet Standards, as discussed in Section 7.
An AS identifies the relevant TSs and the specific way in which
are to be combined, and may also specify particular values or
of TS parameters or subfunctions of a TS protocol that must
implemented. An AS also specifies the circumstances in which the
of a particular TS is required, recommended, or elective (see
3.3).
Bradner Best Current Practice [Page 9]
RFC 2026 Internet Standards Process October 1996
An AS may describe particular methods of using a TS in a
"domain of applicability", such as Internet routers,
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
Internet systems, such as Internet routers or Internet hosts
An AS may not have a higher maturity level in the standards
than any standards-track TS on which the AS relies (see section 4.1).
For example, a TS at Draft Standard level may be referenced by an
at the Proposed Standard or Draft Standard level, but not by an AS
the Standard level
3.3 Requirement
An AS shall apply one of the following "requirement levels" to
of the TSs to which it refers
(a) Required: Implementation of the referenced TS, as specified
the AS, is required to achieve minimal conformance. For example
IP and ICMP must be implemented by all Internet systems using
TCP/IP Protocol Suite
(b) Recommended: Implementation of the referenced TS is
required for minimal conformance, but experience and/or
accepted technical wisdom suggest its desirability in the
of applicability of the AS. Vendors are strongly encouraged
include the functions, features, and protocols of Recommended
in their products, and should omit them only if the omission
justified by some special circumstance. For example, the
protocol should be implemented by all systems that would
from remote access
(c) Elective: Implementation of the referenced TS is
within the domain of applicability of the AS; that is, the
creates no explicit necessity to apply the TS. However,
particular vendor may decide to implement it, or a particular
may decide that it is a necessity in a specific environment.
example, the DECNET MIB could be seen as valuable in
environment where the DECNET protocol is used
Bradner Best Current Practice [Page 10]
RFC 2026 Internet Standards Process October 1996
As noted in section 4.1, there are TSs that are not in
standards track or that have been retired from the
track, and are therefore not required, recommended, or elective
Two additional "requirement level" designations are available
these TSs
(d) Limited Use: The TS is considered to be appropriate for
only in limited or unique circumstances. For example, the
of a protocol with the "Experimental" designation should
be limited to those actively involved with the experiment
(e) Not Recommended: A TS that is considered to be
for general use is labeled "Not Recommended". This may be
of its limited functionality, specialized nature, or
status
Although TSs and ASs are conceptually separate, in practice
standards-track document may combine an AS and one or more
TSs. For example, Technical Specifications that are
specifically and exclusively for some particular domain
applicability, e.g., for mail server hosts, often contain within
single specification all of the relevant AS and TS information.
such cases, no useful purpose would be served by
distributing the information among several documents just to
the formal AS/TS distinction. However, a TS that is likely to
to more than one domain of applicability should be developed in
modular fashion, to facilitate its incorporation by multiple ASs
The "Official Protocol Standards" RFC (STD1) lists a
requirement level for each TS, using the nomenclature defined in
section. This RFC is updated periodically. In many cases,
detailed descriptions of the requirement levels of
protocols and of individual features of the protocols will be
in appropriate ASs
4. THE INTERNET STANDARDS
Specifications that are intended to become Internet Standards
through a set of maturity levels known as the "standards track".
These maturity levels -- "Proposed Standard", "Draft Standard",
"Standard" -- are defined and discussed in section 4.1. The way
which specifications move along the standards track is described
section 6.
Even after a specification has been adopted as an Internet Standard
further evolution often occurs based on experience and
recognition of new requirements. The nomenclature and procedures
Internet standardization provide for the replacement of old
Bradner Best Current Practice [Page 11]
RFC 2026 Internet Standards Process October 1996
Standards with new ones, and the assignment of descriptive labels
indicate the status of "retired" Internet Standards. A set
maturity levels is defined in section 4.2 to cover these and
specifications that are not considered to be on the standards track
4.1 Standards Track Maturity
Internet specifications go through stages of development, testing
and acceptance. Within the Internet Standards Process, these
are formally labeled "maturity levels".
This section describes the maturity levels and the
characteristics of specifications at each level
4.1.1 Proposed
The entry-level maturity for the standards track is "
Standard". A specific action by the IESG is required to move
specification onto the standards track at the "Proposed Standard
level
A Proposed Standard specification is generally stable, has
known design choices, is believed to be well-understood, has
significant community review, and appears to enjoy enough
interest to be considered valuable. However, further
might result in a change or even retraction of the
before it advances
Usually, neither implementation nor operational experience
required for the designation of a specification as a
Standard. However, such experience is highly desirable, and
usually represent a strong argument in favor of a Proposed
designation
The IESG may require implementation and/or operational
prior to granting Proposed Standard status to a specification
materially affects the core Internet protocols or that
behavior that may have significant operational impact on
Internet
A Proposed Standard should have no known technical omissions
respect to the requirements placed upon it. However, the IESG
waive this requirement in order to allow a specification to
to the Proposed Standard state when it is considered to be useful
necessary (and timely) even with known technical omissions
Bradner Best Current Practice [Page 12]
RFC 2026 Internet Standards Process October 1996
Implementors should treat Proposed Standards as
specifications. It is desirable to implement them in order to
experience and to validate, test, and clarify the specification
However, since the content of Proposed Standards may be changed
problems are found or better solutions are identified,
implementations of such standards into a disruption-
environment is not recommended
4.1.2 Draft
A specification from which at least two independent and
implementations from different code bases have been developed,
for which sufficient successful operational experience has
obtained, may be elevated to the "Draft Standard" level. For
purposes of this section, "interoperable" means to be
equivalent or interchangeable components of the system or process
which they are used. If patented or otherwise controlled
is required for implementation, the separate implementations
also have resulted from separate exercise of the licensing process
Elevation to Draft Standard is a major advance in status,
a strong belief that the specification is mature and will be useful
The requirement for at least two independent and
implementations applies to all of the options and features of
specification. In cases in which one or more options or
have not been demonstrated in at least two
implementations, the specification may advance to the Draft
level only if those options or features are removed
The Working Group chair is responsible for documenting the
implementations which qualify the specification for Draft or
Standard status along with documentation about testing of
interoperation of these implementations. The documentation
include information about the support of each of the
options and features. This documentation should be submitted to
Area Director with the protocol action request. (see Section 6)
A Draft Standard must be well-understood and known to be
stable, both in its semantics and as a basis for developing
implementation. A Draft Standard may still require additional
more widespread field experience, since it is possible
implementations based on Draft Standard specifications to
unforeseen behavior when subjected to large-scale use in
environments
Bradner Best Current Practice [Page 13]
RFC 2026 Internet Standards Process October 1996
A Draft Standard is normally considered to be a final specification
and changes are likely to be made only to solve specific
encountered. In most circumstances, it is reasonable for vendors
deploy implementations of Draft Standards into a disruption
environment
4.1.3 Internet
A specification for which significant implementation and
operational experience has been obtained may be elevated to
Internet Standard level. An Internet Standard (which may simply
referred to as a Standard) is characterized by a high degree
technical maturity and by a generally held belief that the
protocol or service provides significant benefit to the
community
A specification that reaches the status of Standard is assigned
number in the STD series while retaining its RFC number
4.2 Non-Standards Track Maturity
Not every specification is on the standards track. A
may not be intended to be an Internet Standard, or it may be
for eventual standardization but not yet ready to enter the
track. A specification may have been superseded by a more
Internet Standard, or have otherwise fallen into disuse or disfavor
Specifications that are not on the standards track are labeled
one of three "off-track" maturity levels: "Experimental",
"Informational", or "Historic". The documents bearing these
are not Internet Standards in any sense
4.2.1
The "Experimental" designation typically denotes a specification
is part of some research or development effort. Such a
is published for the general information of the Internet
community and as an archival record of the work, subject only
editorial considerations and to verification that there has
adequate coordination with the standards process (see below).
Experimental specification may be the output of an organized
research effort (e.g., a Research Group of the IRTF), an IETF
Group, or it may be an individual contribution
Bradner Best Current Practice [Page 14]
RFC 2026 Internet Standards Process October 1996
4.2.2
An "Informational" specification is published for the
information of the Internet community, and does not represent
Internet community consensus or recommendation. The
designation is intended to provide for the timely publication of
very broad range of responsible informational documents from
sources, subject only to editorial considerations and to
that there has been adequate coordination with the standards
(see section 4.2.3).
Specifications that have been prepared outside of the
community and are not incorporated into the Internet
Process by any of the provisions of section 10 may be published
Informational RFCs, with the permission of the owner and
concurrence of the RFC Editor
4.2.3 Procedures for Experimental and Informational
Unless they are the result of IETF Working Group action,
intended to be published with Experimental or Informational
should be submitted directly to the RFC Editor. The RFC Editor
publish any such documents as Internet-Drafts which have not
been so published. In order to differentiate these Internet-
they will be labeled or grouped in the I-D directory so they
easily recognizable. The RFC Editor will wait two weeks after
publication for comments before proceeding further. The RFC
is expected to exercise his or her judgment concerning the
suitability of a document for publication with Experimental
Informational status, and may refuse to publish a document which,
the expert opinion of the RFC Editor, is unrelated to
activity or falls below the technical and/or editorial standard
RFCs
To ensure that the non-standards track Experimental and
designations are not misused to circumvent the Internet
Process, the IESG and the RFC Editor have agreed that the RFC
will refer to the IESG any document submitted for Experimental
Informational publication which, in the opinion of the RFC Editor
may be related to work being done, or expected to be done, within
IETF community. The IESG shall review such a referred
within a reasonable period of time, and recommend either that it
published as originally submitted or referred to the IETF as
contribution to the Internet Standards Process
If (a) the IESG recommends that the document be brought within
IETF and progressed within the IETF context, but the author
to do so, or (b) the IESG considers that the document
Bradner Best Current Practice [Page 15]
RFC 2026 Internet Standards Process October 1996
something that conflicts with, or is actually inimical to,
established IETF effort, the document may still be published as
Experimental or Informational RFC. In these cases, however, the
may insert appropriate "disclaimer" text into the RFC either in
immediately following the "Status of this Memo" section in order
make the circumstances of its publication clear to readers
Documents proposed for Experimental and Informational RFCs by
Working Groups go through IESG review. The review is initiated
the process described in section 6.1.1.
4.2.4
A specification that has been superseded by a more
specification or is for any other reason considered to be obsolete
assigned to the "Historic" level. (Purists have suggested that
word should be "Historical"; however, at this point the use
"Historic" is historical.)
Note: Standards track specifications normally must not depend
other standards track specifications which are at a lower
level or on non standards track specifications other than
specifications from other standards bodies. (See Section 7.)
5. BEST CURRENT PRACTICE (BCP)
The BCP subseries of the RFC series is designed to be a way
standardize practices and the results of community deliberations.
BCP document is subject to the same basic set of procedures
standards track documents and thus is a vehicle by which the
community can define and ratify the community's best current
on a statement of principle or on what is believed to be the best
to perform some operations or IETF process function
Historically Internet standards have generally been concerned
the technical specifications for hardware and software required
computer communication across interconnected networks. However
since the Internet itself is composed of networks operated by a
variety of organizations, with diverse goals and rules, good
service requires that the operators and administrators of
Internet follow some common guidelines for policies and operations
While these guidelines are generally different in scope and
from protocol standards, their establishment needs a similar
for consensus building
While it is recognized that entities such as the IAB and IESG
composed of individuals who may participate, as individuals, in
technical work of the IETF, it is also recognized that the
Bradner Best Current Practice [Page 16]
RFC 2026 Internet Standards Process October 1996
themselves have an existence as leaders in the community. As
in the Internet technical community, these entities should have
outlet to propose ideas to stimulate work in a particular area,
raise the community's sensitivity to a certain issue, to make
statement of architectural principle, or to communicate
thoughts on other matters. The BCP subseries creates a
structured way for these management entities to insert proposals
the consensus-building machinery of the IETF while gauging
community's view of that issue
Finally, the BCP series may be used to document the operation of
IETF itself. For example, this document defines the IETF
Process and is published as a BCP
5.1 BCP Review
Unlike standards-track documents, the mechanisms described in
are not well suited to the phased roll-in nature of the three
standards track and instead generally only make sense for full
immediate instantiation
The BCP process is similar to that for proposed standards. The
is submitted to the IESG for review, (see section 6.1.1) and
existing review process applies, including a Last-Call on the
Announce mailing list. However, once the IESG has approved
document, the process ends and the document is published.
resulting document is viewed as having the technical approval of
IETF
Specifically, a document to be considered for the status of BCP
undergo the procedures outlined in sections 6.1, and 6.4 of
document. The BCP process may be appealed according to the
in section 6.5.
Because BCPs are meant to express community consensus but are
at more quickly than standards, BCPs require particular care
Specifically, BCPs should not be viewed simply as
Informational RFCs, but rather should be viewed as documents
for a content different from Informational RFCs
A specification, or group of specifications, that has, or have
approved as a BCP is assigned a number in the BCP series
retaining its RFC number(s).
Bradner Best Current Practice [Page 17]
RFC 2026 Internet Standards Process October 1996
6. THE INTERNET STANDARDS
The mechanics of the Internet Standards Process involve decisions
the IESG concerning the elevation of a specification onto
standards track or the movement of a standards-track
from one maturity level to another. Although a number of
objective criteria (described below and in section 4) are
to guide the IESG in making a decision to move a specification onto
along, or off the standards track, there is no algorithmic
of elevation to or progression along the standards track for
specification. The experienced collective judgment of the
concerning the technical quality of a specification proposed
elevation to or advancement in the standards track is an
component of the decision-making process
6.1 Standards
A "standards action" -- entering a particular specification into
advancing it within, or removing it from, the standards track --
be approved by the IESG
6.1.1 Initiation of
A specification that is intended to enter or advance in the
standards track shall first be posted as an Internet-Draft (
section 2.2) unless it has not changed since publication as an RFC
It shall remain as an Internet-Draft for a period of time, not
than two weeks, that permits useful community review, after which
recommendation for action may be initiated
A standards action is initiated by a recommendation by the
Working group responsible for a specification to its Area Director
copied to the IETF Secretariat or, in the case of a specification
associated with a Working Group, a recommendation by an individual
the IESG
6.1.2 IESG Review and
The IESG shall determine whether or not a specification submitted
it according to section 6.1.1 satisfies the applicable criteria
the recommended action (see sections 4.1 and 4.2), and shall
addition determine whether or not the technical quality and
of the specification is consistent with that expected for
maturity level to which the specification is recommended
In order to obtain all of the information necessary to make
determinations, particularly when the specification is considered
the IESG to be extremely important in terms of its potential
Bradner Best Current Practice [Page 18]
RFC 2026 Internet Standards Process October 1996
on the Internet or on the suite of Internet protocols, the IESG may
at its discretion, commission an independent technical review of
specification
The IESG will send notice to the IETF of the pending
consideration of the document(s) to permit a final review by
general Internet community. This "Last-Call" notification shall
via electronic mail to the IETF Announce mailing list. Comments on
Last-Call shall be accepted from anyone, and should be sent
directed in the Last-Call announcement
The Last-Call period shall be no shorter than two weeks except
those cases where the proposed standards action was not initiated
an IETF Working Group, in which case the Last-Call period shall be
shorter than four weeks. If the IESG believes that the
interest would be served by allowing more time for comment, it
decide on a longer Last-Call period or to explicitly lengthen
current Last-Call period
The IESG is not bound by the action recommended when
specification was submitted. For example, the IESG may decide
consider the specification for publication in a different
than that requested. If the IESG determines this before the Last
Call is issued then the Last-Call should reflect the IESG's view
The IESG could also decide to change the publication category
on the response to a Last-Call. If this decision would result in
specification being published at a "higher" level than the
Last-Call was for, a new Last-Call should be issued indicating
IESG recommendation. In addition, the IESG may decide to
the formation of a new Working Group in the case of
controversy in response to a Last-Call for specification
originating from an IETF Working Group
In a timely fashion after the expiration of the Last-Call period,
IESG shall make its final determination of whether or not to
the standards action, and shall notify the IETF of its decision
electronic mail to the IETF Announce mailing list
6.1.3
If a standards action is approved, notification is sent to the
Editor and copied to the IETF with instructions to publish
specification as an RFC. The specification shall at that point
removed from the Internet-Drafts directory
Bradner Best Current Practice [Page 19]
RFC 2026 Internet Standards Process October 1996
An official summary of standards actions completed and pending
appear in each issue of the Internet Society's newsletter.
shall constitute the "publication of record" for Internet
actions
The RFC Editor shall publish periodically an "Internet
Protocol Standards" RFC [1], summarizing the status of all
protocol and service specifications
6.2 Advancing in the Standards
The procedure described in section 6.1 is followed for each
that attends the advancement of a specification along the
track
A specification shall remain at the Proposed Standard level for
least six (6) months
A specification shall remain at the Draft Standard level for at
four (4) months, or until at least one IETF meeting has occurred
whichever comes later
These minimum periods are intended to ensure adequate opportunity
community review without severely impacting timeliness.
intervals shall be measured from the date of publication of
corresponding RFC(s), or, if the action does not result in
publication, the date of the announcement of the IESG approval of
action
A specification may be (indeed, is likely to be) revised as
advances through the standards track. At each stage, the IESG
determine the scope and significance of the revision to
specification, and, if necessary and appropriate, modify
recommended action. Minor revisions are expected, but a
revision may require that the specification accumulate
experience at its current maturity level before progressing. Finally
if the specification has been changed very significantly, the
may recommend that the revision be treated as a new document, re
entering the standards track at the beginning
Change of status shall result in republication of the
as an RFC, except in the rare case that there have been no changes
all in the specification since the last publication. Generally
desired changes will be "batched" for incorporation at the next
in the standards track. However, deferral of changes to the
standards action on the specification will not always be possible
desirable; for example, an important typographical error, or
technical error that does not represent a change in overall
Bradner Best Current Practice [Page 20]
RFC 2026 Internet Standards Process October 1996
of the specification, may need to be corrected immediately. In
cases, the IESG or RFC Editor may be asked to republish the RFC (
a new number) with corrections, and this will not reset the
time-at-level clock
When a standards-track specification has not reached the
Standard level but has remained at the same maturity level
twenty-four (24) months, and every twelve (12) months
until the status is changed, the IESG shall review the viability
the standardization effort responsible for that specification and
usefulness of the technology. Following each such review, the
shall approve termination or continuation of the development effort
at the same time the IESG shall decide to maintain the
at the same maturity level or to move it to Historic status.
decision shall be communicated to the IETF by electronic mail to
IETF Announce mailing list to allow the Internet community
opportunity to comment. This provision is not intended to threaten
legitimate and active Working Group effort, but rather to provide
administrative mechanism for terminating a moribund effort
6.3 Revising a
A new version of an established Internet Standard must
through the full Internet standardization process as if it were
completely new specification. Once the new version has reached
Standard level, it will usually replace the previous version,
will be moved to Historic status. However, in some cases
versions may remain as Internet Standards to honor the
of an installed base. In this situation, the relationship
the previous and the new versions must be explicitly stated in
text of the new version or in another appropriate document (e.g.,
Applicability Statement; see section 3.2).
6.4 Retiring a
As the technology changes and matures, it is possible for a
Standard specification to be so clearly superior technically that
or more existing standards track specifications for the same
should be retired. In this case, or when it is felt for some
reason that an existing standards track specification should
retired, the IESG shall approve a change of status of the
specification(s) to Historic. This recommendation shall be
with the same Last-Call and notification procedures used for
other standards action. A request to retire an existing standard
originate from a Working Group, an Area Director or some
interested party
Bradner Best Current Practice [Page 21]
RFC 2026 Internet Standards Process October 1996
6.5 Conflict Resolution and
Disputes are possible at various stages during the IETF process.
much as possible the process is designed so that compromises can
made, and genuine consensus achieved, however there are times
even the most reasonable and knowledgeable people are unable
agree. To achieve the goals of openness and fairness, such
must be resolved by a process of open review and discussion.
section specifies the procedures that shall be followed to deal
Internet standards issues that cannot be resolved through the
processes whereby IETF Working Groups and other Internet
Process participants ordinarily reach consensus
6.5.1 Working Group
An individual (whether a participant in the relevant Working Group
not) may disagree with a Working Group recommendation based on his
her belief that either (a) his or her own views have not
adequately considered by the Working Group, or (b) the Working
has made an incorrect technical choice which places the
and/or integrity of the Working Group's product(s) in
jeopardy. The first issue is a difficulty with Working
process; the latter is an assertion of technical error. These
types of disagreement are quite different, but both are handled
the same process of review
A person who disagrees with a Working Group recommendation
always first discuss the matter with the Working Group's chair(s),
who may involve other members of the Working Group (or the
Group as a whole) in the discussion
If the disagreement cannot be resolved in this way, any of
parties involved may bring it to the attention of the
Director(s) for the area in which the Working Group is chartered
The Area Director(s) shall attempt to resolve the dispute
If the disagreement cannot be resolved by the Area Director(s) any
the parties involved may then appeal to the IESG as a whole.
IESG shall then review the situation and attempt to resolve it in
manner of its own choosing
If the disagreement is not resolved to the satisfaction of
parties at the IESG level, any of the parties involved may appeal
decision to the IAB. The IAB shall then review the situation
attempt to resolve it in a manner of its own choosing
Bradner Best Current Practice [Page 22]
RFC 2026 Internet Standards Process October 1996
The IAB decision is final with respect to the question of whether
not the Internet standards procedures have been followed and
respect to all questions of technical merit
6.5.2 Process
This document sets forward procedures required to be followed
ensure openness and fairness of the Internet Standards Process,
the technical viability of the standards created. The IESG is
principal agent of the IETF for this purpose, and it is the IESG
is charged with ensuring that the required procedures have
followed, and that any necessary prerequisites to a standards
have been met
If an individual should disagree with an action taken by the IESG
this process, that person should first discuss the issue with
ISEG Chair. If the IESG Chair is unable to satisfy the
then the IESG as a whole should re-examine the action taken,
with input from the complainant, and determine whether any
action is needed. The IESG shall issue a report on its review of
complaint to the IETF
Should the complainant not be satisfied with the outcome of the
review, an appeal may be lodged to the IAB. The IAB shall then
the situation and attempt to resolve it in a manner of its
choosing and report to the IETF on the outcome of its review
If circumstances warrant, the IAB may direct that an IESG decision
annulled, and the situation shall then be as it was before the
decision was taken. The IAB may also recommend an action to the IESG
or make such other recommendations as it deems fit. The IAB may not
however, pre-empt the role of the IESG by issuing a decision
only the IESG is empowered to make
The IAB decision is final with respect to the question of whether
not the Internet standards procedures have been followed
6.5.3 Questions of Applicable
Further recourse is available only in cases in which the
themselves (i.e., the procedures described in this document)
claimed to be inadequate or insufficient to the protection of
rights of all parties in a fair and open Internet Standards Process
Claims on this basis may be made to the Internet Society Board
Trustees. The President of the Internet Society shall
such an appeal within two weeks, and shall at the time
acknowledgment advise the petitioner of the expected duration of
Trustees' review of the appeal. The Trustees shall review
Bradner Best Current Practice [Page 23]
RFC 2026 Internet Standards Process October 1996
situation in a manner of its own choosing and report to the IETF
the outcome of its review
The Trustees' decision upon completion of their review shall be
with respect to all aspects of the dispute
6.5.4 Appeals
All appeals must include a detailed and specific description of
facts of the dispute
All appeals must be initiated within two months of the
knowledge of the action or decision to be challenged
At all stages of the appeals process, the individuals or
responsible for making the decisions have the discretion to
the specific procedures they will follow in the process of
their decision
In all cases a 