The IETF process: an informal guide

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.

1. Introduction

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.

2. The guide

2.1. General description of workflow in the IETF

No single document formally covers the flow of work in the IETF. The Tao of the IETF offers most of it informally:

  • How ideas for new work enter the IETF  [RFC6771].
  • How they reach a Birds-of-a-Feather (BOF) meeting [RFC5434].
  • How they enter formal discussion and possibly become material for a new or existing Working Group (WG).
  • How WGs are chartered and managed—the WG Chair's and Area Director's roles.
  • How specific proposals become drafts and flow through the development, review and approval process [RFC7221]. 

2.2. Document types

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. 

2.3. Standards track documents

Technical Specifications
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

  • [RFC3967] Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level
  • [RFC4897] Handling Normative References to Standards-Track Documents
  • [RFC8067] Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level

A specific process for advancing management information base (MIB) documents

  • [RFC2438] Advancement of MIB specifications on the IETF Standards Track

A specific process for advancing metric documents

  • [RFC6576] IP Performance Metrics (IPPM) Standard Advancement Testing

Documentation of implementation status

  • [RFC7942] Improving Awareness of Running Code: The Implementation Status Section

2.4. Review and approval process

The formal process of reviewing and approving specifications intended to become standards is currently defined by two documents that must be read together:

  • [RFC2026] The Internet Standards Process -- Revision 3
  • [RFC6410] Reducing the Standards Track to Two Maturity Levels

Other documents provide additional details about other components of the review and approval process.

  • [RFC4858] Document Shepherding from Working Group Last Call to Publication
  • [RFC5657] Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard
  • [RFC8789] IETF Stream Documents Require IETF Rough Consensus

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:

2.5. Intellectual Property Rights (IPR)

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)

  • [RFC5378] Rights Contributors Provide to the IETF Trust
  • [RFC8721] Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents

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

  • [RFC4181] Guidelines for Authors and Reviewers of MIB Documents
  • [RFC4841] RFC 4181 Update to Recognize the IETF Trust

Rights in Technology (patents) 

  • [RFC8179] Intellectual Property Rights in IETF Technology

Trademarks

  • [RFC5378] Rights Contributors Provide to the IETF Trust

Promoting compliance with IPR policies and sanctions for violating them

  • [RFC6701] Sanctions Available for Application to Violators of IETF IPR Policy
  • [RFC6702] Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules

2.6. Bodies involved in the process

There are several RFCs that describe the various groups involved in the process and  how they operate.

Internet Engineering Task Force

  • [RFC2028] The Organizations Involved in the IETF Standards Process
  • [RFC3233] Defining the IETF 
  • [RFC3935] A Mission Statement for the IETF
  • [RFC2418] IETF Working Group Guidelines and Procedures 
  • [RFC4858] Document Shepherding from Working Group Last Call to Publication
  • [RFC7282] On Consensus and Humming in the IETF
  • [RFC7649] The Jabber Scribe Role at IETF Meetings

Internet Engineering Steering Group (IESG)

  • [RFC3710] An IESG Charter
  • [RFC7475] Increasing the Number of Area Directors in an IETF Area

Internet Architecture Board

  • [RFC2850] Charter of the Internet Architecture Board (IAB)

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.

  • [RFC4052] IAB Processes for Management of IETF Liaison Relationships
  • [RFC4053] Procedures for Handling Liaison Statements to and from the IETF
  • [RFC4691] Guidelines for Acting as an IETF Liaison to Another Organization

Nominating Committee 

  • [RFC8713] IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees
  • [RFC8788] on Eligibility for the 2020-2021 Nominating Committee

Relationship to the Internet Society (ISOC) 

  • [RFC8712]  The IETF-ISOC Relationship
  • [RFC3677] IETF ISOC Board of Trustee Appointment Procedures

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.

2.7. Conduct of participants

  • [RFC7154], IETF Guidelines for Conduct

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”

  • Conduct is also discussed in the Tao of the IETF
  • [RFC3005] IETF Discussion List Charter
  • [RFC3683] A Practice for Revoking Posting Rights to IETF Mailing Lists
  • [RFC3934], Updates to RFC 2418 Regarding the Management of IETF Mailing Lists
  • [RFC4633] Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists
  • The appeal process is described in RFC 2026.

2.8. Publication process

General information about the RFC Series and RFC Editor

  • [RFC8729] The RFC Series and RFC Editor
  • [RFC8728], RFC Editor Model (Version 2)
  • [RFC7841] RFC Streams, Headers, and Boilerplates

Information about IAB stream RFCs

  • [RFC4845] Process for Publication of IAB RFCs
  • [RFC5745] Procedures for Rights Handling in the RFC IAB Stream

Information about Independent Submissions to the RFC Editor 

  • [RFC8730] Independent Submission Editor Model
  • [RFC4846] Independent Submissions to the RFC Editor
  • [RFC5744] Procedures for Rights Handling in the RFC Independent Submission Stream
  • [RFC5742] IESG Procedures for Handling of Independent and IRTF Stream Submissions

Information about IRTF submissions to the RFC Editor

  • [RFC5743] Definition of an Internet Research Task Force (IRTF) Document Stream
  • [RFC5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions

Format and mechanics for Internet-Drafts

Format and mechanics for RFCs

Those writing specifications and standards may also find the following useful:

  • [RFC2119] Key words for use in RFCs to Indicate Requirement Levels
  • [RFC8174] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
  • [RFC2360] Guide for Internet Standards Writers
  • [RFC8126] Guidelines for Writing an IANA Considerations Section in RFCs
  • [RFC3552] Guidelines for Writing RFC Text on Security Considerations
  • [RFC4775] Procedures for Protocol Extensions and Variations
  • [RFC5704] Uncoordinated Protocol Development Considered Harmful
  • [RFC5706].Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions

2.9. Parameter registration process (IANA)

Formal agreement and roles

  • [RFC2860] Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority
  • [RFC8722] Defining the Role and Function of IETF Protocol Parameter Registry Operators 
  • [RFC8720] Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries

Guidelines for RFC authors

  • [RFC8126] Guidelines for Writing an IANA Considerations Section in RFCs
  • [RFC7120].Early IANA Allocation of Standards Track Code Points

Protocol assignments

2.10. Administration and IETF meetings

  • [RFC8711] Structure of the IETF Administrative Support Activity, Version 2.0
  • [RFC8714], Update to the Process for Selection of Trustees for the IETF Trust
  • [RFC8715], IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust
  • [RFC8717] IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology
  • [RFC8718] IETF Plenary Meeting Venue Selection Process
  • [RFC8719] High-Level Guidance for the Meeting Policy of the IETF

2.11. Modifying the process

RFC 2026 defines how process BCPs are discussed and approved. Experiments in process changes are possible.

3. Acknowledgements

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.

4. Administrivia

  • Revision date: 2020-06-24
  • This document is maintained as part of www.ietf.org
  • Discussion forum: [email protected]