The IETF process: an informal guide

This document is an informal guide to various IETF process documents, intended mainly to assist IETF participants in navigating the labyrinth. It may be out of date when you read it, if new documents have appeared recently.

Key Info

Please refer to the various RFCs, IESG Statements, or discuss with Working Group chairs or Area Directors for official guidance.

1. Introduction

BCP 9 (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, so the present document offers a structured way of looking at the official documents. It may be out of date when you read it, if new official documents have appeared recently.

It is difficult to linearise a complicated and interlocked process. This document presents a guide in one particular order, but that is not intended to imply priority or importance, and it cannot capture all interactions between components.

Formally, IETF processes are described in Best Current Practices (BCPs) published as RFCs. Many of the RFCs mentioned below are BCPs. RFC numbers have been used rather than BCP numbers, for convenient lookup. To avoid any accidental ambiguity, this guide does not attempt to paraphrase or summarize their contents; the reader should consult the original RFCs.

2. The guide

2.1. General description of workflow in the IETF

No single document formally covers this topic, although the Tao of the IETF offers most of it informally:

  • How ideas for new work enter the IETF  [RFC 6771].
  • How they reach a BOF (Birds of a Feather meeting) [RFC 5434].
  • How they enter formal discussion and possibly become material for a new or existing Working Group.
  • 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 [RFC 7221]. 

2.2. Definition of standards track and related document types

The main document is RFC 2026. Numerous documents have amended this one, and some have been amended or replaced in their turn. All these amendments are reflected below. A very significant change was introduced in 2011, reducing the standards track to two maturity levels: [RFC 6410] and [RFC 7127]. 

Consolidated lists of standards documents used to published as RFCs, but this is no longer the case; the information is on line at the RFC Editor website

Additional requirements for routing protocols were previously defined in RFC 1264, but this is now obsolete. It should be noted that practice and interpretation have grown around the documented rules; the Tao of the IETF is helpful in this respect.

  • 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 RFC 1311
    Variance procedures for down-level normative references are in 
    RFC 3967,
    RFC 4897, and
    RFC 8067
    A specific process for advancing MIB documents is in 
    [RFC 2438]. 
    A specific process for advancing metric documents is in 
    RFC 6576
    Implementation status may be documented according to 
    [RFC 7942].
  • Informational Material 
    RFC 2026 also describes Informational and Historic documents. A distinction between obsolete and deprecated documents is not currently made in the IETF.

2.3. Intellectual Property Rights (IPR)

2.4. Review and approval process

The formal process is currently defined by two documents that must be read together: 
RFC 2026
RFC 6410.

  • Interoperability reports (optional) 
    RFC 5657.

2.5. Bodies involved in the process

The Internet Research Task Force (IRTF) is quite separate from the IETF: 
RFC 2014
RFC 7418.

2.6. Conduct of participants

See 
RFC 3005
RFC 7154
RFC 3683
RFC 3934
RFC 4633

Conduct is also discussed in the Tao of the IETF and in 
RFC 2418.

  • The anti-harassment policy is described in the IESG's Statement in RFC 7776

    /blog/ietf-anti-harassment-policy/

  • The appeal process is described in RFC 2026.

2.7. Publication process

2.8. Parameter registration process (IANA)

2.9. Administration

See 
RFC 4071
RFC 4371
RFC 4333,
RFC 7691.

2.10. Modifying the process

RFC 2026 defines how process BCPs are discussed and approved. An experimental procedure is described in 
[RFC 3933]. 
Also see the IESG note about process experiments.

3. Acknowledgements

Useful comments on this document were made by: Harald Alvestrand, Scott Bradner, Spencer Dawkins, Leslie Daigle, John Klensin, Paul Hoffman, and others.

This document was produced using the xml2rfc tool defined in RFC 2629 .

4. Change log

Updated with RFC 7649, 7776, 7691, 8067, 8174, 8179, 8126, 2018-01-30
Removed section 5. References 2018-01-24
Updated references to 6982 with references to 7942 (BCP 205); fixed links broken with move to new website at www.ietf.org 2018-01-14
Updated with RFC 7282, 7322, 7437, 7418, 7475, 7500, other tweaks, 2015-08-25. 
Updated with RFC 6982, 7120, 7127, 7154, 7221, took account of RFC 7100, 7101, other tweaks, 2014-05-07. 
Updated with RFC 6771, 6859, 2013-01-22. 
Updated with RFC 6576, 6701, 6702, 2012-09-04. 
Updated with RFC 6635, 2012-06-12. 
Updated with RFC 5657, 6220, 6410, 2011-10-11. 
Updated with RFC 4775, 5704, 5706, 5741-45, and various format cleanups, 2011-02-14. 
Updated with RFC 5680, 2009-10-29. 
Updated with RFC 5226, 5377, 5378, 5434, 5633, 5620, 5633, draft-dawkins-nomcom-openlist, 2009-10-23. 
Reformatted as an ad hoc web page at conclusion of ION experiment, cited RFC 4228, 4844-46, 5078, 2008-04-14. 
DRAFT ion-procdocs 2007-06-27: cited RFC 4897, 4879, 4181, 4841, 4858. 
DRAFT ion-procdocs 2007-02-14: public comments incorporated 
DRAFT ion-procdocs 2007-01-29: converted to ION format 
draft-carpenter-procdoc-roadmap-05: Earlier drafts of this document included references to drafts proposing changes to the standards process. These have been removed to make this document a more stable reference. It has been renamed from "roadmap" to "guide." Some editorial rearrangements have been made. 2006-08-02 
draft-carpenter-procdoc-roadmap-04: minor additions, tuned Abstract and Introduction, 2006-02-20 
draft-carpenter-procdoc-roadmap-03: minor additions, 2005-12-20 
draft-carpenter-procdoc-roadmap-02: minor additions, 2005-10-11 
draft-carpenter-procdoc-roadmap-01: minor additions, 2005-09-20 
draft-carpenter-procdoc-roadmap-00: original version, 2005-08-22

Administrivia

  • Revision date: 2018-01-30
  • Document editor: Brian Carpenter
  • Now maintained as part of www.ietf.org
  • Discussion forum: ietf@ietf.org

Bibliography

  • [1] RFC 2026
    The Internet Standards Process -- Revision 3

    This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document spec...

  • [2] RFC 6771
    Considerations for Having a Successful "Bar BOF" Side Meeting

    New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official statu...

    Gonzalo Camarillo

  • [3] RFC 5434
    Considerations for Having a Successful Birds-of-a-Feather (BOF) Session

    This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. [STANDARDS-TRACK]

    Dr. Thomas Narten

  • [4] RFC 7221
    Handling of Internet-Drafts by IETF Working Groups

    The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group ado...

    Adrian Farrel, Dave Crocker

  • [5] RFC 2026
    The Internet Standards Process -- Revision 3

    This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document spec...

  • [6] RFC 6410
    Reducing the Standards Track to Two Maturity Levels

    This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.

    Dave Crocker, Eric Burger, Russ Housley

  • [7] RFC 7127
    Characterization of Proposed Standards

    RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards.

    Olaf M. Kolkman

  • [8] RFC 1311
    Introduction to the STD Notes

    The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS-TRACK]

  • [9] RFC 3967
    Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level

    IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies). For example, a standards track document...

    Dr. Thomas Narten, Randy Bush

  • [10] RFC 4897
    Handling Normative References to Standards-Track Documents

    The Internet Engineering Task Force (IETF) and Request for Comments (RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher. This rule has sometimes result...

    Dr. John C. Klensin

  • [11] RFC 8067
    Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level

    RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels ("downrefs"), which involves calling out the downref explicitly in the Last Call notice. That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the I...

  • [12] RFC 2438
    Advancement of MIB specifications on the IETF Standards Track

    This document specifies the process which the IESG will use to determine if a MIB specification document meets these requirements. It also discusses the rationale for this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and...

    Michael D. O'Dell

  • [13] RFC 6576
    IP Performance Metrics (IPPM) Standard Advancement Testing

    This document specifies tests to determine if multiple independent instantiations of a performance-metric RFC have implemented the specifications in the same way. This is the performance-metric equivalent of interoperability, required to advance RFCs along the Standards Track. Results from diff...

    Alexander Steinmitz, Al Morton, Reza Fardid, Ruediger Geib

  • [14] RFC 7942
    Improving Awareness of Running Code: The Implementation Status Section

    This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code,...

  • [15] RFC 5378
    Rights Contributors Provide to the IETF Trust

    The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions ...

  • [16] RFC 5377
    Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents

    Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contri...

    Joel M. Halpern

  • [17] RFC 4841
    RFC 4181 Update to Recognize the IETF Trust

    This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

    Mike Heard

  • [18] RFC 4841
    RFC 4181 Update to Recognize the IETF Trust

    This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

    Mike Heard

  • [19] RFC 8179
    Intellectual Property Rights in IETF Technology

    The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as pos...

  • [20] RFC 6701
    Sanctions Available for Application to Violators of IETF IPR Policy

    The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware.

    Adrian Farrel

  • [21] RFC 6702
    Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules

    The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance wit...

  • [22] RFC 4371
    BCP 101 Update for IPR Trust

    This document updates BCP 101 to take account of the new IETF Intellectual Property Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

  • [23] RFC 2026
    The Internet Standards Process -- Revision 3

    This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document spec...

  • [24] RFC 6410
    Reducing the Standards Track to Two Maturity Levels

    This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice.

    Dave Crocker, Eric Burger, Russ Housley

  • [25] RFC 4858
    Document Shepherding from Working Group Last Call to Publication

    This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for pu...

    Allison J. Mankin, David Meyer, Henrik Levkowetz

  • [26] RFC 5657
    Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard

    Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes a...

    Lisa M. Dusseault, Robert Sparks

  • [27] RFC 2028
    The Organizations Involved in the IETF Standards Process

    This document describes the individuals and organizations involved in the IETF. This includes descriptions of the IESG, the IETF Working Groups and the relationship between the IETF and the Internet Society. This document specifies an Internet Best Current Practices for the Internet Community, ...

    Richard Hovey

  • [28] RFC 3233
    Defining the IETF

    This document gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. This document specifies an...

    Paul E. Hoffman

  • [29] RFC 3935
    A Mission Statement for the IETF

    This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document spe...

    Harald T. Alvestrand

  • [30] RFC 2418
    IETF Working Group Guidelines and Procedures

    This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

  • [31] RFC 7282
    On Consensus and Humming in the IETF

    The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosop...

  • [32] RFC 7649
    The Jabber Scribe Role at IETF Meetings

    During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers are commonly called "Jabber scribes". This document summarizes experience with the Jabbe...

    Dan York

  • [33] RFC 3710
    An IESG charter

    This memo provides a charter for the Internet Engineering Steering Group (IESG), a management function of the Internet Engineering Task Force (IETF). It is meant to document the charter of the IESG as it is presently understood. This memo provides information for the Internet community.

    Harald T. Alvestrand

  • [34] RFC 7475
    Increasing the Number of Area Directors in an IETF Area

    This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).

    Spencer Dawkins

  • [35] RFC 2850
    Charter of the Internet Architecture Board (IAB)

    This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

  • [36] RFC 4052
    IAB Processes for Management of IETF Liaison Relationships

    This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers an...

  • [37] RFC 4053
    Procedures for Handling Liaison Statements to and from the IETF

    This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedur...

    Stephen Trowbridge

  • [38] RFC 4691
    Guidelines for Acting as an IETF Liaison to Another Organization

    Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships betwe...

  • [39] RFC 7437
    IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees

    The process by which the members of the IAB and IESG, and some members of the IAOC, are selected, confirmed, and recalled is specified in this document. This document is a self-consistent, organized compilation of the process as it was known at the time of publication of RFC 3777, with various u...

    Murray Kucherawy

  • [40] RFC 8318
    IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: IAOC Advisor for the Nominating Committee

    This specification formalizes an ad hoc practice used to provide advice to the IETF Nominating Committee (NomCom) about the operations of the IETF Administrative Oversight Committee (IAOC).

  • [41] RFC 2031
    IETF-ISOC relationship

    This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary. This memo provides information for the Internet community. ...

    Dr. Erik Huizer

  • [42] RFC 3677
    IETF ISOC Board of Trustee Appointment Procedures

    This memo outlines the process by which the IETF makes a selection of an Internet Society (ISOC) Board of Trustees appointment.

  • [43] RFC 2014
    IRTF Research Group Guidelines and Procedures

    This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). This document specifies an ...

    Dr. Abel Weinrib, Dr. Jon Postel

  • [44] RFC 7418
    An IRTF Primer for IETF Participants

    This document provides a high-level description of things for Internet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the Internet Research Task Force (IRTF). This document emphasizes differences in expectations between the two o...

    Spencer Dawkins

  • [45] RFC 3005
    IETF Discussion List Charter

    The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through discussion of technical issues, and hosts discussions of IETF direction, policy, meetings, and procedures. As this is the most general IETF mailing list, c...

    Susan R. Harris

  • [46] RFC 7154
    IETF Guidelines for Conduct

    This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.

    S Moonesamy

  • [47] RFC 3683
    A Practice for Revoking Posting Rights to IETF Mailing Lists

    All self-governing bodies have ways of managing the scope of participant interaction. The IETF uses a consensus-driven process for developing computer-communications standards in an open fashion. An important part of this consensus-driven process is the pervasive use of mailing lists for discus...

    Dr. Marshall T. Rose

  • [48] RFC 3934
    Updates to RFC 2418 Regarding the Management of IETF Mailing Lists

    This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. This document specifies an Internet Best Curre...

  • [49] RFC 4633
    Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists

    Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managing Internet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools...

    Sam Hartman

  • [50] RFC 7776
    IETF Anti-Harassment Procedures

    IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.

  • [51] RFC 4844
    The RFC Series and RFC Editor

    This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill ...

  • [52] RFC 6635
    RFC Editor Model (Version 2)

    The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFC Series Editor, the RFC Production Center, and the RFC Publisher. Internet Architecture Board (IAB) oversight via the RFC Series Oversight Committee (RSOC) is described, a...

    Joel M. Halpern, Olaf M. Kolkman

  • [53] RFC 5741
    RFC Streams, Headers, and Boilerplates

    RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is in...

    Olaf M. Kolkman

  • [54] RFC 4845
    Process for Publication of IAB RFCs

    From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC Series. This memo provides information for the Internet community.

  • [55] RFC 5745
    Procedures for Rights Handling in the RFC IAB Stream

    This document specifies the procedures by which authors of RFC IAB stream documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust mana...

  • [56] RFC 4846
    Independent Submissions to the RFC Editor

    There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as "Ind...

    Dave Thaler, Dr. John C. Klensin

  • [57] RFC 5744
    Procedures for Rights Handling in the RFC Independent Submission Stream

    This document specifies the procedures by which authors of RFC Independent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the "outgoing" rights the community grants to readers and users of those documents, and it requests that the IET...

  • [58] RFC 5742
    IESG Procedures for Handling of Independent and IRTF Stream Submissions

    This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams.

    Harald T. Alvestrand, Russ Housley

  • [59] RFC 5743
    Definition of an Internet Research Task Force (IRTF) Document Stream

    This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. This document is not an In...

  • [60] RFC 7322
    RFC Style Guide

    This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that ref...

    Heather Flanagan

  • [61] RFC 2119
    Key words for use in RFCs to Indicate Requirement Levels

    In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the In...

  • [62] RFC 8174
    Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words

    RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

  • [63] RFC 2360
    Guide for Internet Standards Writers

    This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improveme...

    Gregor D. Scott

  • [64] RFC 5226
    Guidelines for Writing an IANA Considerations Section in RFCs

    Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensu...

    Dr. Thomas Narten

  • [65] RFC 3552
    Guidelines for Writing RFC Text on Security Considerations

    All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the In...

    Brian Korver

  • [66] RFC 4775
    Procedures for Protocol Extensions and Variations

    This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocol...

    Dr. Thomas Narten

  • [67] RFC 5704
    Uncoordinated Protocol Development Considered Harmful

    This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robus...

    Monique Morrow

  • [68] RFC 5706
    Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions

    New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that de...

  • [69] RFC 2860
    Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority

    This document places on record the text of the Memorandum of Understanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. This memo provides information for the Internet community.

  • [70] RFC 6220
    Defining the Role and Function of IETF Protocol Parameter Registry Operators

    Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are ...

    Danny R. McPherson, Geoff Huston, Olaf M. Kolkman

  • [71] RFC 7500
    Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries

    This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.

    Olaf Kolkman, Russ Housley

  • [72] RFC 8126
    Guidelines for Writing an IANA Considerations Section in RFCs

    Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF proto...

  • [73] RFC 7120
    Early IANA Allocation of Standards Track Code Points

    This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilita...

    Michelle Cotton

  • [74] RFC 4071
    Structure of the IETF Administrative Support Activity (IASA)

    This document describes the structure of the IETF Administrative Support Activity (IASA) as an activity housed within the Internet Society (ISOC). It defines the roles and responsibilities of the IETF Administrative Oversight Committee (IAOC), the IETF Administrative Director (IAD), and ISOC in ...

    Rob Austein

  • [75] RFC 4333
    The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process

    This memo outlines the guidelines for selection of members of the IETF Administrative Oversight Committee, and describes the selection process used by the IAB and the IESG. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggesti...

    Geoff Huston

  • [76] RFC 7691
    Updating the Term Dates of IETF Administrative Oversight Committee (IAOC) Members

    BCP 101 defines the start and end dates for the terms of IETF Administrative Oversight Committee (IAOC) members; these terms have proven to be impractical. This memo updates BCP 101 to direct the IAOC to establish more practical start and end dates for terms of IAOC members.

  • [77] RFC 3933
    A Model for IETF Process Experiments

    The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often...

    Dr. John C. Klensin

  • [78] RFC 2629
    Writing I-Ds and RFCs using XML

    This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.

    Dr. Marshall T. Rose