This informal guide to the Internet Engineering Task Force (IETF) standards process aims to assist IETF participants by providing an introduction to the variety of documents that describe it, as well as related groups and processes.
This guide is updated irregularly and may be out of date when you read it if new official documents have appeared recently. Please refer to the various RFCs, Internet Engineering Steering Group (IESG) Statements, or discuss with Working Group chairs or Area Directors for current official guidance.
The IETF makes the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. IETF specifications are published as RFCs. The IETF standards process, related processes, and the groups that guide and oversee them are also defined in RFCs—many of which are further codified as Best Current Practices (BCPs)—and statements by the Internet Engineering Steering Group.
Formally, IETF processes are described in Best Current Practices (BCPs), which are defined by one or more RFCs. Both BCPs and RFCs are assigned numbers, with BCPs sometimes updated to include a new set of RFCs as older RFCs are updated or obsoleted. RFC numbers rather than BCP numbers have been used here for convenient lookup and to clarify which RFC is current for a particular topic as of the last update to this guide.
BCP 9 (RFC2026) has been the basis for the IETF standards process for many years. However, many other process documents exist, some of which are partial updates to BCP 9. This situation is complicated and it is difficult to linearize the IETF standards process. This guide offers one structured way of looking at the official documents. But that is not intended to imply priority or importance, and it cannot capture all interactions between components involved in the IETF standardization process.
To avoid any accidental ambiguity, this guide does not attempt to paraphrase or summarize the contents of listed documents.
No single document formally covers the flow of work in the IETF. The Tao of the IETF offers most of it informally:
The RFC Series Editor oversees the publication of RFCs. All RFCs start as Internet-Drafts (I-Ds). Many I-Ds do not become RFCs. Only some RFCs define standards; an RFC may be informational, experimental, or have another non-standard status.
While only the IESG may submit I-Ds for publication as Standard Track RFCs, the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), or the Independent Submissions Editor (ISE) may submit I-Ds for publication in their own RFC streams. Non-Standards Track RFCs may be classified as Informational or Experimental. RFCs that have been superseded by more recent specifications may be designated as Historic. A distinction between obsolete and deprecated documents is not currently made in the IETF.
The main document defining the IETF standards process is “The Internet Standards Process -- Revision 3” [RFC2026]. Numerous documents have amended RFC2026, and some these have been amended or replaced in their turn. One of these updates has been to refine Standards-Track RFCs maturity to two levels: Proposed Standard and Internet Standard.
These are described in RFC 2026 as amended by RFC 6410, covering standards track, BCP and Experimental documents. The STD (standard) designation is documented in [RFC1311]. A consolidated list of standards documents is published on the RFC Editor website. Further details about specifics are available:
Variance procedures for down-level normative references
A specific process for advancing management information base (MIB) documents
A specific process for advancing metric documents
Documentation of implementation status
The formal process of reviewing and approving specifications intended to become standards is currently defined by two documents that must be read together:
Other documents provide additional details about other components of the review and approval process.
Various review teams exist in different IETF Areas, each with their own technical criteria. Many of these are organized as IETF Directorates (e.g. Transport Area Review Team, Security Area Directorate, General Area Review Team), a list of which is available on the IETF Datatracker.
The Internet Engineering Steering Group (IESG) is responsible for the final review of IETF documents. Members of the IESG have the option, when they review a document, of stating a “DISCUSS” position. The DISCUSS identifies one or more issues that must be discussed in relation to the document before the document can become an RFC. Further details:
The IETF standards process provides a mechanism for filing disclosures regarding Intellectual Property Rights (IPR). The IETF Note Well summarizes policies in effect for IETF participation and contributions. The IETF Trust holds and manages the intellectual property rights involved in the IETF standards process.
Rights in Contributions (copyrights)
The IETF Trust legal provisions provide additional detail about how the trust carries out its IPR responsibilities.
Additional information about Management Information Base (MIB) related documents
Rights in Technology (patents)
Promoting compliance with IPR policies and sanctions for violating them
There are several RFCs that describe the various groups involved in the process and how they operate.
Internet Engineering Task Force
Internet Engineering Steering Group (IESG)
Internet Architecture Board
The IAB acts as representative of the interests of the IETF and the Internet Society in technical liaison relationships with other organizations concerned with standards and other technical and organizational issues relevant to the world-wide Internet.
Relationship to the Internet Society (ISOC)
Internet Research Task Force
The Internet Research Task Force (IRTF) is quite separate from the IETF and not directly involved in the standards process, but information about it may provide useful context as it publishes its own stream of RFCs.
Since much of the work in the IETF is conducted on mailing lists, a number of RFCs address that context.
The anti-harassment policy is described in the IESG's Statement in RFC 8716, “Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC”
General information about the RFC Series and RFC Editor
Information about IAB stream RFCs
Information about Independent Submissions to the RFC Editor
Information about IRTF submissions to the RFC Editor
Format and mechanics for Internet-Drafts
Format and mechanics for RFCs
Those writing specifications and standards may also find the following useful:
Formal agreement and roles
Guidelines for RFC authors
RFC 2026 defines how process BCPs are discussed and approved. Experiments in process changes are possible.
This document was originally created and edited by Brian Carpenter. Useful comments have been made by: Harald Alvestrand, Scott Bradner, Spencer Dawkins, Leslie Daigle, John Klensin, Paul Hoffman, and others.