RFC 9281

Entities Involved in the IETF Standards Process

📅 published June 2022, from ietf

Entities Involved in the IETF Standards Process 🎀

Title block: This is RFC 9281, a Best Current Practice (it's BCP 11 💅). The author is R. Salz from Akamai Technologies, it was published in June 2022, and it's listed under ISSN 2070-1721. It obsoletes RFC 2028 (the old version of this same doc 👀). The header doesn't list anything it updates.

Abstract 💖

Okay so this doc is all about the people and orgs that make the IETF standards process work, as described in BCP 9 🧚. It gives you quick, friendly descriptions of each entity and what they actually do in the process. Main character energy 👑.

The IETF and its structure have changed a LOT since RFC 2028 came out in 1996 😭. This document reflects the new org structure and replaces RFC 2028 🦋.

Status of This Memo 📝

This memo documents an Internet Best Current Practice. ✨

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🫶. If you want more info on BCPs, check out Section 2 of RFC 7841 🌈.

Info about the current status of this document, any errata, and how to give feedback can be found at https://www.rfc-editor.org/info/rfc9281 💜.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please actually read these, bestie, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License 💅.

Table of Contents 📚

1.  Introduction
  1.1.  Terminology
  1.2.  Changes since RFC 2028
2.  Key Individuals in the Process
  2.1.  Document Editor or Author
  2.2.  Working Group Chair
  2.3.  Area Director
3.  Key Organizations in the Process
  3.1.  Internet Engineering Task Force (IETF)
  3.2.  Working Groups (WGs)
  3.3.  Internet Engineering Steering Group (IESG)
  3.4.  Internet Architecture Board (IAB)
  3.5.  RFC Production Center (RPC)
  3.6.  Internet Assigned Numbers Authority (IANA)
  3.7.  Internet Research Task Force (IRTF)
  3.8.  IETF Trust
  3.9.  IETF Administration LLC (IETF LLC)
  3.10. IETF Secretariat
  3.11. Internet Society (ISOC)
4.  Security Considerations
5.  IANA Considerations
6.  Informative References
Acknowledgements
Author's Address

1. Introduction 🦋

So the IETF community has a process for standardizing protocols and procedures, and it's written up in BCP 9 [IETFPROCS] 📖. BCP 9 covers the stages of standardization, what has to happen to move a document between stages, and the types of documents used along the way. This doc is here to introduce some of the key individual roles and orgs in all that 💕.

1.1. Terminology 🧸

This document talks about individual roles in the singular, like "a document editor." 🙃 Real life is messier, though, since lots of these roles are filled by more than one person at the same time. To keep things clear, this document doesn't use phrases like "chair (or co-chair)" ✨.

1.2. Changes since RFC 2028 🔥

Here's what's changed since RFC 2028, in no particular order 🌈:

  • Added the role of responsible area director (AD) and reordered Section 2 to follow the typical workflow.
  • Added the IETF Administration LLC and the IETF Trust to Section 3.
  • Changed "RFC Editor" to "RFC Production Center" to reflect the changes made by [RFCEDMODEL] 🍓.
  • Added the Terminology and Acknowledgements sections.
  • Cleaned up some wording throughout the document 💅.

2. Key Individuals in the Process 👑

This section describes the individual roles involved in the process. It tries to list them in the order they show up in the process, without implying that any one of them matters more than the others 🫶.

2.1. Document Editor or Author ✍️

Most working groups (WGs) focus their efforts on one or more documents that capture what they've produced. The WG chair picks one or more people to be the editor(s) for a particular document 💜. The editor is responsible for making sure the document accurately reflects the decisions the WG has made 🎯.

When a document is mostly composed and edited by one or more individuals, they may be called "document authors" 🌸. The distinction doesn't matter for the standards process, and this document uses the term "document editor" ✨.

When a document editor is also a chair of the same WG, another chair should manage the process around the document. If there's no other chair available, the WG and AD must monitor the process especially carefully, so the documents accurately reflect the WG's consensus and every process gets followed 🙈. This is a shared responsibility for everyone involved with the document 🫶.

2.2. Working Group Chair 🎀

Each WG has a chair, and the chair is in charge of facilitating the group's activities, running its meetings, and making sure the group meets its commitments for its role in the Internet standards process 💅. Most importantly, the WG chair is the formal point of contact between the WG and the Internet Engineering Steering Group (IESG), through the AD of the area the WG belongs to 🦋.

Everything about picking and running a WG chair is in [WGPROCS] 📖.

2.3. Area Director 🌟

Each WG gets assigned one responsible area director (AD) 👑. The AD can help the WG chair figure out consensus and carry out the process 🧚. The AD also reviews documents after the WG has approved them, and once they're satisfied, the AD coordinates the IESG review and the IETF Last Call for the document 💖.

An AD can also sponsor an Internet-Draft directly, but that's not very common. When it happens, no WG is involved 🙃.

Except for the General Area, IETF areas usually have multiple ADs 🌈.

3. Key Organizations in the Process 🏢

The following organizations and organizational roles are involved in the Internet standards process 💕.

3.1. Internet Engineering Task Force (IETF) 🌍

The IETF is an open, international community of network designers, operators, implementors, researchers, and other interested folks who care about how the Internet architecture evolves and how the Internet keeps running smoothly 🌐. It's the main body that develops new Internet Standard specifications and related documents, so honestly it's iconic 👑.

3.2. Working Groups (WGs) 🛠️

The IETF's technical work happens in its WGs. They're organized by topic into several areas (https://www.ietf.org/topics/areas/), and each area is coordinated by an AD ✨. WGs usually have a narrow focus and a lifetime that ends when their specific tasks, as laid out in their charter and milestones, are done 🦋. Some WGs are long-lived and exist to keep maintaining IETF protocol(s) 🧸. There are also "dispatch" WGs, which figure out where new work in the IETF should happen, but they don't directly produce standards 👀.

For every purpose that matters to the Internet Standards development process, membership in the IETF and its WGs is defined as being established solely and entirely by individuals who take part in IETF and WG activities 💜. These individuals don't formally represent any organizations they might be affiliated with, although affiliations are often used for identification 🫶.

Anyone with the time and interest is entitled and urged to actively take part in one or more WGs and to attend IETF meetings, which usually happen three times a year [MEETINGS] ✈️. A WG can also schedule interim meetings (virtual, in-person, or hybrid), which get scheduled and announced to the entire WG 📅. You can be an active WG participant without ever going to an in-person meeting 🌸.

Participants in the IETF and its WGs must disclose any relevant current or pending intellectual property rights that they reasonably and personally know about if they join discussions about a specific technology 🔒. The full intellectual property policy is defined in [IPRRIGHTS1] and [IPRRIGHTS2] 📜.

New WGs are established by the IESG and almost always come with a specific and explicit charter 🎀. The charter can change as the WG progresses. The guidelines and procedures for forming and operating WGs are described in detail in [WGPROCS] 💅.

A WG is managed by a WG chair, as described in Section 2.2. Documents the group produces have an editor, as described in Section 2.1. More details on how WGs operate are in [WGPROCS] 🧚.

WGs ideally show a spirit of cooperation and a high degree of technical maturity 🌈. IETF participants know that the biggest benefit for everyone in the Internet community comes from working together to develop technically excellent protocols and services 🫶.

3.3. Internet Engineering Steering Group (IESG) 👑

The IESG is responsible for managing the IETF's technical activities 🎯. It runs the Internet Standards process according to the rules and procedures defined in [IETFPROCS] 📖. The IESG handles the actions that move documents along the IETF Stream, including the initial approval of new WGs, any later rechartering, and the final approval of documents ✨.

The IESG is made up of the ADs and the IETF Chair. The IETF Chair also chairs the IESG and is the AD for the General Area 💖. The Chair of the Internet Architecture Board (IAB) is an ex officio member of the IESG 🦋. Various other bodies have liaisons with the IESG, and you can find the full list at <https://www.ietf.org/about/groups/iesg/members/> 🌸.

All IESG members are nominated by a Nominations Committee (colloquially, "NomCom") and confirmed by the IAB 🎀. See [NOMCOM] for a detailed description of NomCom procedures. Other matters about how the NomCom is organized and run are described in the IESG Charter [IESG] 📜.

3.4. Internet Architecture Board (IAB) 🏛️

The IAB oversees the architecture of the Internet and its protocols 🌐. It approves the IESG candidates the NomCom puts forward, and it reviews all proposed IETF WG charters 💅.

The IAB also oversees the standards process and acts as an appeal board for complaints about improper execution [IETFPROCS] ⚖️. More generally, it's a source of advice on technical, architectural, procedural, and policy matters related to the Internet and the technologies that enable it 🧚.

IAB members are nominated by the NomCom and confirmed by the Board of the Internet Society (ISOC) 💜. The IETF Chair is also an IAB member, and the Chair of the Internet Research Task Force (IRTF) is an ex officio member 🫶. Other matters about the IAB's organization and operation are described in the IAB Charter [IAB] 📖✨.

3.5. RFC Production Center (RPC) 🎀

okay so editing and publishing RFCs is handled by the RFC Production Center (RPC) 📝 the rules for how RFCs work are set by the RFC Series Working Group (RSWG), which is an open group (kinda like IETF WGs) 🫶 and those rules get approved by the RFC Series Advisory Board (RSAB), which has appointed members 👑 the RFC Series Consulting Editor (RSCE) is a position funded by the IETF Administration LLC, and its responsibilities are defined in [RFCEDMODEL] ✨

if you want the full tea on what the RPC does and its roles and responsibilities, it's all in [RFCEDMODEL], especially Section 4 💅

3.6. Internet Assigned Numbers Authority (IANA) 🦋

okay this one is lowkey so important bestie 🥺 a lot of protocol specs have parameters that need to be uniquely assigned, like port numbers, option identifiers inside a protocol, and things like that 🔢 the Internet Assigned Numbers Authority (IANA) is the one responsible for assigning values to these protocol parameters and maintaining the parameter registries online (https://www.iana.org/protocols) 🌸 assignments get coordinated by writing an "IANA Considerations" section for a given document, as described in [IANADOCS] 📋 the IETF's relationship with IANA is defined by formal agreements, including [IANAMOU] 🤝

IANA is also responsible for operating and maintaining several aspects of the DNS (https://www.iana.org/domains) and for coordinating IP address assignments (https://www.iana.org/numbers) 🌐✨

3.7. Internet Research Task Force (IRTF) 🔬

the IRTF is giving research energy 🧠 it focuses on longer-term research issues related to the Internet, and it's a parallel organization to the IETF, which focuses on the shorter-term stuff: engineering, operations, and specifying standards 💜

the IRTF is made up of research groups (RGs) that are chartered to research different aspects of the broader Internet 🍓 their products are usually research results that get published in scholarly conferences and journals, but they can also be published as RFCs on the IRTF Stream 📚 RGs also sometimes develop experimental protocols or technologies, and some of those might be suitable for possible standardization in the IETF 🧪 IETF WGs sometimes ask RGs for advice or other input too 🫶 however, contributions from RGs generally carry no more weight in the IETF than other community input, and they go through the same standards-setting process as any other proposal 💅 no special VIP treatment, periodt 🙅‍♀️

the IRTF is managed by the IRTF Chair in consultation with the Internet Research Steering Group (IRSG) 👑 the IRSG membership includes the IRTF Chair, the chairs of the various RGs, and possibly other individuals ("members at large") from the community 🌈 if you want the details on how the IRTF, the ISRG, and its RGs are organized and operated, check out [IRTF], [IABIRTF], [IRTFPRIMER], and [IRTFCHAIR] 📖

3.8. IETF Trust ⚖️

the IETF Trust is the legal owner of intellectual property for the IETF, IRTF, and IAB 💖 that covers their trademarks, the copyrights to RFCs and to works of the IETF (like the IETF website), and copyright licenses for IETF contributions, including Internet-Drafts 📜 the principles for the copyright licenses granted to and from the Trust are described in [IPRRIGHTS1] and [COPYRIGHT], and the licenses themselves live in the Trust Legal Provisions (https://trustee.ietf.org/documents/trust-legal-provisions/) 🎀

the Trust also currently owns IANA's domain names and trademarks through an agreement with IANA 🌸

the Trustees who govern the Trust are selected from the IETF community, as described in [TRUSTEES], and the reasoning behind that is given in [TRUSTRAT] 🫶

3.9. IETF Administration LLC (IETF LLC) 🏢

the IETF Administration Limited Liability Company (colloquially, the "IETF LLC") is the corporate legal home for the IETF, the IAB, and the IRTF 🏠✨

the IETF LLC supports the ongoing operations of the IETF, manages its finances and budget, and raises money 💰 it regularly reports back to the community 📣 it's also the legal entity that signs contracts for the IETF Secretariat, meeting hotels, tools development contractors, and many others 🧾 the IETF LLC also responds to legal requests, and these are often subpoenas in patent lawsuits 😬

selection of the IETF LLC Board of Directors is defined in [NOMCOM] 🗳️

the IETF Executive Director handles the IETF's daily tasks and management, and is overseen by the IETF LLC Board of Directors 👩‍💼

Section 6 of [ISOCIETF] describes the legal relationship between the IETF LLC and the Internet Society 🤓

3.10. IETF Secretariat 📋

the administrative functions needed to support the activities of the IETF and its various related boards and organizations are performed by a Secretariat that's contracted by the IETF LLC 💼 the IETF Secretariat handles a lot of the logistics for running the in-person meetings, and it's responsible for maintaining the formal public record of the Internet standards process [IETFPROCS] 🗂️✨

3.11. Internet Society (ISOC) 🌍

ISOC plays a really important role in the standards process 🙌 besides being the legal entity that hosts the IETF LLC, ISOC appoints the NomCom Chair, confirms IAB candidates selected by the NomCom, and acts as the final authority in the appeals process 🧑‍⚖️ this is described in [ISOCIETF] 💜

the way the ISOC leadership is selected, along with other matters about how the Internet Society operates, is described in [ISOC] 🌷

4. Security Considerations 🔐

this document introduces no new security considerations 🛡️ no new security considerations, but keep your guard up anyway bestie 💀

5. IANA Considerations 🧚

this document has no IANA actions 🌟

6. Informative References ✨

okay bestie, this is the reading list 📚 every reference is listed with its full details, so you can go find the exact doc. the tags in brackets are how the text points at each one 💅

Acknowledgements ✨

we owe a big thank-you to the authors of [RFC2028], Richard Hovey and Scott Bradner 🫶

also a huge shoutout to Barry Leiba, Colin Perkins, Eric Auerswald, John Levine, and Lars Eggert, who gave useful feedback and corrections on this doc. literally the MVPs 👑

Author's Address ✨

Rich Salz Akamai Technologies Email: rsalz@akamai.com

and that's the whole thing, bestie 🌈💖

📦 where this page comes from