网页
综合
更新时间 2026-11-15 01:05:12
IETF | Informal guide to IETF process documents
自动蜘蛛
www.ietf.org
正文约 6000 字
The IETF works on a broad range of networking technologies that provide the foundation for the Internet's growth and evolution.
While most IETF work takes place online, meetings and other events such as Hackathons provide in-person opportunities to advance work within the IETF.
The IETF is the premier Internet standards organization. It follows open and well-documented processes for setting these standards. Once published, those standards are made freely available.
The global IETF community works together in many different ways to produce high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
By supporting the IETF today, you are ensuring a free and open Internet exists tomorrow.
This informal guide to documents about 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 informal guide to documents about 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 latest 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 mainly 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. There are also some process guidelines published as Informational RFCs.
BCP 9 (originally RFC 2026) 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 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 describes the entire flow of work in the IETF, but the website largely does so — see the Process sidebar. Here are some key points to consider:
The RFC Editor service 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 approve I-Ds for publication as Standard Track RFCs, the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), the Independent Submissions Editor (ISE) and the RFC Series Approval Board (RSAB) approve 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.
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
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
本页为82搜索生成的网页快照,内容来自站内索引;演示数据的原文链接仅作示例。