RFC 9592

Retiring the Tao of the IETF

📅 published June 2024, from ietf

Retiring the Tao of the IETF 🎀

Okay bestie, here's the header tea ☕ This RFC was published by the Internet Engineering Task Force (IETF) and it's the one that retires the Tao:

  • RFC number: 9592 📄
  • Title: Retiring the Tao of the IETF
  • Authors: N. ten Oever (University of Amsterdam) and G. Wood (IETF Administration LLC)
  • Category: Informational
  • Date: June 2024
  • ISSN: 2070-1721
  • Obsoletes: RFC 6722 🙅‍♀️
  • Updates: none listed

Abstract

So this doc retires and obsoletes the Tao of the IETF as a document the IETF maintains 💅 It also obsoletes RFC 6722, the one that describes how the Tao gets published as a webpage 🌸 It explains why the Tao got retired ✨ and, for archival purposes, the last version of the Tao is tucked into the appendix 📚 The info new participants need to engage with the IETF isn't going anywhere, though. It'll keep living on the IETF website, in a more timely and accessible way 💖 This is the way. 🧚

Status of This Memo

Not me getting in my standards era, but this document is not an Internet Standards Track specification. It's published for informational purposes 🦋

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🤓

Want the current status, any errata, or a way to send feedback? Check https://www.rfc-editor.org/info/rfc9592 ✨

Copyright (c) 2024 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're in effect on the publication date. Please actually read these, 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 the Revised BSD License describes 🔥

Table of Contents

   1.  Introduction
   2.  Reasons for Retirement
     2.1.  Infrequent Updates
     2.2.  Unwieldy Format
     2.3.  Changing Participation Modes
   3.  Going Forward
     3.1.  New Communications Opportunities
   4.  Conclusion
   5.  Security Considerations
   6.  IANA Considerations
   7.  Informative References
   Appendix A.  Last Edition of the Tao
     Abstract
     1 Introduction
       1.1 Acronyms and Abbreviations Used in the Tao
     2 What is the IETF?
       2.1 Humble Beginnings
       2.2 The Hierarchy
       2.3 IETF Mailing Lists
     3 IETF Meetings
       3.1 Registration
       3.2 Take the Plunge and Stay All Week!
       3.3 Newcomer Training
       3.4 Dress Code
       3.5 Working Group Meetings
       3.6 Seeing Spots Before Your Eyes
       3.7 Terminal Room
       3.8 Meals and Snacks
       3.9 Social Event
       3.10 Agenda
       3.11 EMODIR to the Rescue
       3.12 Where Do I Fit In?
       3.13 Proceedings
       3.14 Other General Things
       3.15 Remote Participation
     4 Working Groups
       4.1 Working Group Chairs
       4.2 Getting Things Done in a Working Group
       4.3 Working Group Documents
       4.4 Preparing for Working Group Meetings
       4.5 Working Group Mailing Lists
       4.6 Interim Working Group Meetings
     5 BOFs and Dispatching
     6 RFCs and Internet-Drafts
       6.1 The Overall Process
       6.2 Common Issues
       6.3 Writing an Internet-Draft
       6.4 Standards-Track RFCs
       6.5 RFCs Other than Standards-Track
     7 How to Contribute to the IETF
       7.1 What You Can Do
       7.2 What Your Company Can Do
     8 IETF and the Outside World
       8.1 IETF and Other SDOs
       8.2 Press Coverage of the IETF
   Acknowledgements
   Authors' Addresses

1. Introduction ✨

Okay so the Tao has been around since [RFC1391] came out in 1993 💜 It explained how IETF meetings and Working Groups actually work, talked about the organizations around the IETF, and walked new participants through the working processes. It was never a formal IETF process document, though. It was an informational overview that the community built and looked after 🌸

After it was an RFC for 13 years, the Tao moved to being a webpage for over a decade, following the process in [RFC6722] 🕸️ But the Tao didn't keep up with how the community and the organization changed, so it stopped being a reliable source of info 😭 We want to give a huge shoutout to everyone who contributed to the Tao over the years 🫶 Participation has changed, we've gotten better at figuring out how to explain things to newcomers, and we learned a lot from publishing the Tao as a webpage. All of that points to a new approach for collecting, updating, and sharing the info newcomers need to engage with the IETF successfully. So this document formally retires and obsoletes the "Tao of the IETF" as a single standalone document. Bye Tao 👋

2. Reasons for Retirement 💅

Real talk: the Tao covered so many topics, updated on a schedule nobody could predict, and took so much effort to revise and review that it just didn't match what its intended audience needed or wanted 🙈

2.1. Infrequent Updates

The Tao was first published as [RFC1391] in January 1993. Over the next 17 years, four more versions came out as RFCs 📚

In August 2012, [RFC6722] was published to document the process for publishing the Tao as a webpage, so it could "be updated more easily." 💻 But then, in the 11 years after that, only four more versions were published 💀 The Tao was so long that reviewing and approving the whole thing took a ton of effort and time, which is why updates were so rare 😩

2.2. Unwieldy Format

The big, consolidated format of the Tao was a huge commitment for readers 📖 Editors also had a hard time keeping up with the changes it needed to stay current. For example, IETF Hackathons got really popular with new participants, which prompted an update. But that content was basically buried in an already long document 🫠

2.3. Changing Participation Modes

The original Tao wanted to welcome new participants to IETF meetings, because attendance was growing fast alongside the Internet in the 1990s 🌈 Over the following decades, other ways to get started with the IETF showed up, but the Tao's main focus stayed on in-person meeting participation. Remote participation has become a much bigger deal in the past few years, for example 💻

3. Going Forward 🦋

The content of the Tao has already been folded into the IETF website, which is the main channel for newcomers and general audiences 🌟 That content is kept up to date continuously and shared through a variety of media to reach different audiences. The IETF wants to make sure the website keeps up with our ever-evolving community and potential newcomers too 💖

3.1. New Communications Opportunities

The IETF and its community are always looking for ways to level up their communication, for newcomers and existing participants alike ✨ Some possible ways to do that:

  • More focused guides, e.g., on IETF Hackathon participation, starting new work, etc.
  • Alternative formats, e.g., multiple shorter documents, on-demand video, podcasts, etc. 🎧
  • New channels for communications, e.g., blog posts, improved Datatracker, Slack, etc. 🍓

4. Conclusion

So the Tao covered a huge range of topics, updated on an unpredictable schedule, and was expensive to revise and review. That meant it took a lot of effort to maintain, it was usually out of date, and it didn't do its job of informing the community and newcomers 😔 That's why this document is the end of the road for the "Tao of the IETF." It's officially retired now 🪦 For archival reasons, the last version of the Tao lives in Appendix A.

5. Security Considerations 🔐

This document has no security considerations. Zero. None. Nada 🙌

6. IANA Considerations 📋

This document has no IANA actions. Nothing for IANA to do here 💅

7. Informative References 📚

Appendix A. Last Edition of the Tao 🕰️

For archival purposes, here's the last edition of the Tao as published under the process described in [RFC6722]. Heads up: several links to resources outside the Tao don't work at the time this RFC was published 🔗 Also, minor errors in the text below have been corrected ✏️

Abstract

This document introduces you to the "ways of the IETF": it will convey the might and magic of networking people and packets in the Internet's most prominent standards body 🧙‍♀️ In this document we describe the inner workings of IETF meetings and Working Groups, discuss organizations related to the IETF, and introduce the standards process. This is not a formal IETF process document but an informal and informational overview.

1. Introduction ✨

okay so the IETF is literally the biggest standards development organization (SDO) for the Internet 😭🌐 and since its early years it has grown phenomenally. In-person attendance at face-to-face meetings now averages between 1000 and 1500 participants (https://datatracker.ietf.org/stats/meeting/overview/). At any given meeting, around 200 attendees are newcomers (the IETF's own word for someone who has attended five or fewer meetings), and lots of them go on to become regulars 🫶 When the IETF was smaller, it was pretty easy for a newcomer to settle in. Now a newcomer meets SO many more new people, some of whom they only knew as the authors of documents or as the people behind really thought-provoking emails 🙈

Obviously, lots of IETF people never go to the face-to-face meetings at all, especially since the COVID-19 pandemic, when meetings were totally online for a while 💻 There are also tons of people who only focus on the mailing lists of various IETF Working Groups. The inner workings of Working Groups can be hard for newcomers to get, so this document gives you all the mundane bits of info you need to become an active participant 🎀 The IETF website also has a lot of newcomer info (https://www.ietf.org/about/participate/get-started/) in various formats. In this document we try to cover as much as possible in one place, bestie 💅

The IETF is always evolving ✨ The principles in this document are expected to stay consistent over time, but the practical details may well have changed by the time you're reading this. For example, a web-based tool may have replaced an email address for requesting some sort of action 🦋

Lots of IETF documentation gets mentioned here. The IETF publishes its technical docs as RFCs, which are still known by their historical name, Requests for Comments. (Sometimes people joke that it stands for Request for Compliance 💀) STDs are RFCs identified as "standards", and BCPs are RFCs that capture thoughts on Best Current Practices in the Internet. Both STDs and BCPs are also RFCs, so it's giving RFC all the way down 👑 For example, BCP 9 (https://www.rfc-editor.org/info/bcp9) points to a collection of RFCs that describe the IETF's standardization processes. See RFCs and Internet-Drafts for more details 🧚

1.1. Acronyms and Abbreviations Used in the Tao

Some of the acronyms and abbreviations from this document are listed below 🍓

  +=======+=====================================================+
  | Term  | Meaning                                             |
  +=======+=====================================================+
  | AD    | Area Director                                       |
  +-------+-----------------------------------------------------+
  | BCP   | Best Current Practice (a type of RFC)               |
  +-------+-----------------------------------------------------+
  | BOF   | Birds of a Feather                                  |
  +-------+-----------------------------------------------------+
  | IAB   | Internet Architecture Board                         |
  +-------+-----------------------------------------------------+
  | IANA  | Internet Assigned Numbers Authority                 |
  +-------+-----------------------------------------------------+
  | IASA  | IETF Administrative Support Activity                |
  +-------+-----------------------------------------------------+
  | ICANN | Internet Corporation for Assigned Names and Numbers |
  +-------+-----------------------------------------------------+
  | I-D   | Internet-Draft                                      |
  +-------+-----------------------------------------------------+
  | IESG  | Internet Engineering Steering Group                 |
  +-------+-----------------------------------------------------+
  | IPR   | Intellectual property rights                        |
  +-------+-----------------------------------------------------+
  | IRSG  | Internet Research Steering Group                    |
  +-------+-----------------------------------------------------+
  | IRTF  | Internet Research Task Force                        |
  +-------+-----------------------------------------------------+
  | ISOC  | Internet Society                                    |
  +-------+-----------------------------------------------------+
  | RFC   | Request for Comments                                |
  +-------+-----------------------------------------------------+
  | STD   | Standard (a type of RFC)                            |
  +-------+-----------------------------------------------------+
  | WG    | Working Group                                       |
  +-------+-----------------------------------------------------+

                              Table 1

2. What is the IETF? 💖

The IETF has no members and no dues 🌸 It's a loosely self-organized group of people who contribute to the engineering and evolution of Internet technologies. It's the principal body doing the development of new Internet standard specifications, and it's unusual because it exists as a collection of meetings (both in-person and virtual) and online activities (like email and pull request discussions) that individuals voluntarily take part in 🦋

The IETF welcomes all interested individuals, and IETF participants come from all over the world and from many different parts of the Internet industry 🌈 The IETF does all of its work solely in English. See Where do I fit in? for info about the many different ways people fit into the IETF 🫶

Quoting from RFC 3935: A Mission Statement for the IETF (https://www.rfc-editor.org/info/rfc3935), "the overall goal of the IETF is to make the Internet work better. Its mission is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds." 🔥

The ways the IETF does that include the following:

  • Identifying and proposing solutions to pressing operational and technical problems in the Internet.
  • Specifying the development or usage of protocols and the near-term architecture to solve such technical problems for the Internet.
  • Making recommendations to the Internet Engineering Steering Group (IESG) regarding the standardization of protocols and protocol usage in the Internet.
  • Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internet community.
  • Providing a forum for the exchange of information within the Internet community among vendors, users, researchers, agency contractors, operators, and network managers.

RFC 3935 further states that the Internet isn't value-neutral, and neither is the IETF 👑 The IETF wants the Internet to be useful for communities that share its commitment to openness and fairness. The IETF embraces technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community 💜 These concepts have little to do with the technology that's possible, and much to do with the technology that the IETF chooses to create. Main character energy 💅

In many ways, the IETF runs on the beliefs of its participants 🧚 One of the founding beliefs is embodied in an early quote about the IETF from David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code." Another early quote that has become a commonly-held belief in the IETF comes from Jon Postel: "Be conservative in what you send and liberal in what you accept." 🫶

There is no membership in the IETF 🌸 Anyone may sign up to working group mailing lists, or register for a meeting and then attend. The closest thing there is to being an IETF member is being a participant on the IETF or Working Group mailing lists, and that's where the best info about current IETF activities and focus can be found ✨

Of course, no organization can be as successful as the IETF is without some sort of structure 🎀 In the IETF's case, that structure is provided by other supporting organizations, as described in RFC 2028: The Organizations Involved in the IETF Standards Process (https://www.rfc-editor.org/info/rfc2028). Please note that RFC 2028 is outdated and being revised 🙈

The IETF web site (https://www.ietf.org) is the best source for info about upcoming IETF meetings and newcomer materials. The IETF Datatracker (https://datatracker.ietf.org/) is the best source for info about Internet-Drafts, RFCs, and Working Groups 🍓

One more thing that is super important for newcomers: the IETF in no way "runs the Internet," despite what some people mistakenly might say 🚨 The IETF makes voluntary standards that are often adopted by Internet users, network operators, and equipment vendors, and it thus helps shape the trajectory of the development of the Internet. But in no way does the IETF control, or even patrol, the Internet. If your interest in the IETF is because you want to be part of the overseers, you may be badly disappointed by the IETF. A saying you will sometimes hear is, "we are not the protocol police." 👮‍♀️💅

2.1. Humble Beginnings 🌸

okay so bestie, the very first IETF meeting happened in January 1986 at Linkabit in San Diego, and only 21 people showed up 😭 tiny but iconic. The 4th IETF, at SRI in Menlo Park in October 1986, was the first one where equipment vendors came through 💅. Then at the 5th IETF, at the NASA Ames Research Center in California in February 1987, the concept of Working Groups got introduced 🚀. And the 7th IETF, at MITRE in McLean, Virginia, in July 1987, was the first with more than 100 attendees 🔥 that's a glow-up.

After the Internet Society (https://www.internetsociety.org) (ISOC) was formed in January 1992, the IAB proposed to ISOC that the IAB's activities should take place under the auspices of the Internet Society 🤝. Then during INET92 in Kobe, Japan, the ISOC Trustees approved a new charter for the IAB to reflect that relationship ✨.

The IETF met in Amsterdam, The Netherlands, in July 1993. That was the first IETF meeting in Europe, and the US/non-US attendee split was nearly 50/50 🌈 very balanced energy. The IETF first met in Oceania (in Adelaide, Australia) in 2000, the first meeting in Asia (in Yokohama, Japan) was in 2002, and the first meeting in Latin America (in Buenos Aires, Argentina) was in 2016 🦋. So far, though, the IETF has never met in Africa 🥺 someone needs to fix that.

The IETF currently has a "1-1-1" meeting policy, where the goal is to distribute the meetings equally between North America, Europe, and Asia 🌍. This policy is mainly aimed at spreading out the travel effort for existing IETF participants who physically attend meetings, and at spreading out the timezone pain for people who participate remotely 🕐. The IETF has also met in Latin America and Oceania, but those continents are currently not part of the 1-1-1 rotation schedule. If you want the deets on picking the venue and the meeting policy, check out RFC 8718: IETF Plenary Meeting Venue Selection Process (https://www.rfc-editor.org/info/rfc8718) and RFC 8719: High-Level Guidance for the Meeting Policy of the IETF (https://www.rfc-editor.org/info/rfc8719) 📚.

Remote participation in IETF meetings has been growing significantly over the past few years 📈, thanks in part to the ongoing effort to improve the tools and processes used for this mode of participation 💻✨.

2.2. The Hierarchy 👑

2.2.1. The Internet Society (ISOC) and the IETF Administration LLC (IETF LLC)

okay so the Internet Society (ISOC) is an international, non-profit, membership organization that supports and promotes the development of the Internet as a global technical infrastructure 🌐. Its mission is "to promote the open development, evolution, and use of the Internet for the benefit of all people throughout the world" 💜. One of the ways ISOC does this is through financial support of the IETF 💸.

The IETF Administration LLC (https://www.ietf.org/about/administration/) (IETF LLC) is a "disregarded entity" of ISOC, which means it is treated as a branch or division for tax purposes 🧾. The IETF LLC has no role in the oversight or steering of the standards process, the appeal chain, the confirming bodies for existing IETF and IAB appointments, the IRTF, or ISOC's memberships in other organizations 🙅. Instead, the IETF LLC, as overseen by its Board of Directors, is responsible for staffing and for contracts with places like hotels that host IETF meetings 🏨. Most of the day-to-day activities are delegated to the IETF Executive Director.

Responsibilities of the IETF LLC include:

  • Supporting the ongoing operations of the IETF, including meetings and non-meeting activities.
  • Managing the IETF's finances and budget.
  • Raising money on behalf of the IETF.
  • Establishing and enforcing policies to ensure compliance with applicable laws, regulations, and rules.

The IETF and ISOC continue to be strongly aligned on key principles 🫶. ISOC initiatives related to the IETF continue to support participation in, and deployment of, the standards created by the IETF 🎀.

2.2.2. Internet Engineering Steering Group (IESG)

The IESG is responsible for technical management of IETF activities and the Internet standards process 🧠. However, the IESG doesn't really exercise direct leadership the way you'd see in lots of other standards organizations 🙈. As its name suggests, its role is to set directions rather than to give orders 🧭. The IESG gets WGs started and finished, ratifies or steers the output from the IETF's Working Groups (WGs), and makes sure that non-WG I-Ds that are about to become RFCs are correct ✅.

Check the IESG web pages (https://www.ietf.org/about/groups/iesg) to find up-to-date information about IESG statements, I-Ds processed, RFCs published, and documents in Last Call, plus the monthly IETF status reports 📅.

The IESG consists of the Area Directors (ADs), who are selected by the Nominations Committee (NomCom) and are appointed for two years 🗓️. The process for choosing the members of the IESG is detailed in BCP 10 (https://www.rfc-editor.org/info/bcp10) 📖.

The current Areas and abbreviations are shown below, and more details (https://www.ietf.org/topics/areas/) are on the IETF web site 🗺️.

     +======================+========================================+
     | Area                 | Description                            |
     +======================+========================================+
     | Applications and     | Protocols seen by user programs, such  |
     | Real-Time Area (art) | as email and the web and delay-        |
     |                      | sensitive interpersonal communications |
     +----------------------+----------------------------------------+
     | General (gen)        | IETF process, and catch-all for WGs    |
     |                      | that don't fit in other Areas (which   |
     |                      | is very few)                           |
     +----------------------+----------------------------------------+
     | Internet (int)       | Different ways of moving IP packets    |
     |                      | and DNS information                    |
     +----------------------+----------------------------------------+
     | Operations and       | Network management, AAA, and various   |
     | Management (ops)     | operational issues facing the Internet |
     +----------------------+----------------------------------------+
     | Routing (rtg)        | Getting packets to their destinations  |
     +----------------------+----------------------------------------+
     | Security (sec)       | Privacy, integrity, authentication,    |
     |                      | non-repudiation, confidentiality, and  |
     |                      | access control                         |
     +----------------------+----------------------------------------+
     | Transport (tsv)      | Transport for large volumes of traffic |
     |                      | at potentially high bandwidths         |
     +----------------------+----------------------------------------+

Table 2

Because the IESG reviews all Internet-Drafts before they become RFCs, ADs have quite a bit of influence 👀. The ADs for a particular Area are expected to know more about the combined work of the WGs in that Area than anyone else 🤓. That's because they actively follow the working groups they're responsible for, and they help working groups and chairs with charter and milestone reviews 📋. Some people shy away from directly engaging with Area Directors, but don't! They can be an important resource and help you find the person or the answer you're looking for 💖. They're often very busy during meetings, though, so an email to schedule a meeting can be useful, or you can just ask your questions 💌.

The entire IESG reviews each Internet-Draft (I-D or "draft") that is proposed to become an RFC, and should be aware of general trends that can be gleaned from the collective work products of the IETF 🔍. For IETF-produced RFCs, as part of the document reviews, ADs place ballots that may contain comments on documents 🗳️. The AD enters a position that may be YES, NO OBJECTION, DISCUSS, ABSTAIN, or RECUSE as the result of their review. Any AD may record a DISCUSS ballot position against a draft if they have serious concerns and would like to discuss them 🚩. It's common for documents to be approved with one or two YES ballots, and for the majority of the remaining IESG balloting to be NO OBJECTION 🙌. An IETF blog post (https://www.ietf.org/blog/handling-iesg-ballot-positions/) gives advice on how draft authors could handle the various ballot positions 📝.

Another important job of the IESG is to watch over the output of all the WGs, to help prevent IETF protocols from being at odds with each other 🧩. This is why ADs are supposed to review the I-Ds coming out of Areas other than their own. Each Area also has a directorate, a set of experienced volunteers who review I-Ds with a focus on potential issues for their Area 🧑‍🤝‍🧑.

The quality of IETF standards comes both from the review they get in the Working Groups and from the scrutiny the WG review gets from the ADs 🏆.

2.2.3. Internet Architecture Board (IAB)

The IAB (https://www.iab.org) is responsible for keeping an eye on the "big picture" of the Internet 🔭. It focuses on long-range planning and coordination among the various areas of IETF activity 🗂️. The IAB stays informed about important long-term issues in the Internet, and it brings these topics to the attention of the people it thinks should know about them 📣.

IAB members pay special attention to emerging activities in the IETF 👀. When a new IETF Working Group is proposed, the IAB reviews its charter for architectural consistency and integrity 🏗️. Even before the group is chartered, IAB members are more than willing to discuss new ideas with the people proposing them 💬.

The IAB also sponsors and organizes the Internet Research Task Force (https://www.irtf.org) (IRTF), and convenes invitational workshops that provide in-depth reviews of specific Internet architectural issues 🧪. Typically, the workshop reports make recommendations to the IETF community and to the IESG 📑. The IAB keeps the community informed through blog posts and by publishing RFCs 📰.

The IAB also:

  • Approves NomCom's IESG nominations
  • Acts as the appeals board for appeals against IESG actions
  • Oversees the RFC series policy and procedures
  • Acts as an advisory body to ISOC
  • Oversees IETF liaisons with other standards bodies

Like the IESG, IAB members are selected for two-year positions by the NomCom, and they are approved by the ISOC Board of Trustees 🎉.

2.2.4. Internet Assigned Numbers Authority (IANA)

The core registrar for the IETF's activities is the IANA (https://www.iana.org) 🗃️. Many Internet protocols require that someone keep track of protocol items that were added after the protocol came out 🧾. Typical examples of the kinds of registries needed are registries for TCP port numbers and MIME types 🔢. IANA's work on behalf of the IETF is overseen by the IAB. There's a joint group (https://datatracker.ietf.org/group/ietfiana/about/) that advises IANA, and IANA is funded by ICANN (https://www.icann.org) 💰.

Even though being a registry may not sound super exciting, many IETF participants will testify to how important IANA has been for the Internet 🙌. Having a stable, long-term repository run by careful and conservative operators makes it much easier for people to experiment without worrying about messing things up 🧪🫧.

2.2.5 RFC Editor and RFC Production Center (RPC) 📝

The RPC edits, formats, and publishes RFC's. 🎀 This used to be done by one person, which is why you'll still see the term _RFC Editor_. IETFers are obsessed with their history 📜. If you're a document author, you'll mostly meet the people editing your draft 🫶. Their other big job is keeping one definitive repository (https://www.rfc-editor.org) for all RFCs 🗂️.

Okay, the misconception: not every RFC is the IETF's work 🙈. There are actually four sources of RFCs: the IETF, the IAB, the IRTF, and Independent streams. A fifth source will probably show up soon, for documents about the RFC series itself 👀. Only documents that come straight from the IETF, through Working Groups or sponsored by ADs, can have IETF consensus and be called IETF specifications or standards 👑.

Once an RFC is published, it is never revised 🔒. If the spec it describes changes, the standard gets republished in a new RFC that "obsoletes" the old one 🔁. If someone finds a technical or editorial error, an errata can be filed for review ✏️. If it's accepted, the errata gets linked to the RFC and might wait for the next document update 💅.

At the time of writing, the model for the RFC Editor and the RPC is being revised under an IAB Program (https://datatracker.ietf.org/group/rfcefdp/about/) 🔧. In this revision, the IETF LLC hires a position called the RFC Series Editor, who gets advice from a couple of groups 🧑‍💼. As a newcomer and potential author, the details shouldn't matter much to you right now 🌸.

The RPC is contracted by the IETF LLC 📋.

2.2.6 IETF Secretariat 🗓️

A few people get paid to support the IETF 💖. The IETF Secretariat handles the day-to-day logistics, which mostly means coordinating face-to-face meetings and running the IETF's presence on the web 🌐. That includes the IETF web site (https://www.ietf.org), the mailing lists, the repository for Internet-Drafts, and so on ✨. The Secretariat also gives administrative help to the IESG and others 🫡.

The Secretariat is contracted by the IETF LLC 📋.

2.2.7 IETF Trust 🦋

The IETF Trust (https://trustee.ietf.org) was set up to hold and license the IETF's intellectual property 💜. That includes trademarks (the IETF logo, etc.) and copyrights ©️. The Trust is a stable, legally identifiable entity 🏛️. Most participants never interact with it beyond seeing it mentioned in RFC boilerplate 🙈. Honestly, that's a good sign! It means they're quietly doing their job 🫶✨.

2.3 IETF Mailing Lists 📬

The IETF does most of its communication, and all of its official work, over email 💌.

Anyone planning to participate should join the IETF announcement mailing list (https://www.ietf.org/mailman/listinfo/ietf-announce) 📣. This is where all the meeting info, RFC announcements, and IESG Protocol Actions and Last Calls get posted 🔥. The list is strongly moderated, and only the Secretariat and a small number of IETF leaders can approve messages sent to it, although those messages can come from all kinds of people 🧐.

There's also a general discussion list (https://www.ietf.org/mailman/listinfo/ietf) that is unmoderated 🌪️. That means everyone can share their opinions about issues affecting the Internet 🗣️. As an open forum it sometimes spins out of control, so it helps to be quick on the _DELETE MESSAGE_ button while also being slow to take offense 💀. The list does have a charter (https://www.rfc-editor.org/info/bcp45) 📜, which says it's not a place for companies or individuals to solicit or advertise 🚫. As of this writing, the charter is being revised 🛠️. It's lightly moderated by two people appointed by the IETF Chair. They used to be called the Sargent At Arms (SAA), so you might still hear that term 🎖️. There's also a process for banning persistent offenders from the list, but thankfully it's extremely rare 🙏.

There are also subset lists. The i-d-announce list (https://www.ietf.org/mailman/listinfo/i-d-announce) only posts when a new Internet-Draft is submitted 📄, and it's moderated. The last-call list (https://www.ietf.org/mailman/listinfo/last-call) is not moderated, and it's for discussing IETF Last Calls 🕯️. A Last Call is the stage where the IETF community gets one last chance to comment on a draft before it's published as an RFC ⭐.

Every Working Group has its own mailing list 🧚.

Every IETF mailing list is archived 🗄️. (Unfortunately, the archives for some lists from many years ago, back when the IETF didn't have its own servers, have been lost 😭.)

Even though the IETF mailing lists "represent" IETF participants at large, attending an IETF meeting doesn't mean you'll be automatically added to any list 🙅‍♀️. You'll have to "opt in" directly 💅.

3 IETF Meetings 🎉

The computer industry is absolutely packed with conferences, seminars, expos, and all manner of other meetings 🎪. IETF face-to-face meetings are not like these 🙃. The meetings happen three times a year and are week-long gatherings 🗓️. Their main goals are helping Working Groups get their tasks done and encouraging a healthy amount of mixing among the WGs and the Areas 🌈. IETF meetings are of little interest to sales and marketing folks, but of high interest to engineers and developers 🤓.

For a lot of people, IETF meetings are a breath of fresh air compared to standard computer industry conferences 🌬️. There's no exposition hall, few tutorials, and no big-name industry pundits 🙅. Instead there's lots of real work, plus plenty of time for socializing 🍻. The IETF believes that having a drink together (often beer in the hotel lobby, but drink whatever you want 🍹) is highly conducive to collaboration 🫶.

IETFers can be surprisingly direct, sometimes verging on rude 😬. To build a climate where people of many different backgrounds are treated with dignity, decency, and respect, the IETF has an anti-harassment policy (https://www.ietf.org/blog/ietf-anti-harassment-policy) 🛡️, a code of conduct (https://www.rfc-editor.org/info/bcp54) 📖, and an Ombudsteam (https://www.ietf.org/contact/ombudsteam) you can reach out to 💜.

A typical IETF meeting kicks off with an IETF Hackathon (https://www.ietf.org/how/runningcode/) on Saturday and Sunday 💻. Tutorials and an informal gathering happen on Sunday, and WG and BoF meetings run Monday through Friday 🗂️. WG meetings last between one and 2.5 hours each, and some WGs meet more than once, depending on how much work they expect to do ⏰. The WG chairs set the agenda for their meeting time(s) 📋.

There's a plenary session during the week, sometimes two 🎤. Either the first part, or a separate Technical Plenary, has one or more technical presentations on topics of interest to lots of Working Groups 🧠. The IAB organizes this one 🏷️. The Administrative Plenary is organized by the IETF Chair 👑. It has greetings from the meeting sponsor, reports on meeting attendance and IETF finances, and progress reports from most groups mentioned in the "Hierarchy" section above 📊. It ends with an "open mic" session, with the various groups on stage 🎙️. This is a great time to share administrative concerns. Praise is welcome, but more often concerns and gripes get raised 😅.

There have been more than 110 IETF meetings so far 🥳. The list of future meetings is online (https://www.ietf.org/how/meetings/upcoming/) 🔭, and they're also announced on the _ietf-announce_ mailing list mentioned above 📣.

Note that COVID-19 disrupted in-person meetings 😔. After several virtual or online meetings, the IETF tried its first hybrid meeting, in Vienna, in March 2022 🇦🇹✨.

3.1 Registration 🎟️

To attend an IETF meeting, either online or in person, you have to register and pay a registration fee 💳. If you can't afford the online registration fee, you can apply for a fee waiver during registration 🙌. The meeting site (if the meeting isn't purely online) is generally announced several months ahead, or earlier if possible 🗺️. An announcement goes out by email to the _ietf-announce_ mailing list, and the info goes up on the IETF web site (https://www.ietf.org) that same day 📨. Upcoming meeting locations get mentioned at the plenary too, and the host for the next meeting often gives a welcome 👋.

You can register online at the IETF website, or in person throughout the week 💻. There are different fee schedules for early-bird, latecomers, single-day, and so on 💸. The general registration fee covers all of the week's meetings, the Sunday evening _Welcome Reception_, and afternoon beverage and snack breaks 🍪.

The IETF and related organizations are committed to transparency and protecting individuals' privacy 🔐. For info about the personal data that's collected and how it's managed, check the privacy statement (https://www.ietf.org/privacy-statement/) 🕵️‍♀️.

You might also want to subscribe to the meeting-specific email list 💌. It's offered as an option when you register, whether in person or remotely. Discussions on the meetings list can be high volume and pretty wide-ranging about meeting-specific stuff 🌀. It's also a great channel for sharing info that helps everyone understand what's going on during the meeting itself 🧭. Topics often include local mass transit, interesting sites to see, wanting to buy or sell a social event ticket, and so on 🚇🎫. Local experts, people who live in the area, often answer questions and can be super helpful 🥰.

Sunday is an excellent day to join the meeting, unless you already came on Saturday for the hackathon 🌟. Sunday is when the newcomer's tutorial happens, along with the Quick Connections session, where newcomers get to meet experienced IETF participants 🤝. After those sessions comes the welcome reception, a popular event where you can grab a small bite and socialize with other attendees 🥂.

During registration you'll be asked to confirm that you agree to follow the _Note Well_ 📜. You can read it anytime online (https://www.ietf.org/about/note-well/) 👀. It lays out the rules for IETF intellectual property rights (IPR), anti-harassment, and other important guiding policies 🏛️. These slides are also shown before every WG session, and as the week goes on the slide transitions tend to get faster and faster 💨💀.

If you need to leave messages for other attendees, you can use the cork boards that are usually near the IETF registration desk 📌. These boards also carry last-minute meeting and room changes 🚪. The agenda is online, but changes can happen right up to the last minute, like a WG meeting getting cancelled 😱.

You can also turn lost-and-found items in at the registration desk 🧦. At the end of the meeting, anything left over is usually handed to the hotel or brought back to the Secretariat's office 📦. Fun fact: the IETF registration desk is often a convenient place to arrange to meet people 🙈. But if someone says "meet me at registration," clarify whether they mean the IETF registration desk or the hotel registration desk 🚨. This has been a common cause of missed connections 💔.

3.2. Take the Plunge and Stay All Week! 🏊‍♀️

IETF WG meetings run from Monday morning through Friday afternoon 📅. Associated non-WG meetings often happen on the weekend before or after, and unofficial "side meetings" can get scheduled during the week too. It's best to plan on being there the whole week, because that's where the magic happens: cross-fertilization between WGs and hallway chats, both offline and in online spaces like the _gather.town_ website 🌈. The agenda is fluid, and there have been times when people missed important sessions because of last-minute scheduling changes after their travel was already booked 😭. Being there all week is the only way to dodge that particular mess.

If you can't find any meetings all week that catch your interest, you can still make the most of it by working between sessions 💻. Almost everyone has a laptop, so you'll see tons of people in the terminal room, or in the lobbies and hallways, working during meeting sessions. The IETF sets up a high-speed network throughout the hotel for the whole meeting, and the "IETF wifi" is free 🙌. It covers lots of places at the venue (restaurants, coffee shops, and so on), so catching up on email between meetings is a super common IETF move.

Lots of people use their laptops during sessions for practical stuff, like looking up drafts 🧠. Heads up: power strips in every meeting room and hotel room only give you the sockets that local regulations allow. So make sure, ahead of time, that you've got a proper travel adapter 🔌.

3.3. Newcomer Training 🎓

Newcomers, you need to go to the Newcomer's Tutorial on Sunday 🫶. It's made especially for you! It's organized and run by the IETF Education, Mentoring, and Outreach Directorate (_EMODIR_) team, and it gives you the intro info you need. It covers how the IETF is structured, how to get the most out of the meeting, and a bunch of other essential, mind-blowing topics for new IETFers ✨. The IETF has a YouTube channel with past tutorials at https://www.youtube.com/user/ietf. They recently chopped the tutorial into four 15-minute segments, which might be easier to watch, at https://www.youtube.com/watch?v=MW1cDLmr91c&list=PLC86T-6ZTP5imxIwnF0mYxWVp0sbqDR0J&pp=iAQB 🎬.

Quick Connections is a session for newcomers and experienced IETF folks only 💜. It's a great way to meet people and make contacts you'll be glad to have for the rest of the week. You need to register because space is limited, and it happens right before the welcome reception 🥂.

3.4. Dress Code 👗

People dress pretty informally at meetings, so newcomers could feel out of place if they show up Monday morning in suits 💀. The general rule is "dress for casual comfort." Just a heads up: the hotel air conditioning might mean you want a sweater or some other layer too 🧣.

3.5. Working Group Meetings 📝

The heart of an IETF meeting is the WG meetings themselves 💖. Different WG chairs have totally different styles, so there's no way to generalize how a WG meeting will feel 🎭. All WGs do have agendas, though, and most follow a similar approach.

At the start of the meeting, the chair passes around the _blue sheets_, which are paper forms where everyone writes their name and affiliation ✍️. They get archived and used to plan capacity for the next time the WG meets. In very rare cases, they've been used to show exactly who showed up. When the sheet lands in your hands, sign your name and pass it along in the same direction 🙏. If you arrive after the start, you can go up front at the end of the meeting and sign it then. For virtual attendance using the _MeetEcho_ video conference system, attendance is handled through the application itself 💻.

After the blue sheets, there are calls for volunteers to take minutes 📒. More than one person can do it, and it's often done on a web page with a collaborative editing app. Taking minutes is honestly a great way to follow the discussion without getting distracted 🧠. The link to the web page is part of the WG entry in the online meeting agenda. There's also a chance to make last-minute updates to the agenda, which is known as "agenda bashing" 🫠. Finally, there's a review of the Note Well. The order of these things can change, but they all happen before the meeting really "starts" 🎬.

To speak, go to the microphone(s) near the middle of the room 🎤. For controversial topics, there'll be a line at the mic, but don't hesitate to be the first person in line if you have a question or a contribution 💅. The WG chair or presenter will tell you when you can speak. You could just raise your hand from your seat, but the mics do something really useful: they let people listening remotely and in the room hear your question or comment 👂. When you first speak, say your name and affiliation so people know who you are. If you forget, folks will often say "name!" to remind you. Don't be embarrassed if it happens, because it's not uncommon 😅.

3.6. Seeing Spots Before Your Eyes 🔴🟡🔵

Some attendees have a little colored dot on their name tag, and a few people have more than one 👀. These dots identify people who volunteered to do extra work, like being a WG chair, an IESG member, and so on. Here's what the colors mean:

+========+=============================+
| Color  | Meaning                     |
+========+=============================+
| Blue   | Working Group/BOF Chair     |
+--------+-----------------------------+
| Green  | Meeting Host/Sponsor        |
+--------+-----------------------------+
| Red    | IAB member                  |
+--------+-----------------------------+
| Yellow | IESG member                 |
+--------+-----------------------------+
| Pink   | IRSG member                 |
+--------+-----------------------------+
| Orange | Nominating Committee member |
+--------+-----------------------------+
| Black  | IETF LLC Board              |
+--------+-----------------------------+

                 Table 3

Members of the press wear orange-tinted badges with the word "press" on them 📰.

Newcomers, don't be scared to strike up conversations with people wearing these dots 🥰. If the IAB and IESG members and WG and BOF chairs didn't want to talk to anybody, they wouldn't be wearing the dots in the first place! Just note that IETF meetings are usually intense for Area Directors 😵‍💫. Talking to an AD during a meeting will often get you asked to send an email after it ends. Also, when you start a hallway chat with an Area Director (or even a WG chair), it's a good idea to give them about 30 seconds of context first ⏱️.

Near the registration area, there are usually ribbons and markers so people can label their interests, history, and so on 🎀. Lots of people use them for (inside) jokes, and some of them are genuinely hilarious 💀.

3.7. Terminal Room 💻

The IETF wifi is provided by volunteers who run the Network Operations Center (NOC) 🙏. The terminal room is where you can get wired connectivity and limited access to a printer 🖨️. The people and companies who donate their equipment, services, and time deserve a huge round of applause and thanks 👏.

You must be wearing your badge to get into the terminal room 🪪. The terminal room has power strips, Ethernet ports, and wifi (for people who don't need Ethernet but want power). What it doesn't have are terminals. The name is historical 🙃. The help desk in the terminal room is also a good spot to ask about network failures, although they might point you to different networking staff 🧑‍💻.

3.8. Meals and Snacks 🍓

It's true that some people eat very well at the IETF, but they usually find their own food, since lunches and dinners aren't included in the registration fee 🍝. Besides socializing, dinner meetings can be a great way to get extra work done 🧠.

If sponsorship is secured, the welcome reception provides drinks and appetizers, but it's not meant to replace dinner 🥂. Sometimes a continental breakfast is included with the hotel registration 🥐. The IETF meeting also includes a morning coffee and snack break, plus a similar one in the afternoon ☕.

If you'd rather get out of the hotel for meals, the local host usually provides a list of places to eat within easy reach of the meeting site 🗺️. The meeting-specific email list is also a useful source 📧.

3.9. Social Event 🪩

Another one of the biggest things the host organizes and manages is the IETF social event 🎉. The social event is sometimes a high-tech-related event, or it might be at an art museum or a reception hall 🖼️. Just know that not every IETF meeting has a social event.

Newcomers are encouraged to go to the social event 🫶. Wear your name tag and leave your laptop behind! The social event is designed to help people meet on a social rather than technical level 💜. The social ticket costs extra, you reserve it at registration time, and it has limited capacity 🎟️. People looking to buy or sell a social ticket often post to the email list or the corkboards mentioned above 📌.

3.10. Agenda 🗓️

The IETF meeting agenda is a very fluid thing 🌊. It's available on the web and through the IETF mobile apps starting a few weeks before the meeting. "Final" in the IETF doesn't mean what it does everywhere else, though 🙃. The final agenda is simply the last version posted before the meeting. The Secretariat posts agenda changes on the bulletin board near the IETF registration desk (reminder: not the hotel registration desk!) 📋. These late changes aren't random. They're made "just in time" as session chairs and speakers find out about unexpected conflicts ⏰. The IETF is too dynamic for agendas to be locked in weeks in advance 💫.

A map of the hotel layout, especially the meeting rooms, is also available with the agenda 🗺️. Room assignments can change as the agenda changes. Some WGs meet multiple times during a meeting, and every effort is made to keep a WG in the same room for each session 🏠.

3.11 EMODIR to the Rescue ✨

If certain parts of the IETF still feel like a mystery after you finish reading this document, you'll want to drop in on the on-site training from the Education, Mentoring, and Outreach (EMODIR) team 🎀 Besides the Newcomer training I mentioned above, EMODIR also hosts informal newcomer gatherings during the coffee break sessions ☕ The details change from meeting to meeting, so keep an eye on the agenda and the newcomer-specific email list 💌

EMODIR also organizes in-depth technical tutorials that are useful for newcomers and experienced IETFers alike 🤓 These get announced as part of the program too, and they're usually on Sundays 🌸

Last but not least, EMODIR runs the IETF Guides program, which pairs newcomers with an experienced IETF person so you can get settled and effective super fast 🫶 Ngl, this hasn't worked out very well during the all-virtual meetings 😭 If you're interested, watch for the announcement. Ideally you'd have a call with your mentor before the meeting, another meeting at the start of the meeting, and a check-in at some point during the meeting, so they can help with any questions you have 💅

Details on EMODIR membership and charter are online at https://datatracker.ietf.org/group/emodir/about/ 🦋

3.12 Where Do I Fit In?

The IETF is different things to different people 🌈 Lots of people have been super active in the IETF without ever going to an IETF meeting, and you do not need to feel obligated to come to one just to get a feel for the vibe ✨ But if you do decide to come, this document and RFC 4144: How to Gain Prominence and Influence in Standards Organizations (https://www.rfc-editor.org/info/rfc4144) have some pointers on how to make your meeting a success 🔥 The guidelines below are based on stereotypes of people in various industries, so they might help you figure out whether you actually want to come, and if so, how to spend your time at your first meeting 🧚

3.12.1 IT Managers

As we've talked about throughout this document, an IETF meeting is nothing like any trade show you've been to 🙈 IETF meetings are honestly the worst places to go if you want to find out what's going to be hot in the Internet industry next year 💀 You can safely assume that going to Working Group meetings will confuse you more than it helps you understand what is happening, or what will be happening, in the industry 😵‍💫

That said, not everyone from industry should skip it 🍓 As an IT manager, you might want to send specific people who are responsible for technologies that are being developed in the IETF. As those people read the current Internet-Drafts and the email traffic on the relevant Working Group lists, they'll get a sense of whether showing up would be worthwhile for your company or for the Working Groups 🎀

3.12.2 Network Operators and ISPs

Knowing how networks are run is indispensable for developing new (versions of) protocols 🛠️ If you work for the kind of network that always runs the very latest hardware and software, and you're already following the relevant Working Groups, participating in the IETF could be super valuable for you 💜 Also note that the IETF has several WGs focused on operations, which might be especially relevant 👑

Finally, the IETF is increasingly focused on encrypting network traffic, and that has implications for operators 🔐 A good chunk of IETF work also covers other parts of operating ISPs and large enterprises, and input from operators in each of these kinds of organizations is really valuable for keeping this work vibrant and relevant 🌟 Many of the best operations documents from the IETF come from real-world operators, not just vendors and academics 🫶

3.12.3 Networking Hardware and Software Vendors

The image of the IETF being mostly network researchers may have been true in the distant past, but today's attendees usually have industry jobs 💼 In most areas of the IETF, vendor employees are the ones writing the protocols and leading the Working Groups, so it's totally appropriate for vendors to attend 💖 If you create Internet hardware or software, or run a service that's available on the Internet, and nobody from your company has ever come to an IETF meeting, it behooves you to show up at least to tell everyone how relevant the meeting was (or wasn't) to your business 🦋

Now, this doesn't mean companies should shut down during IETF meeting weeks so everyone can go 🙅‍♀️ Marketing folks, even technical marketing and pre-sales people, are totally fine staying away as long as some of the technical people from the company are there 💅 Similarly, it isn't required, or likely useful, for everyone in a technical department to go, especially if they aren't reading the Internet-Drafts and following the Working Group mailing lists 📚 Many companies only send a few designated attendees, chosen for their ability to write complete and useful trip reports 📝 Plenty of companies also have internal coordination efforts and a standards strategy 🧠 If a company depends on the Internet for some or all of its business, the strategy should probably cover the IETF. Just remember that IETF participation is as an individual, not as a formal representative of their employer 🌸

3.12.4 Academics

IETF meetings are often amazing places for all kinds of researchers to find out what's coming in the way of soon-to-be-deployed protocols, networking architecture, and infrastructure 🔬 Professors and grad students (and sometimes overachieving undergrads) who do research in networking or communications can pick up a wealth of info by following Working Groups in their fields of interest 📖 Wandering into different Working Group meetings can have the same effect as going to symposia and seminars in your department 🎓 Researchers are also, of course, likely to be interested in IRTF activities 🌈

The IRTF and ACM co-host the annual Applied Networking Research Workshop (https://irtf.org/anrw/), which is normally scheduled during the July IETF meeting. Registration is required, but IETF attendees can attend for free 🎟️ The IRTF also hosts the Applied Networking Research Prize (https://irtf.org/anrp/), which comes with a cash prize, a travel grant to attend, and a chance to present ✨ Check out the web page for the requirements 💜

3.12.5 Computer Trade Press

If you're a member of the press and you're thinking about attending IETF, please see the special section below 📰

3.13 Proceedings

IETF proceedings are compiled in the weeks and months after each meeting and are available online at https://www.ietf.org/how/meetings/proceedings/ 📂 Be sure to look through a copy at least once! The proceedings are packed with information about the IETF that you probably won't find anywhere else 🤯 For example, you'll find copies of every session's slides, links to the video recording, copies of the blue sheets (attendance), and so on 🎬

3.14 Other General Things

IETFers are generally super approachable 🥰 Never be afraid to walk up to someone and introduce yourself 👋 And don't be scared to ask questions, especially about jargon and acronyms, because we've all been there 🫠 If someone is presenting an update to their draft, feel free to step up to the mic and ask a clarifying question. Before you do, though, make sure you've read the draft first 📄 Working Group meetings are not the time for general tutorials, bestie 🙏

Hallway conversations are a huge deal. A lot of really good work happens when people talk between meetings and over lunches and dinners 🍝 Every minute of the IETF can be considered work time (much to some people's dismay 😅).

A side meeting (historically, but often inaccurately, called a "bar BOF") is an unofficial get-together between WG meetings or in the late evening, and a lot of work gets done at them 🍻 Side meetings pop up all over the place during an IETF meeting, like restaurants, coffee shops, unused hall spaces, and the like ☕ You can read more about Birds-of-a-Feather sessions (BOFs) in section 5 🐦

The IETF meetings, and the plenary session especially, are not places for vendors to sell their wares 🙅‍♀️ People can totally answer questions about their company and its products, but keep in mind that the IETF is not a trade show 💅

There's always a "materials distribution table" near the registration desk 🗂️ This desk is used to make appropriate information available to attendees (for example, copies of something discussed in a Working Group session, or descriptions of online IETF-related information). Please check with the Secretariat before placing materials on the desk, because the Secretariat has the right to remove material they feel is not appropriate 🫡

3.15 Remote Participation

People have been joining IETF meetings remotely for a long time, but the tools have changed a lot over the years 💻 Currently, the IETF uses a browser-based tool called MeetEcho 🌐 There's also a text-based discussion forum called Jabber 💬 It's integrated into MeetEcho, but there are also stand-alone clients available 🦄 Planned for 2022, the Zulip text will be available, and each WG will have its own stream 🌊

The links for the Meetecho rooms, the Jabber chats, and meeting materials can always be found on the right-hand side of the agenda, under the different icons 👀 All sessions are recorded and can be viewed after the meeting, along with chat logs and meeting minutes 🎥 This is super useful for refreshing your memory while writing a trip report, or for catching up on what happened when you wanted to be in two WG meetings at once 😩 It happens, scheduling conflicts are unavoidable 🫶

4 Working Groups 🧶

The vast majority of the IETF's work is done in its many Working Groups. At the time of this writing, there are well over one hundred different WGs 🤯 BCP 25, "IETF Working Group Guidelines and Procedures," (https://www.rfc-editor.org/info/bcp25) is an excellent resource for anyone participating in WG discussions 📘 You can find the full list of working groups on the datatracker at https://datatracker.ietf.org/wg/ 🗺️

A WG is really just a mailing list with a bit of supervision and facilitation 📬 You "join" the WG by subscribing to the mailing list, and all mailing lists are open to anyone 🥳 Anyone can post to a WG mailing list, although non-subscribers have to have their postings approved first ✅

More importantly, each WG has a charter that the WG is supposed to follow 📜 The charter states the scope of the discussion for the Working Group and its goals. The WG's mailing list and face-to-face meetings are supposed to focus only on what's in the charter, and not wander off onto other "interesting" topics 🙃 Looking a bit outside the scope of the WG is occasionally useful, of course, but the large majority of the discussion should be on the topics listed in the charter 🎯 Some WG charters even specify what the WG will not do, especially if some attractive but nebulous topics came up while the charter was being drafted 🚫 The list of all WG charters makes for really interesting reading if you want to know what the different Working Groups are supposed to be doing 📚 Each WG has its own page on the datatracker 💖

4.1. Working Group Chairs

Okay so every Working Group has one or two (or, rarely, three) chairs 👑. Their role is described in both BCP 11 (https://www.rfc-editor.org/info/bcp11) and BCP 25 (https://www.rfc-editor.org/info/bcp25) 📚

Chairs are responsible for the technical and non-technical quality of the WG's output 💖. The chair must keep the WG productive and making progress on its drafts ✨. Sometimes there's a WG Secretary to help out 🫶. Document editors are usually motivated to make progress too, ngl 💅

The chair has to manage WG discussion, both on the list and by scheduling meetings when it makes sense 🗓️. Sometimes discussions get stuck on contentious points, and the chair may need to steer people toward productive interaction and then declare when rough consensus has been met and the discussion is over 🙈. Chairs also sometimes manage interactions with non-WG participants or the IESG, especially when a WG document is approaching publication 🦋. Honestly, with that mix of secretarial, interpersonal, and technical demands, some WG chairs are way better at their jobs than others 😭

4.2. Getting Things Done in a Working Group

Okay, this one confuses so many newcomers 🥺. Face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list 📬. You'll often hear people say something like "at the last WG meeting, we decided XXX; if you disagree please speak up by the end of the week," and the phrase "to be confirmed on the list" shows up constantly 🌸. There are loads of examples of important decisions made in WG meetings that get overturned later on the mailing list, often because someone who couldn't make the meeting spotted a serious flaw in the logic used to reach the decision 👀. Finally, WG meetings aren't "drafting sessions" like they are in some other standards bodies. In the IETF, drafting happens elsewhere 📝

Another thing that trips people up is that there's no formal voting 🙅‍♀️. The general rule on disputed topics is that the Working Group has to reach "rough consensus," meaning a very large majority of those who care must agree, and those in the minority have had a chance to explain why 🎀. Consensus is usually determined by humming: if you agree with a proposal, you hum when the chair prompts you 🎶. Most hum questions come in three parts. You hum to the first part if you agree with the proposal, to the second part if you disagree, or to the third part if you don't have enough information to make up your mind 🧚. Newcomers find it super peculiar, but it works ✨. It's up to the chair to decide when the Working Group has reached rough consensus, and sometimes the responsible AD will decide too 👑

The lack of formal voting has caused some very long delays for some proposals 😩. But most IETF participants who have watched rough consensus come together after acrimonious debates feel that the delays often lead to better protocols 💜. (And honestly, if you think about it, how could you have "voting" in a group that invites all interested individuals to participate, when it's impossible to count the participants? 🤷‍♀️) A common definition and practice of humming can be found in RFC 7282: On Consensus and Humming in the IETF (https://www.rfc-editor.org/info/rfc7282) 🌈

Another related problem: some people think their topic should be discussed in the WG even when the WG chair believes it's outside the scope of the charter 🙄. If the WG agrees, they can work to re-charter so the topic is in scope 🛠️. The individual can also bring their concerns to the responsible AD 💅

When a WG has fulfilled its charter, it's supposed to cease operations 🎉. (Most WG mailing lists keep going after a WG is closed, still discussing the same topics the Working Group did 📬.) In the IETF, it's a mark of success when a WG closes because it fulfilled its charter. This is one of the things that newcomers with experience in other standards bodies really struggle to understand 🥹

4.3. Working Group Documents

There's an official distinction between WG I-Ds and individual I-Ds 📄. A WG will have to review an individual draft before deciding whether to adopt it as a WG document. The WG chairs appoint who will be the authors or editors of the I-Ds, and often the people who wrote the initial draft keep working on it on behalf of the WG 🫶. Procedures for Internet-Drafts are covered in much more detail later in this document 🔜

For Working Group documents, the document editor serves at the pleasure of the WG Chair 👑. There's often more than one editor for WG documents, especially for complex ones 🧑‍🤝‍🧑. The document editor is responsible for making sure the contents accurately reflect WG decisions. When an editor doesn't follow the WG consensus, the WG Chairs will either get more forceful about getting changes that match the consensus, or replace the editor with someone more responsive to the WG 😤. As a WG document progresses, participants suggest changes on the Working Group's mailing list (or online, if the document is maintained somewhere accessible), and the editors are expected to follow the discussion and make changes when there's consensus 💖

Sometimes a Working Group will consider several alternatives before selecting a particular Internet-Draft as a WG document 🔍. A WG will often take ideas from several of the alternatives to create a single WG document. In that case, the chair decides who gets listed as authors on the title page and who gets acknowledged as contributors in the body of the document 🎀

When a WG document is ready to move beyond the WG, the WG Chairs will assign a "shepherd" to take over the final process 🐑. The role of the document shepherd is described in RFC 4858: Document Shepherding from Working Group Last Call to Publication (https://www.rfc-editor.org/info/rfc4858) 🦋. The chair, who knows the draft's history within the WG, often does the shepherd write-up ✍️

4.4. Preparing for Working Group Meetings

The most important thing that everyone should do before coming to a face-to-face meeting is read the Internet-Drafts and RFCs ahead of time 📚🫶. WG meetings are explicitly not for education. They're for developing the group's documents, and often the document is presented as a set of slides saying "here's what changed since last meeting" 🎞️. Even if you don't plan to say anything in the meeting, you should read, or at least skim, the group's documents before attending so you can actually follow what's being said 🧠

It's up to the WG chairs to set the meeting agenda, usually a few weeks in advance 🗓️. If you want something discussed at the meeting, make sure you let the chair know 💌. The agendas for all the WG meetings are available in advance on the datatracker, and links to will be found on every full meeting agenda. Unfortunately, some WG chairs are lax (if not totally negligent) about turning them in 😒

The Secretariat only makes the full IETF meeting schedule a few weeks in advance, and the schedule often changes as little as a week before the first day ✈️. If you're only coming for one WG meeting, you may have a hard time booking your flight with such little notice, especially if the Working Group's meeting changes schedule 😩. Keep track of the current agenda so you can schedule flights and hotels 🏨. But honestly? You probably shouldn't come for just one WG meeting. Your knowledge could be valuable in a few WGs, assuming you've read the I-Ds and RFCs for those groups 🌟. Work in the IETF is reciprocal, so contribute positively to others' work and you're more likely to get comments and feedback on your own 🤝

If you're on the agenda at a face-to-face meeting, prepare a few slides and mail them to the chair before the meeting 📨. Don't come with a tutorial, because people are supposed to read the I-Ds in advance 🙅‍♀️. Projectors for laptop-based presentations are available in all the meeting rooms 📽️

And here's a tip for your slides: don't put your company's logo on every one, even though that's common practice outside the IETF 🙈. The IETF frowns on this kind of corporate advertising (except for the meeting sponsor in the plenary presentation), and most presenters don't even put their logo on their opening slide. The IETF is about technical content, not company boosterism 💅. Slides are often plain black and white for legibility, with color used only when it really adds clarity 🖤. Again, the content is the most important part of the slides, not how it's presented ✨

One thing you might find helpful, and maybe even entertaining, during WG sessions is to follow the running commentary in the Jabber room associated with that Working Group 💬. Jabber is a free, streaming XML technology mainly used for instant messaging. You can find pointers to Jabber clients for many platforms at (https://xmpp.org/xmpp-software/clients) 📱. The Jabber chatrooms are named after the Working Group followed by "@jabber.ietf.org". Those rooms are actually available year-round, not just during IETF meetings, and some are used by active WG participants during protocol development 🌸

4.5. Working Group Mailing Lists

As we mentioned earlier, the IETF announcement and discussion mailing lists are the central mailing lists for IETF activities 📢. But there are many other mailing lists related to IETF work. For example, every Working Group has its own discussion list 💌. On top of that, some long-term technical debates have moved off the IETF list onto lists created specifically for those topics 🗂️. It is highly recommended that you follow the discussions on the mailing lists of the Working Groups you want to attend 💖. The more work that gets done on the mailing lists, the less work needs to happen at the meeting, which leaves time for cross pollination (i.e., attending Working Groups outside one's primary areas of interest in order to broaden one's perspective) 🌈🦋

The mailing lists also give people who want to follow, or contribute to, the Working Groups' efforts a place to do it when they can't attend IETF meetings 🫶. That's why IETF procedures require all decisions to be confirmed "on the list," and you'll often hear a WG chair say "Let's take it to the list" to close a discussion 🔒

Every WG has a dedicated page on the datatracker site, and the "About" tab will point you to mailing list subscription and archives 📬✨

4.6 Interim Working Group Meetings ✨

okay so Working Groups sometimes hold interim meetings between IETFs 💅 but interim meetings are NOT a substitute for IETF meetings, bestie 🙅‍♀️ a group can't just decide to skip a meeting in a location they're not fond of and meet in Cancun (or even someplace mundane) three weeks later, for example 🌴 not me giving up on the vibe check. Interim meetings need to be announced at least one month in advance. Location and timing need to allow fair access for all participants 🫶 And like regular IETF meetings, someone needs to take notes and the group needs to take attendance 📝 Decisions tentatively made during an interim WG meeting must still be confirmed on the mailing list 💌 Interim meetings are subject to the IETF Note Well 👀 Most interim meetings are virtual these days and have the same reporting requirements as face-to-face virtual meetings, so no skipping the paperwork just because you're on Zoom 🎀

The IESG has rules for advance notice on time and place of interim Working Group meetings, plus rules for reporting the results of those meetings 📋 The whole point is to make interim meetings accessible to as many WG members as possible and to keep the Working Group process transparent 🔍 that's giving fairness, and I'm here for it 🦋

5 BOFs and Dispatching 🌸

okay so in order to form a Working Group, you need a charter and someone who is able to be chair 👑 to get those things, you need to get people interested so they can help focus the charter and convince an Area Director that the project is worthwhile 💜 A face-to-face meeting is useful for this. In fact, very few WGs get started without an initial meeting 🧚

A _Birds of a Feather_ (BOF) meeting has to be approved by the Area Director in the relevant area, in consultation with the IESG and the IAB, before it can be scheduled 📅 If you think you need a new WG, approach an AD with your proposal and see what they think. You will have to write some informative background text, and they will work with you to get it scheduled. Of course, you can also gather interested people and work on a draft charter in the meantime ✨

BOF meetings have a very different tone than WG meetings 🫠 the purpose of a BOF is to make sure that a good charter with good milestones can be created, that there are enough people willing to do the work needed in order to create standards, and that any standards would get adoption 💅 Often a self-selected group of key people will get together after the BOF to refine the draft charter 🍓

Generally, there are only two BOF meetings allowed for the same topic 🛑 Sometimes it is obvious after one meeting that a WG should be created, and sometimes it is obvious a WG would not be successful 💀

If you have a draft already written, you can submit it to the relevant "dispatch" WG 📨 Each area has one of these. Their job is to review submitted documents and decide on the next steps. The possibilities include: create a new WG, send to an existing WG, hold a BOF, and so on 🌈

An advantage of using the dispatch WG compared to a BOF is that the discussion is more limited and focused 🎯 On the other hand, a draft might tend to limit what the other folks in the BOF want to do in the charter 🙈 Remember that most BOFs are held in order to get support for an eventual Working Group, not to get support for a particular document. Main character energy for the group, not the draft 👑

6 RFCs and Internet-Drafts 🦋

okay so this section is about Internet-Drafts and RFCs in the IETF stream, meaning it describes how documents are produced and advanced within the IETF 📚 For a brief note on other RFC streams, see above.

If you're a new IETF participant and looking for a particular RFC or Internet-Draft, go check out the IETF _Datatracker_ 🔎 This website, https://datatracker.ietf.org/, has a text search capability (including content, keywords, author, and so on), and the search results point to the document status, page count, and other useful info. A little-known hint: dt.ietf.org is an abbreviation (a DNS CNAME entry) for the longer datatracker.ietf.org hostname 🤫

Most RFCs in the IETF stream follow the same process, and the sections below discuss that process and some of the issues 🧃 Note that there are other ways to get an RFC published (https://www.ietf.org/about/participate/get-started/#officialdocuments), particularly if it is not intended for the standards track. For the sake of brevity, we won't mention those here. After all, this document is about "the Way of the IETF," and the main Way is "developing standards" 💖

If you are interested in learning more about how to author an Internet-Draft yourself, the I-D Authors website (https://authors.ietf.org) has tons of information and resources, including pointers to online tools that can help 🛠️ literally go look, it's so worth it.

6.1 The Overall Process 🌈

okay so the very first step is to have a draft document 📝 Internet-Drafts should follow a specific format, and they are required to have particular sections. This will be discussed more below.

RFCs are generally written by a Working Group 👯 If an appropriate WG doesn't seem to exist, the BOF or Dispatch process mentioned above can be used to learn which one is appropriate, or to start the process to create one 🌸

Once a potential WG exists, the document must be _adopted_ 💌 To do this, you submit your individual draft to the datatracker. It should start with draft-YOURNAME-brief-subject, where _YOURNAME_ is your name. Send a note to the WG mailing list with an introduction to the draft and why you think it is appropriate 📬 After any discussion, the WG Chair will issue a _call for adoption_. If consensus is to adopt the draft, you will be asked to submit it with the name draft-ietf-WGNAME-brief-subject. You can probably guess what _WGNAME_ should be 🧚‍♀️

Note that as part of submitting an Internet-Draft according to the rules, you grant the IETF certain rights 🤝 These rights give the IETF the ability to reliably build upon the work you've brought forward. These rights are held by the IETF Trust. BCP 78 (https://www.rfc-editor.org/rfc/rfc5378.html) explains the certain rights the IETF Trust takes on for submissions 📜

Once a WG adopts a document, the WG as a whole has the right of "change control" 😬 This means the WG can make any changes to the document, the one you initially wrote, that they want. If you are not comfortable with this, then the IETF is not the place for your document 🙃 There are a few more details on this below.

The WG now "works on" the document 🛠️ This will be a combination of mailing list discussion, perhaps agenda time at a meeting, and publishing updated drafts. (Every draft ends with -NN, where the digits indicate the draft number.) 🔢

At some point the document will seem finished ✅ The WG Chair will put the document in _WG Last Call_ (WGLC), which gives the members of the WG a chance for last-minute changes. It can be frustrating to get a bunch of changes after you think you're done, but don't take it personally 🥲 like many things, people are often deadline-driven.

After WGLC, the responsible AD (the one who oversees the WG) does a review. They will probably have comments that must be resolved by you and the WG, and it's quite likely you'll have to publish a new draft 📝 Then the IESG and the overall IETF review the draft, as mentioned above. The purpose of IETF Last Call is to get community-wide discussion on documents before the IESG considers them. Note the word _discussion_ here 🗣️ It is generally considered bad form to send IETF Last Call comments on documents you have not read, or to send comments but not be prepared to discuss your views. The IETF Last Call is not a vote. Having said that, IETF Last Call comments from people who have just read the document for the first time can expose issues that IETF and WG regulars may have completely missed, which is why the discussion is open to everyone 👀

Finally, the draft is given to the RFC Production Center (RPC) and prepared for publication 🎉 There might be other changes required, including reviews by IANA for registrations and the like. The most common thing you'll hear about this is the _AUTH48_ state, which means the document is in the final stages of copy-editing by the RPC and you 💅 The publication process can take weeks, so be patient, and you'll eventually see an email announcement saying that your brand-new RFC has been published. Congratulations! 🥳🎊

A much more complete explanation of these steps is contained in BCP 9 (https://www.rfc-editor.org/info/bcp9). This set of documents goes into great detail on a topic that is very often misunderstood, even by seasoned IETF participants: different types of RFCs go through different processes and have different rankings 🌟 it's giving complicated, but we'll get there together 🫶

6.2 Common Issues

okay so there are two big drama queens that keep showing up when people prep I-Ds: copyright and patents 💅 🌸

We talked about copyright earlier, but let's dig in. When the IETF adopts an Internet-Draft, the boilerplate (the standard text that sits in every draft) has to include a notice saying the IETF, _and the document authors_, own the copyright 📜 ✨ So the IETF can do what it wants with the document, but you're also limited. You can't claim it's an IETF standard, and you can't use IETF trademarks 🙅‍♀️

Also, the change control on Internet standards doesn't stop once the RFC is published 🦋 Things can get changed later for all kinds of reasons, like fixing a newly discovered problem or covering new use cases. Those later changes are also controlled by the IETF, not by the editors of the standards document 💜

Now, patents 🫣 The IETF wants its standards to be widely used and validated by the market. If making a product that uses a standard means getting a patent license, people are less likely to implement it 😭 So the general rule has been "use good non-patented technology where possible." 🌈

That's not always doable, though 💀 Sometimes patents show up after a standard is already established, and the IETF can't really do much about it. Sometimes a patent covers something so valuable that there's no non-patented equivalent, and the IETF generally tries to avoid it.

The best case is when the patent holder is generous and promises every implementor a royalty-free license, which makes implementing it almost as easy as if the patent didn't exist 🧚 Ideally, and this is the common case when a patent holder is active in a document, the patent holder will grant free use of the patent to implement the specification ✨

The official rules for all intellectual property rights (IPR) in IETF documents are covered in BCP 78 (https://www.rfc-editor.org/info/bcp78) and BCP 79 (https://www.rfc-editor.org/info/bcp79). This isn't just about patents, either. It also covers code samples and similar stuff 🍓

If you're writing an Internet-Draft and you know of a patent that applies to the tech you're writing about, do NOT list the patent in the document 🚫 Instead, check the IPR disclosures page (https://datatracker.ietf.org/ipr/about/). If you're still stuck, talk to the WG Chair or the responsible AD.

Why no IPR list in RFCs? Because RFCs never change after they're published, but knowledge of IPR can change at any time 🙈 So an IPR list in an RFC could go out of date and mislead the reader. BCP 79 (https://www.rfc-editor.org/info/bcp79) has the specific text to add to RFCs where the author knows about IPR issues 🎀

6.3 Writing an Internet-Draft

Every RFC starts its life as an I-D 🌸 Internet-Drafts have the same format as an RFC and have to include all the content that should end up in the RFC. That includes a couple of sections I'll explain below. A draft can also have extra info, like an incremental list of changes from previous versions, or links to places where people can raise issues and suggest changes 💖

For the past several years, the official canonical source of RFCs is RFC 7991: The "xml2rfc" Version 3 Vocabulary (https://www.rfc-editor.org/info/rfc7991). Some people love writing in XML, and some people don't 😭 The alternative for the second group is a specific dialect of markdown, which gets converted to XML as needed (especially during publication). A recent trend is more markdown and hosting I-Ds on GitHub to reach a wider, Internet-savvy audience 🫶 You can find some info on this in RFC 8874: Working Group GitHub Usage Guidance (https://www.rfc-editor.org/info/rfc8874).

The IETF is setting up a new site, https://authors.ietf.org (https://authors.ietf.org), with guides and online tools for new and experienced authors 🧚 As of this writing it's still a draft, but there's already a ton of useful stuff on it. Feel free to use it and give feedback ✨

Outside of formatting decisions, the most important document you can read is Guidelines to Authors of Internet-Drafts (https://www.ietf.org/how/ids/guidelines) 📚 It explains the naming conventions, formatting requirements, required content, and how to submit (also called _post_) your draft 💅

6.3.1 Internet-Draft Language

It's really common for Internet-Drafts that revise existing RFCs to have "bis" in their names, which means "again" or "twice" 🍓 For example, a draft might be called draft-ietf-uta-rfc6125bis, meaning it's meant to be a revision of, and eventual replacement for, RFC6125.

Writing clear specs can be a bit of an art, especially for people who don't have English as their first language 🌈 You could keep the spec super short, with just a list of requirements, but that tends to make implementors take too much leeway 🙃 If you make it super wordy with tons of suggestions, implementors tend to miss the actual requirements (and often disagree with your suggestions anyway) 💀 The sweet spot is somewhere in between ✨

One way to make interoperable implementations more likely is to be clear about what the spec mandates 🫶 Over time the IETF has realized that defining a few words with specific meanings helps a ton. BCP 14 (https://www.rfc-editor.org/info/bcp14) defines about a dozen keywords that show what's a requirement versus what's purely informative 👑 It defines the meaning of words like MUST and points out that the word has to appear in all uppercase to have its special meaning 🔥

It's not unusual for feedback on standards-track I-Ds to question particular uses of what's called "2119 language" 🙈 For example: "The document says MAY but doesn't explain why not; should it be a MUST?"

6.3.2 About References

One thing that trips up lots of newcomers to IETF standards is the rule for normative references to non-IETF documents or to other RFCs 😭 A normative reference points to a document you must follow in order to implement the standard. A non-normative reference (sometimes called an _informative reference_) is helpful to an implementor but not strictly needed to implement it 🦋

An IETF standard can make a normative reference to any other standards-track RFC at the same standards level or higher, or to any "open standard" developed outside the IETF 💖 The "same level or higher" rule means that before a standard can move from Proposed to Internet Standard, every RFC it cites as a normative reference also has to be an Internet Standard 👑 This gives implementors the assurance that everything in an Internet standard is pretty stable, even the stuff referenced from outside 🧚 This rule, and its exceptions, is described in BCP 97 (https://www.rfc-editor.org/info/bcp97) 📚

There's no hard-and-fast rule for what counts as an "open standard," but generally it means a stable standard made by a generally recognized SDO, that anyone can get a copy of (though not necessarily for free) 🌸 If the external standard changes, you have to reference the particular instantiation of it in your spec, like by designating its date 🎀 Some external standards bodies don't keep old standards around, which is a real problem for IETF standards that need to be used in the future 😭 When in doubt, ask the WG chair or AD whether a particular external standard can be used in an IETF standard 🫶

6.3.3 About Required Content

Every draft has to have some content 💅 Some of it is boilerplate about copyright, the "2119 keyword," and so on. The document formatting tools will generate this for you automatically if you use the right keyword ✨ There are also special sections that might be required for your draft, and you (and the WG) will have to write them 🍓

A lot of IETF standards have extension points, like unassigned fields in a message header, or for something like email or HTTP, an actual message header 🌈 As mentioned above, IANA maintains online registries for these. Because the registries standards need are so large and diverse, IANA needs specific info on how to register parameters, what not to register, who (if anyone) approves registration requests, and so on 🧚

Anyone writing a draft that needs one or more registries, or that adds values to existing registries, must have an "IANA Considerations" section 💖 Authors should read BCP 26 (https://www.rfc-editor.org/info/bcp26), "Guidelines for Writing an IANA Considerations Section in RFCs," which explains how to properly ask IANA to make the changes requested in the draft 📜 If there are no considerations, it's a good idea to still have the section and explicitly say "This document has no IANA requests." 🙌

Every draft must have a "Security Considerations" section 🔐 This describes possible threats or attacks, known vulnerabilities, information that could be exposed, and so on. It should also describe any strategies or mechanisms to mitigate them 😭 When the security directorate (SECDIR) reviews your draft, this section is one of their main focuses. Do NOT gloss over it, or say things like "use TLS to get security" without explaining how the protocol uses TLS and what it actually provides 💀 Check out BCP 72 (https://www.rfc-editor.org/info/bcp72), "Guidelines for Writing RFC Text on Security Considerations," for more on writing good security considerations 🔥

A draft might also have a "Privacy Considerations" section 🙈 RFC 6973: Privacy Considerations for Internet Protocols (https://www.rfc-editor.org/info/rfc6973) is an Informational RFC written by the IAB, meant to raise general awareness of privacy on the Internet. It also gives advice on when a draft should have an explicit privacy section 🦋

Some drafts benefit from an "Implementation Status" section, as explained by BCP 205: Improving Awareness of Running Code: The Implementation Status Section (https://www.rfc-editor.org/info/rfc7942) 🌸

More detail on required content is available online (https://authors.ietf.org/en/required-content) 🎀

6.4 Standards-Track RFCs

If the IESG approves a draft to become a standards-track RFC, they ask the RPC to publish it as a _Proposed Standard_ 👑

Don't be surprised if a standard doesn't progress from Proposed Standard to Internet Standard 💀 To become an Internet Standard, an RFC needs multiple interoperable implementations, and the unused features in the Proposed Standard have to be removed. There are additional requirements in BCP 9 (https://www.rfc-editor.org/info/bcp9) 📚 Most of the protocols in common use are Proposed Standards and never move forward 😭 That might be because nobody took the time to push them to Internet Standard, or because some of their normative references are still at Proposed Standard, or because everyone found more important things to do 🙃

6.5 RFCs Other than Standards-Track 🎀

Okay so, not every RFC is a standard!! 😭 Lots of really important RFCs are not on the standards track at all. Right now there are categories for Informational, Experimental, Best Current Practice, and Historical (for standards that are no longer recommended for use) 🍓. The role of Informational RFCs is kinda confusing, and people sometimes call them "standards" when they're literally not 💀.

Experimental RFCs are for specs that are interesting, but it's unclear if they'll get widespread deployment or if they'll scale once they're out there 🧪. Like, a spec might solve a problem, but there might not be IETF consensus that the problem is worth solving, or that the spec is complete enough to actually fix it 🙈. Experimental RFCs are also a way to get people to try out a technology that looks like it might be standards-track material, but still has unanswered questions ✨.

The IESG made guidelines (https://www.ietf.org/standards/process/informational-vs-experimental/) to help you pick between Informational and Experimental. It's a short, informal read, and if you are not sure where your document fits, it is worth reading 💅.

Last thing: there are two sub-series of RFCs, Best Current Practice (BCP) and Internet Standards (STD) 👑. BCP describes how various technologies are applied on the Internet, and BCPs are also commonly used to document the many parts of the IETF process 🦋. The STD sub-series was created to identify RFCs that actually specify Internet standards 💜.

These are an example of the aphorism that everything in computer science can be solved by a layer of indirection 🌈. For example, a single BCP can refer to one or more RFCs, and the specific RFCs can change, like when a new version of a protocol gets published 🔥. Likewise, some STDs are actually sets of more than one RFC, and the "standard" label applies to the whole set of documents 🫶.

7. How to Contribute to the IETF 🌸

7.1. What You Can Do 💖

Read: Review the Internet-Drafts in your area of expertise and comment on them in the Working Groups 👀. Participate in the discussion in a friendly, helpful way, with the goal being the best Internet standards possible 🧚. Listen much more than you speak 🤫. If you disagree, debate the technical issues: never attack the people 🫶.

Implement: Write programs that use the current Internet standards 💅. Standards aren't worth much unless they're available to Internet users 🌈. Implement even the "minor" standards, since they'll become less minor once they show up in more software 📱. Report any problems you find with the standards to the appropriate Working Group so the standard can be clarified in later revisions 📝. Remember the tenet "rough consensus and running code" ⭐, so you can help the standards you want become more widespread by creating more running code 🚀. You can help develop protocols before they become standards by implementing I-Ds (but not doing wide-spread deployment) to make sure the authors did a good job 🔍. If you find errors or omissions, offer improvements based on your implementation experience 🛠️. A great way to get involved is by participating in the Hackathons 🎉.

Write: Edit or co-author Internet-Drafts in your area of expertise 🖊️. Do this for the benefit of the Internet community, not to get your name (or, even worse, your company's name) on a document 🙅. Draft authors get all kinds of technical (and, sadly, sometimes personal) criticism 😭. Take the technical comments with equanimity and use them to improve your draft so you can produce the best and most interoperable standard, and ignore the personal ones 🧘.

7.2. What Your Company Can Do 🏢

Share: Avoid proprietary standards 🚫. If you're an implementor, show a strong preference for IETF standards 💜. If the IETF standards aren't as good as the proprietary ones, work to make the IETF standards better 💪. If you're a purchaser, avoid products that use proprietary standards that compete with the IETF's open standards, and tell the vendors that you're doing so 🛒.

Open Up: If your company owns a patent that's used in an IETF standard, convince the company to make the patent available at no cost to anyone implementing the standard 🎁. Patents have caused many serious problems for Internet standards before, because they stop some companies from freely implementing them 😤. Luckily, many companies have generously offered unlimited licenses for particular patents to help IETF standards flourish 🌟. These companies are usually rewarded with positive publicity for not being as greedy or short-sighted as other patent-holders 📣.

Support: The IETF has sponsorship opportunities (https://ietf.org/about/donors/) and an endowment (https://www.ietf.org/endowment/donate-ietf-endowment/) that can also take individual-sized donations 💸. Become a member of ISOC 🌍. Urge any company that has benefited from the Internet to contribute, since this has the greatest financial benefit for the group 💰. It will, of course, also benefit the Internet as a whole 🌐.

8. IETF and the Outside World 🌎

While some IETF participants would like to think otherwise, the IETF does not exist in a standards vacuum 🫧. This section discusses two important groups 👯.

8.1. IETF and Other SDOs 🤝

There are many other standards organizations whose decisions affect the Internet 🌐. Some of them ignored the Internet for a long time and now want to get a piece of the action 👀. In general, the IETF tries to have cordial relationships with other SDOs 💕. This isn't always easy, since they usually have different structures and processes than the IETF does, and the IETF is mostly run by volunteers who would probably rather write standards than meet with representatives from other bodies 😅. Even so, many SDOs make a great effort to interact well with the IETF despite the obvious cultural differences 🥹.

As stated in BCP 39 (https://www.rfc-editor.org/info/bcp39), the IAB Charter says: "Liaisons are kept as informal as possible and must be of demonstrable value in improving the quality of IETF specifications." 📜 In practice, the IETF prefers liaisons to happen directly at the WG level, with formal relationships and liaison documents in a backup role 🫶. The best place to check whether the IETF has any formal liaison at all is the list of IETF liaisons (https://www.ietf.org/about/liaisons) 🔎.

At the time of writing, the IETF has around two dozen liaisons ✨. Some of these liaison tasks fall to the IESG, and others fall to the IAB 🧑‍🤝‍🧑. Full details about the processes for dealing with other SDOs can be found in BCP 102 (https://www.rfc-editor.org/info/bcp102) and BCP 103 (https://www.rfc-editor.org/info/bcp103) 📚.

8.2. Press Coverage of the IETF 📰

Given that the IETF is one of the best-known bodies helping move the Internet forward, it's only natural for the media to cover what it does 📺. But it can be hard to cover the IETF 😩. A common mistake is reporting an individual's Internet-Draft as something the IETF is working on, or saying the IETF has approved a new standard when it was actually an Informational or Individual RFC 🙃. Often the press isn't really to blame, since they might have been tipped off by a company trying to get publicity for a protocol, or they saw the latest "controversy" on social media 📱.

Reporters who want to find out about "what the IETF is doing" on a particular topic would be well-advised to talk to more than one person who's active on that topic in the IETF, and should probably try to talk to the WG chair in any case 🗣️. It's impossible to determine what will happen with a draft by looking at the draft or talking to the draft's author 🔮. Luckily, all WGs have archives that a reporter can look through for recent indications about the progress of a draft 🗂️. Unfortunately, few reporters have the time or inclination to do this kind of research 😭.

Reporters looking for information about the IETF, or pointers to IETF participants working on a particular topic relevant to the IETF, should send a message to media@ietf.org (mailto:media@ietf.org) 📩. A full page of contacts for a variety of needs is available online (https://www.ietf.org/contact/) 🌷. Replies are usually sent within a day ⏰. Even if a direct answer to a particular query isn't available, pointers to resources or people who can provide more information about a topic are often provided 💌.

Acknowledgements 🎀

The next phase of work to welcome new participants to the IETF builds on and gratefully acknowledges everyone who has contributed to the Tao, and to other efforts to help newcomers become engaged and productive participants 🫶.

We acknowledge all of the past "Tao of the IETF" editors:

  • Gary Scott Malkin 💜
  • Susan R. Harris 💜
  • Paul Hoffman 💜
  • Kathleen Moriarty 💜
  • Niels ten Oever 💜

We also acknowledge all the work of the translators who made the Tao accessible to so many different audiences 🌍. Finally, we want to acknowledge the work of countless contributors over the years 🥰.

Authors' Addresses 💌

Niels ten Oever University of Amsterdam Email: mail@nielstenoever.net

Greg Wood IETF Administration LLC Email: ghwood@staff.ietf.org

📦 where this page comes from