diff options
Diffstat (limited to 'doc/rfc/rfc9592.txt')
| -rw-r--r-- | doc/rfc/rfc9592.txt | 2118 |
1 files changed, 2118 insertions, 0 deletions
diff --git a/doc/rfc/rfc9592.txt b/doc/rfc/rfc9592.txt new file mode 100644 index 0000000..a2af7a3 --- /dev/null +++ b/doc/rfc/rfc9592.txt @@ -0,0 +1,2118 @@ + + + + +Internet Engineering Task Force (IETF) N. ten Oever +Request for Comments: 9592 University of Amsterdam +Obsoletes: 6722 G. Wood +Category: Informational IETF Administration LLC +ISSN: 2070-1721 June 2024 + + + Retiring the Tao of the IETF + +Abstract + + This document retires and obsoletes the Tao of the IETF as an IETF- + maintained document. This document also obsoletes RFC 6722, which + describes the publication process of the Tao. Furthermore, this + document describes the rationale for the retirement of the Tao. For + archival purposes, the last version of the Tao is included in the + appendix. Information that new participants need to engage in the + work of the IETF will continue to be provided through the IETF + website in a more timely and accessible manner. This is the way. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + 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 has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9592. + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +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 + + Since its publication as [RFC1391] in 1993, The "Tao of the IETF" + ("Tao") has described the inner workings of IETF meetings and Working + Groups, discussed organizations related to the IETF, and introduced + the working processes to new participants. The Tao never was a + formal IETF process document, but rather a community-developed and + maintained informational overview. After the Tao was published as an + RFC for 13 years, it was published as a webpage for over a decade + following the process described in [RFC6722]. However, the Tao did + not keep up with the changes in the processes of the community and + the organization, and thereby ceased to be a reliable source of + information. We gratefully want to acknowledge all the individuals + who contributed to the Tao over the years. The changing nature of + IETF participation, a better understanding of how to most effectively + convey information to new participants, and experience with + publishing the Tao as a webpage all suggest a new approach to + collecting, updating, and communicating the information that new + participants need to engage in the work of the IETF successfully. + This document formally retires and obsoletes the "Tao of the IETF" as + a single standalone document. + +2. Reasons for Retirement + + In short, the breadth of topics covered in the Tao, the unpredictable + and different schedule for updates to the topics, and the high + overhead for revising and reviewing the content did not match the + needs or preferences of the intended audience of the Tao. + +2.1. Infrequent Updates + + The Tao was originally published as [RFC1391] in January 1993. In + the following 17 years, four additional versions of the Tao were + published as RFCs: + + * [RFC1539] in October 1993, + * [RFC1718] in November 1994, + * [RFC3160] in August 2001, and + * [RFC4677] in September 2006. + + In August 2012, [RFC6722] was published to document the process for + publishing the Tao as a webpage so that it could "be updated more + easily." However, in the subsequent 11 years, only four additional + versions were published. The length of the Tao meant that review and + approval of the entire document took considerable effort and time, + leading to very infrequent updates. + +2.2. Unwieldy Format + + The large, consolidated document format of the Tao made for a heavy + investment by readers, in addition to the difficulty editors faced + keeping pace with the changes required to keep it current. For + example, the emergence of IETF Hackathon popularity with new + participants prompted an update. However, that content was + effectively buried in an already long document. + +2.3. Changing Participation Modes + + The original Tao aimed to welcome new participants to IETF meetings + as attendance grew rapidly along with the growth of the Internet in + the 1990s. As other avenues for initial participation in the IETF + emerged over the ensuing decades, the main focus of the Tao remained + on in-person meeting participation. For example, remote + participation in IETF meetings has become a much more significant + aspect in the past few years. + +3. Going Forward + + The content of the Tao has already been integrated into the website + of the IETF, which is the main channel of communication for IETF + newcomers and a general audience. The content is continuously kept + up to date with a variety of media to serve different audiences. The + IETF seeks to ensure that the website continues to address the needs + of our ever-evolving community and potential newcomers. + +3.1. New Communications Opportunities + + The IETF and its community continuously seek to improve its + communication to newcomers and existing participants alike. Examples + of possible ways of doing this: + + * 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 + + The coverage of a wide range of topics, the unpredictable and + different schedule for updates to the topics, and the high overhead + for revising and reviewing the content mean that the Tao required a + lot of effort to maintain, was commonly out-of-date, and thus did not + serve its intended purpose of informing the community and newcomers. + Therefore, this document is the end of the road for "Tao of the + IETF." The document is now retired. For archival reasons, the last + version of the Tao can be found in Appendix A. + +5. Security Considerations + + This document has no security considerations. + +6. IANA Considerations + + This document has no IANA actions. + +7. Informative References + + [RFC1391] Malkin, G., "The Tao of the IETF: A Guide for New + Attendees of the Internet Engineering Task Force", + RFC 1391, DOI 10.17487/RFC1391, January 1993, + <https://www.rfc-editor.org/info/rfc1391>. + + [RFC1539] Malkin, G., "The Tao of IETF - A Guide for New Attendees + of the Internet Engineering Task Force", RFC 1539, + DOI 10.17487/RFC1539, October 1993, + <https://www.rfc-editor.org/info/rfc1539>. + + [RFC1718] IETF and G. Malkin, "The Tao of IETF - A Guide for New + Attendees of the Internet Engineering Task Force", + RFC 1718, DOI 10.17487/RFC1718, November 1994, + <https://www.rfc-editor.org/info/rfc1718>. + + [RFC3160] Harris, S., "The Tao of IETF - A Novice's Guide to the + Internet Engineering Task Force", RFC 3160, + DOI 10.17487/RFC3160, August 2001, + <https://www.rfc-editor.org/info/rfc3160>. + + [RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's + Guide to the Internet Engineering Task Force", RFC 4677, + DOI 10.17487/RFC4677, September 2006, + <https://www.rfc-editor.org/info/rfc4677>. + + [RFC6722] Hoffman, P., Ed., "Publishing the "Tao of the IETF" as a + Web Page", RFC 6722, DOI 10.17487/RFC6722, August 2012, + <https://www.rfc-editor.org/info/rfc6722>. + +Appendix A. Last Edition of the Tao + + For archival purposes, the last edition of the Tao as published under + the process described in [RFC6722], is included below. Note that + several links to resources external to the Tao do not work at the + time of publication of this RFC. Additionally, minor errors in the + following text 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 + + The Internet Engineering Task Force (IETF) is the largest standard + development organization (SDO) for the Internet. Since its early + years, participation in the IETF 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_ (defined by the IETF as someone who has attended five or + fewer meetings), and many of those go on to become regular + participants. When the IETF was smaller, it was relatively easy for + a newcomer to adjust. Today, however, a newcomer meets many more new + people -- some previously known only as the authors of documents or + thought-provoking email messages. + + Of course, it's true that many IETF participants don't go to the + face-to-face meetings at all -- especially since the COVID-19 + pandemic when meetings were completely online for a while. There are + also many participants who solely focus on the mailing lists of + various IETF Working Groups. Since the inner workings of Working + Groups can be hard for newcomers to understand, this document + provides the mundane bits of information that newcomers will need in + order to become active participants. The IETF website also has a lot + of newcomer information (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. + + The IETF is always evolving. Although the principles in this + document are expected to remain consistent over time, practical + details may well have changed by the time you read it; for example, a + web-based tool may have replaced an email address for requesting some + sort of action. + + Many types of IETF documentation are mentioned here. The IETF + publishes its technical documentation as RFCs, still known by their + historical term _Requests for Comments_. (Sometimes people joke that + it stands for _Request for Compliance_.) STDs are RFCs identified as + "standards", and BCPs are RFCs that represent thoughts on Best + Current Practices in the Internet. Both STDs and BCPs are also RFCs. + 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 is a loosely self-organized + group of people who contribute to the engineering and evolution of + Internet technologies. It is the principal body engaged in the + development of new Internet standard specifications. The IETF is + unusual in that it exists as a collection of meetings (both in-person + and virtual) and online activities (such as email and pull request + discussions), in which individuals voluntarily participate. + + The IETF welcomes all interested individuals: IETF participants come + from all over the world and from many different parts of the Internet + industry. The IETF conducts its work solely in English. See Where + do I fit in? for information about the ways that many 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 to do 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 our 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. + + 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. This is where the best + information about current IETF activities and focus can be found. + + Of course, no organization can be as successful as the IETF is + without having 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 + information about upcoming IETF meetings and newcomer materials. The + IETF Datatracker (https://datatracker.ietf.org/) is the best source + for information about Internet-Drafts, RFCs, and Working Groups. + + One more thing that is 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 + + The first IETF meeting was held in January 1986 at Linkabit in San + Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in + October 1986, was the first that equipment vendors attended. The + concept of Working Groups was introduced at the 5th IETF meeting at + the NASA Ames Research Center in California in February 1987. The + 7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the + first meeting with more than 100 attendees. + + 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. During INET92 in Kobe, Japan, the ISOC Trustees approved a + new charter for the IAB to reflect the proposed relationship. + + The IETF met in Amsterdam, The Netherlands, in July 1993. This was + the first IETF meeting held in Europe, and the US/non-US attendee + split was nearly 50/50. 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, the IETF has never met in Africa. + + 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 distributing the travel effort + for the existing IETF participants who physically attend meetings and + for distributing the timezone difficulty for those who participate + remotely. The IETF has also met in Latin America and Oceania, but + these continents are currently not part of the 1-1-1 rotation + schedule. More information on picking the venue and the meeting + policy can be found in 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 + in the past few years, thanks in part to the ongoing effort to + improve the tools and processes used to facilitate this mode of + participation. + +2.2 The Hierarchy + +2.2.1 The Internet Society (ISOC) and the IETF Administration LLC (IETF +LLC) + + 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. The mission of + ISOC 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 that 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. Rather, the IETF LLC, as overseen by its Board of + Directors, is responsible for staffing and contracts with places like + hotels to 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 + exercise much direct leadership, such as the kind you will find in + many 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, as well as 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. This is because the ADs actively follow the + working groups for which they are responsible and assist working + groups and chairs with charter and milestone reviews. Some people, + therefore, shy away from directly engaging with Area Directors. + Don't -- they can be an important resource and help you find the + person or the answer that you're looking for. They are, however, + often very busy during meetings, and so an email to schedule a + meeting can be useful, or 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 these concerns. It is common for + documents to be approved with one or two _YES_ ballots, and the + majority of the remaining IESG balloting _NO OBJECTION_. An IETF + blog post (https://www.ietf.org/blog/handling-iesg-ballot-positions/) + provides 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 that are at odds with each + other. This is why ADs are supposed to review the I-Ds coming out of + Areas other than their own, and each Area has a _directorate_, a set + of experienced volunteers who review I-Ds with a focus on potential + issues for their area. + + The quality of the IETF standards comes both from the review they get + in the Working Groups and the scrutiny that 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, and 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 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, the 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, the IAB members are selected for two-year positions by + the NomCom and 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 for TCP + port numbers and MIME types. IANA's work on behalf of the IETF is + overseen by the IAB. There is a joint group + (https://datatracker.ietf.org/group/ietfiana/about/) that advises + IANA. IANA is funded by ICANN (https://www.icann.org). + + Even though being a registry may not sound interesting, 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 will still see the term _RFC Editor_; + IETFers are fond of their history. Also, if you are a document + author, you will most commonly come in contact with people + responsible for editing your draft. Another important role is to + provide one definitive repository (https://www.rfc-editor.org) for + all RFCs. + + A common misconception is that all RFCs are the work of the IETF. In + fact, there are four sources of RFCs: the IETF, the IAB, the IRTF, + and Independent streams. It is likely that there will soon be a + fifth source, which will be for documents on the RFC series itself. + Only documents coming directly from the IETF through Working Groups, + or sponsored by ADs, can have IETF consensus and be described as IETF + specifications or standards. + + Once an RFC is published, it is never revised. If the specification + it describes changes, the standard will be re-published in another + RFC that "obsoletes" the first. If a technical or editorial error is + found in an RFC, an errata may be filed for review. If accepted, the + errata will be linked to the RFC and may be held for the next + document update. + + At the time of this 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, there is a position hired by the IETF LLC known as the RFC + Series Editor, who is advised by 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 + + There are a few people who are paid to support the IETF. The IETF + Secretariat provides day-to-day logistical support, which mainly + means coordinating face-to-face meetings and running the IETF + presence on the web, including the IETF web site + (https://www.ietf.org), mailing lists, the repository for Internet- + Drafts, and so on. The Secretariat also provides administrative + assistance 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 intellectual property of the IETF, such as trademarks + (the IETF logo, etc.) and copyrights. The trust is a stable, + legally-identifiable entity. Most participants never interact with + the IETF Trust, beyond seeing it mentioned in RFC boilerplate. This + is a good sign, and indicates that they are quietly doing their job. + +2.3 IETF Mailing Lists + + The IETF does most of its communication, and all of its official + work, via email. + + Anyone who plans to participate in the IETF should join the IETF + announcement mailing list (https://www.ietf.org/mailman/listinfo/ + ietf-announce). This is where all of the meeting information, RFC + announcements, and IESG Protocol Actions and Last Calls are posted. + This list is strongly moderated, and only the Secretariat and a small + number of IETF leaders can approve messages sent to the announcement + list, although those messages can come from a variety of people. + + There is also a general discussion list + (https://www.ietf.org/mailman/listinfo/ietf) that is unmoderated. + This means that everyone can express their opinions about issues + affecting the Internet. As an open discussion forum, it sometimes + spins out of control and it helps to be quick on the _DELETE MESSAGE_ + button while also being slow to take offense. The mailing list does + have a charter (https://www.rfc-editor.org/info/bcp45), however, + which points out that it is not a place for companies or individuals + to solicit or advertise. As of this writing, the charter is being + revised. It is lightly moderated by two people appointed by the IETF + Chair; they used to be called the Sargent At Arms (SAA), and you + might see that term sometimes. There is also a process for banning + persistent offenders from the list, but fortunately this is extremely + rare. + + There are also subset lists. The i-d-announce + (https://www.ietf.org/mailman/listinfo/i-d-announce) list only posts + when a new Internet-Draft is submitted. It is moderated. The last- + call (https://www.ietf.org/mailman/listinfo/last-call) list is not + moderated, and is for discussion of IETF Last Calls (the stage when + the IETF community is given one last chance to comment on a draft + before it is 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, when the IETF did not have its + own servers, have been lost.) + + Even though the IETF mailing lists "represent" the IETF participants + at large, it is important to note that attending an IETF meeting does + not mean you'll be automatically added to any list; you'll have to + "opt in" directly. + +3 IETF Meetings + + The computer industry is rife with conferences, seminars, + expositions, and all manner of other kinds of meetings. IETF face- + to-face meetings are not like these. The meetings, held three times + a year, are week-long gatherings with the primary goals of helping + Working Groups get their tasks done, and promoting a fair 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 many people, IETF meetings are a breath of fresh air when + compared to the standard computer industry conferences. There is no + exposition hall, few tutorials, and no big-name industry pundits. + Instead, there is lots of work, as well as a fair amount of time for + socializing for many participants. The IETF believes that having a + drink together (often beer in the hotel lobby, but drink whatever you + want) is highly conducive to collaboration. + + On the other hand, IETFers can sometimes be surprisingly direct, + sometimes verging on rude. To build a climate in which 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) that you can reach out to. + + The general flow of an IETF meeting is that it begins with an IETF + Hackathon (https://www.ietf.org/how/runningcode/) on Saturday and + Sunday, tutorials and an informal gathering on Sunday, and WG and BoF + meetings Monday through Friday. WG meetings last for between one and + 2.5 hours each, and some WGs meet more than once, depending on how + much work they anticipate doing. The WG chairs set the agenda for + their meeting time(s). + + There is a plenary session during the week, sometimes two. Either + the first part, or a separate Technical Plenary, will have one or + more technical presentations on topics of interest to many Working + Groups. This is organized by the IAB. The Administrative Plenary is + organized by the IETF Chair, and will have greetings from the meeting + sponsor, reports on meeting attendance and IETF finances, and + progress reports from most groups mentioned in the "Hierarchy" + section above. This ends with an "open mic" session, with the + various groups on stage. This is a good time to share administrative + concerns; praise is welcome, but more often concerns and gripes are + raised. + + There have been more than 110 IETF meetings so far. The list of + future meetings is available online + (https://www.ietf.org/how/meetings/upcoming/), and they are also + announced on the _ietf-announce_ mailing list mentioned above. + + Note that COVID-19 disrupted the 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 cannot afford the online + registration fee, you can apply for a fee waiver during the + registration process. The meeting site (if the meeting is not purely + online) is generally announced at several months ahead of the meeting + -- earlier if possible. An announcement goes out via email to the + _ietf-announce_ mailing list, and information is posted on the IETF + web site (https://www.ietf.org), that same day. Upcoming meeting + locations are also mentioned at the plenary, 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 the privacy of individuals. For information about the + personal data that is collected, and how it is managed, please see + the privacy statement (https://www.ietf.org/privacy-statement/). + + You might also consider subscribing to the meeting-specific email + list, which is presented as an option when you register to + participate in the meeting either in-person or remotely. Discussions + on the meetings list can be high volume and fairly wide-ranging about + meeting-specific issues, but it is also a channel for sharing + information that many find useful to understand what is going on + during the meeting itself. Topics often include information about + local mass transit, interesting sites to see, desire to buy or sell a + social event ticket, and so on. Local experts, people who live in + the area, often respond to questions and can be very helpful. + + Sunday is an excellent day to join the meeting, unless you already + came on Saturday for the hackathon. Sunday is the day for the + newcomer's tutorial, as well the Quick Connections session where + newcomers get to meet with experienced IETF participants. After + these sessions there is the welcome reception, a popular event where + you can get a small bite to eat and socialize with other attendees. + + During registration, you will be asked to confirm that you agree to + follow the _Note Well_. You can also read it, anytime, online + (https://www.ietf.org/about/note-well/). This points out the rules + for IETF intellectual property rights (IPR), anti-harassment, and + other important guiding policies for the IETF. These slides will + also be shown before every WG session; as it gets later in the week, + the slide transitions tend to get faster and faster. + + If you need to leave messages for other attendees, you can do so at + the cork boards that are usually near the IETF registration desk. + These cork boards will also have last-minute meeting changes and room + changes. The agenda is available online, and changes can happen up + to the last minute, such as cancelling a WG meeting. + + You can also turn in lost-and-found items to the registration desk. + At the end of the meeting, anything left over from the lost-and-found + will usually be turned over to the hotel or brought back to the + Secretariat's office. Incidentally, the IETF registration desk is + often a convenient place to arrange to meet people. If someone says + "meet me at registration," you should clarify if 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 are scheduled from Monday morning through Friday + afternoon. Associated non-WG meetings often take place on the + preceding or following weekends, and unofficial "side meetings" can + also be scheduled during the week. It is best to plan to be present + the whole week, to benefit from cross-fertilization between WGs and + from hallway discussions (both offline as well as in online + environments such as the _gather.town_ website). As noted below, the + agenda is fluid, and there have been instances of participants + missing important sessions due to last-minute scheduling changes + after their travel plans were fixed. Being present the whole week is + the only way to avoid this annoyance. + + If you cannot find meetings all week to interest you, you can still + make the most of the IETF meeting by working between sessions. + Almost every attendee has a laptop, and it is common to see many of + them 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 duration of the meeting, and there's no + charge to use the "IETF wifi." This usually covers many places of + the meeting venue (restaurants, coffee shops, and so on), so catching + up on email when not in meetings is a fairly common task for IETFers. + + Note that many people use their laptops actively during meeting + sessions for practical purposes such as consulting drafts. Power + strips in all meeting rooms and hotel rooms will provide only the + sockets permitted by local regulations, so ensure in advance that you + have an appropriate travel adapter. + +3.3 Newcomer Training + + Newcomers should attend the Newcomer's Tutorial on Sunday, which is + especially designed for them. The tutorial is organized and + conducted by the IETF Education, Mentoring, and Outreach Directorate + (_EMODIR_) team and is intended to provide useful introductory + information. The session covers the structure of the IETF, how to + get the most out of the meeting, and many other essential and + enlightening topics for new IETFers. The IETF has a YouTube channel + (https://www.youtube.com/user/ietf) which has the previous tutorials. + This has recently been broken down into four 15-minute segments + (https://www.youtube.com/watch?v=MW1cDLmr91c&list=PLC86T- + 6ZTP5imxIwnF0mYxWVp0sbqDR0J&pp=iAQB) which might be easier to view. + + _Quick Connections_ is a session limited to newcomers and experienced + IETF participants. It is a great chance to meet people, and + establish contacts that can be useful during the rest of the week. + Registration is required as space is limited. It is held right + before the welcome reception. + +3.4 Dress Code + + At meetings people generally dress informally, and newcomers could + feel out of place if they show up Monday morning in suits. The + general rule is "dress for casual comfort." Note that the hotel air + conditioning might mean bringing a sweater or other covering as well. + +3.5 Working Group Meetings + + The heart of an IETF meeting is the WG meetings themselves. + Different WGs chairs have very different styles, so it is impossible + to generalize how a WG meeting will feel. All WGs have agendas, + however, and most will follow the following approach. + + At the beginning of the meeting, the chair will pass around the _blue + sheets_, which are paper forms on which everyone writes their name + and their affiliation. These are archived and used for planning + capacity needs for the next time the WG meets. In very rare cases, + they have been used to indicate exactly who showed up. When you are + handed the sheet, sign your name and pass it along in the same + direction. If you arrive after the start, at the end of the meeting + you can go up front and sign it then. For virtual attendance using + the _MeetEcho_ video conference system, attendance is handled by + accessing the application. + + After the blue sheets, there are calls for volunteers to take + minutes. More than one person can do so, and they are often done on + a Web page using a collaborative editing app. Taking minutes can be + a good way to ensure you follow the discussions without distraction! + The link to the web page will be part of the WG entry that is part of + the online meeting agenda. There is also a chance to make any last- + minute updates to the agenda. This is known as "agenda bashing." + Finally, there will be a review of the Note Well. The order in which + these things happen can vary, but they are all done before the + meeting really "starts." + + To speak during a meeting, go to the microphone(s) located near the + middle of the room. For controversial topics, there will be a line + at the mic, but do not hesitate to be the first person at the line if + you have a question or a contribution to the discussion. The WG + chair or presenter will indicate when you can speak. Although it + would be easier to just raise your hand from where you are sitting, + the mics perform a very useful task: they let the people listening + remotely and in the room hear your question or comment. When you + first speak, say your name and affiliation for identification + purposes. If you miss this, folks will often say "name!" to remind + you. Don't be embarrassed if this happens, it's not uncommon. + +3.6 Seeing Spots Before Your Eyes + + Some attendees will have a little colored dot on their name tag, and + a few people have more than one. These dots identify people who have + volunteered to do extra work, such as being a WG chair, an IESG + member, and so on. The colors have the meanings shown here. + + +========+=============================+ + | 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. + + As newcomer, don't be afraid to strike up conversations with people + who wear these dots. If the IAB and IESG members and Working Group + and BOF chairs didn't want to talk to anybody, they wouldn't be + wearing the dots in the first place! Note, however, that IETF + meetings are usually intense times for Area Directors. Talking to an + AD during an IETF meeting will often result in them asking you to + send email after the meeting ends. Also, when you start a hallway + conversation with an Area Director (or even a WG chair, for that + matter), it is often good to give them about 30 seconds of context + for the discussion. + + Near the registration area there are usually ribbons and markers so + that people can label their specific interests, history, and so on. + Many people use them to make (inside) jokes, which are sometimes + amusing. + +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 that donate their equipment, services, and time are to be + heartily congratulated and thanked. + + You must be wearing your badge in order to get into the terminal + room. The terminal room provides power strips, Ethernet ports, and + wifi (for the people who don't need Ethernet but want power). What + it doesn't provide are terminals; the name is historical. The help + desk in the terminal room is also a good place to ask questions about + network failures, although they might point you off to different + networking staff. + +3.8 Meals and Snacks + + Although it is true that some people eat very well at the IETF, they + find the food on their own since lunches and dinners are not included + in the registration fee. In addition to socializing, dinner meetings + can be a good way to get additional work done. + + If sponsorship for it is secured, the welcome reception provides + drinks and appetizers but is not meant to be a full replacement for + dinner. Sometimes a continental breakfast can be included with the + hotel registration. There IETF meeting also includes a morning + coffee and snack break, and a similar one in the afternoon. + + If you prefer to 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, and the meeting-specific email list is also a useful + source. + +3.9 Social Event + + Another of the most important things organized and managed by the + host is the IETF social event. The social event is sometimes high- + tech-related event, or it might be in an art museum or a reception + hall. Note, however, that not all IETF meetings have social events. + + Newcomers to the IETF are encouraged to attend the social event. + Wear your name tag and leave your laptop behind. The social event is + designed to give people a chance to meet on a social, rather than + technical, level. The social ticket costs extra, is reserved at + registration time, and has limited capacity. People looking to buy + or sell a social ticket often post to the email list, or on the + corkboards mentioned above. + +3.10 Agenda + + The agenda for the IETF meetings is a very fluid thing. It is + available on the web and through the IETF mobile apps starting a few + weeks before the meeting. Of course, "final" in the IETF doesn't + mean the same thing as it does elsewhere in the world. The final + agenda is simply the last version posted before the meeting. The + Secretariat will post agenda changes on the bulletin board near the + IETF registration desk (reminder, not the hotel registration desk!). + These late changes are not capricious: they are made "just in time" + as session chairs and speakers become aware of unanticipated + conflicts. The IETF is too dynamic for agendas to be tied down weeks + in advance. + + A map showing the hotel layout and, specifically the meeting rooms, + is also available with the agenda. Room assignments can change as + the agenda changes. Some Working Groups meet multiple times during a + meeting, and every attempt is made to have a Working Group meet in + the same room for each session. + +3.11 EMODIR to the Rescue + + If, after you finish reading this document, certain aspects of the + IETF still mystify you, you'll want to drop in on the on-site + training offered by the Education, Mentoring, and Outreach (EMODIR) + team. In addition to the Newcomer training mentioned above, EMODIR + also hosts informal newcomer gatherings during the coffee break + sessions. Details vary for each meeting, so watch the agenda and the + newcomer-specific email list. + + EMODIR also organized in-depth technical tutorials, useful for + newcomers and experienced IETFers alike. These are also announced as + part of the program, and are usually on Sundays. + + Finally, EMODIR runs the _IETF Guides_ program, pairing newcomers + with an experienced IETF person to help you become acclimated and + effective quickly. This has not worked out very well during the all- + virtual meetings, frankly. If you are interested, watch for the + announcement. Ideally you have a call with your mentor before the + meeting, a meeting during the beginning of the meeting, and check in + some time during the meeting, so they can help you with any questions + you might have. + + Details on EMODIR membership and charter are available online + (https://datatracker.ietf.org/group/emodir/about/). + +3.12 Where Do I Fit In? + + The IETF is different things to different people. There are many + people who have been very active in the IETF who have never attended + an IETF meeting, and you should not feel obligated to come to an IETF + meeting just to get a feel for the IETF. If, however, you decide to + come, this document and RFC 4144: How to Gain Prominence and + Influence in Standards Organizations (https://www.rfc- + editor.org/info/rfc4144) provides some pointers on how to make your + meeting a success. The following guidelines (based on stereotypes of + people in various industries) might help you decide whether you + actually want to come and, if so, what might be the best use of your + time at your first meeting. + +3.12.1 IT Managers + + As discussed throughout this document, an IETF meeting is nothing + like any trade show you have attended. IETF meetings are singularly + bad places to go if your intention is to find out what will be hot in + the Internet industry next year. You can safely assume that going to + Working Group meetings will confuse you more than it will help you + understand what is happening, or will be happening, in the industry. + + This is not to say that no one from the industry should go to IETF + meetings. As an IT manager, you might want to consider sending + specific people who are responsible for technologies that are under + development in the IETF. As these people read the current Internet- + Drafts and email traffic on the relevant Working Group lists, they + will get a sense of whether or not their presence would be worthwhile + for your company or for the Working Groups. + +3.12.2 Network Operators and ISPs + + Knowledge of how networks are run is indispensable for the + development of new (versions of) protocols. Especially if you work + for the type of network that is always using the very latest hardware + and software, and you are already following the relevant Working + Groups, you could certainly find participating in the IETF valuable. + Note that the IETF has several WGs focused on operations, that might + be particularly relevant. + + Finally, note that the IETF is increasingly focused on encrypting + network traffic, and that this has implications for operators. A + fair amount of IETF work also covers many other parts of operations + of ISPs and large enterprises, and the input of operators from each + of these types of organizations is quite valuable to keep this work + vibrant and relevant. Many of the best operations documents from the + IETF come from real-world operators, not 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 the jobs of today's attendees are + typically in industry. In most areas of the IETF, employees of + vendors are the ones writing the protocols and leading the Working + Groups, so it's completely appropriate for vendors to attend. If you + create Internet hardware or software, or run a service available on + the Internet, and no one from your company has ever attended an IETF + meeting, it behooves you to come to a meeting if for no other reason + than to tell the others how relevant the meeting was or was not to + your business. + + This is not to say that companies should close up shop during IETF + meeting weeks so everyone can go to the meeting. Marketing folks, + even technical marketing folks or pre-sales, are safe in staying away + from the IETF as long as some of the technical people from the + company are at the meeting. Similarly, it isn't required, or likely + useful, for everyone from a technical department to go, especially if + they are not all reading the Internet-Drafts and following the + Working Group mailing lists. Many companies have just a few + designated meeting attendees who are chosen for their ability to do + complete and useful trip reports. In addition, many companies 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, but note that IETF participation is + as an _individual_ not a formal representative of their employer. + +3.12.4 Academics + + IETF meetings are often excellent places for all kinds of researchers + to find out what is happening in the way of soon-to-be-deployed + protocols, and networking architecture and infrastructure. + Professors and grad students (and sometimes overachieving undergrads) + who are doing research in networking or communications can get a + wealth of information by following Working Groups in their specific + 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. + + In addition, the IRTF and ACM co-host the annual Applied Networking + Research Workshop (https://irtf.org/anrw/), normally scheduled during + the July IETF meeting Registration is required, IETF attendees can + attend for free. The IRTF also hosts the Applied Networking Research + Prize (https://irtf.org/anrp/), which includes a cash prize, a travel + grant to attend, and a chance to present. See the web page for + requirements. + +3.12.5 Computer Trade Press + + If you're a member of the press and are considering 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 (https://www.ietf.org/how/meetings/ + proceedings/). Be sure to look through a copy at least once; the + proceedings are filled with information about IETF that you're not + likely to find anywhere else. For example, you'll 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 in general are very approachable. Never be afraid to + approach someone and introduce yourself. Also, don't be afraid to + ask questions, especially when it comes to jargon and acronyms. 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, however, + make sure to have read the draft first. Working Group meetings are + not a time for general tutorials. + + Hallway conversations are very important. A lot of very good work + gets done by people who talk together 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, during which a lot of work gets done. These side + meetings spring up in many different places around an IETF meeting, + such as 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 in particular, are not + places for vendors to try to sell their wares. People can certainly + answer questions about their company and its products, but bear in + mind that the IETF is not a trade show. + + There is always a "materials distribution table" near the + registration desk. This desk is used to make appropriate information + available to the attendees (e.g., copies of something discussed in a + Working Group session, descriptions of online IETF-related + information). Please check with the Secretariat before placing + materials on the desk; the Secretariat has the right to remove + material that they feel is not appropriate. + +3.15 Remote Participation + + People have joined IETF meetings remotely for a long time, but the + tools for this have changed a lot over the years. Currently the IETF + uses a browser- based tool known as _MeetEcho_. There is also a text- + based discussion forum called _Jabber_. This is integrated into + MeetEcho, but there are also stand-alone clients available. Planned + for 2022, the _Zulip_ text will be available. Each WG will have its + own stream. + + The links for the Meetecho rooms, the Jabber chats, and meeting + materials, can always be found in 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 can be useful to refresh 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 (https://www.rfc-editor.org/info/bcp25), "IETF + Working Group Guidelines and Procedures," is an excellent resource + for anyone participating in WG discussions. The full list of working + groups can be found on the datatracker (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; + 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 discussion for the Working + Group and its goals. The WG's mailing list and face-to-face meetings + are supposed to focus on only what is in the charter and not to + wander off on other "interesting" topics. Of course, looking a bit + outside the scope of the WG is occasionally useful, but the large + majority of the discussion should be on the topics listed in the + charter. In fact, some WG charters actually specify what the WG will + not do, particularly if there were some attractive but nebulous + topics brought up during the drafting of the charter. The list of + all WG charters makes interesting reading for folks who 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 + + Each Working Group has one or two (or, rarely, three) chairs. The + role of the WG chairs is described in both BCP 11 (https://www.rfc- + editor.org/info/bcp11) and BCP 25 (https://www.rfc-editor.org/info/ + bcp25). + + Chairs have responsibility for the technical and non-technical + quality of WG output. The chair must keep the WG productive, and + making progress on its drafts. Sometimes there is a WG Secretary to + help. Document editors, too, are usually incentivized to make + progress on their drafts. The chair must manage WG discussion, both + on the list and by scheduling meetings when appropriate. 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. Sometimes + chairs also manage interactions with non-WG participants or the IESG, + especially when a WG document approaches publication. As you can + imagine given the mix of secretarial, interpersonal, and technical + demands, some Working Group chairs are much better at their jobs than + others. + +4.2 Getting Things Done in a Working Group + + One fact that confuses many newcomers is that the 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. This is sometimes + phrased as "at the last WG meeting, we decided XXX; if you disagree + please speak up by the end of the week" and you'll therefore often + hear the phrase "to be confirmed on the list." There are numerous + examples of important decisions made in WG meetings that are later + overturned on the mailing list, often because someone who couldn't + attend the meeting pointed out a serious flaw in the logic used to + come to the decision. Finally, WG meetings aren't "drafting + sessions" as they are in some other standards bodies: in the IETF, + drafting is done elsewhere. + + Another aspect of Working Groups that confounds many people is the + fact that there is no formal voting. The general rule on disputed + topics is that the Working Group has to come to "rough consensus," + meaning that a very large majority of those who care must agree, and + that those in the minority have had a chance to explain why. + Generally consensus is determined by _humming_: if you agree with a + proposal, you hum when prompted by the chair. 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 do not have enough information to make up your mind. Newcomers + find it quite peculiar, but it works. It is up to the chair to + decide when the Working Group has reached rough consensus; sometimes + the responsible AD will also do so. + + The lack of formal voting has caused some very long delays for some + proposals, but most IETF participants who have witnessed rough + consensus after acrimonious debates feel that the delays often result + in better protocols. (And, if you think about it, how could you have + "voting" in a group that invites all interested individuals to + participate, and 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). + + A related problem is that some people think that their topic should + be discussed in the WG even when the WG chair believes it is outside + the scope of the charter. If the WG agrees, they can work to _re- + charter_ so that the topic is in scope. The individual can also + bring their concerns to the responsible AD. + + When a WG has fulfilled its charter, it is supposed to cease + operations. (Most WG mailing lists continue on after a WG is closed, + still discussing the same topics as the Working Group did.) In the + IETF, it is a mark of success that the WG closes up because it + fulfilled its charter. This is one of the aspects of the IETF that + newcomers who have experience with other standards bodies have a hard + time understanding. + +4.3 Working Group Documents + + There is an official distinction between WG I-Ds and individual I-Ds. + A WG will have to review an individual draft before deciding if it + should be adopted by the WG. The WG chairs appoint who will be the + authors or editors of the I-Ds; often those who wrote the initial + draft continue work 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 is often more than one editor for + Working Group documents, particularly for complex documents. The + document editor is responsible for ensuring that the contents of the + document accurately reflects Working Group decisions; when a document + editor does not follow the WG consensus, the WG Chairs will either be + more forceful about getting changes that match the consensus or + replace the document editor with someone more responsive to the WG. + As a Working Group document is progressing, participants suggest + changes on the Working Group's mail list (or online if the document + is maintained somewhere accessible); the editors are expected to + follow the discussion and make changes when there is consensus. + + Sometimes a Working Group will consider several alternatives before + selecting a particular Internet-Draft as a Working Group document. A + Working Group will often take ideas from several of the alternatives + to create a single Working Group document; in such a case, the chair + determines who will be listed as authors on the title page and who + will be acknowledged as contributors in the body of the document. + + When a WG document is ready to progress 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 history of the + draft 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 to read the Internet-Drafts and RFCs ahead of + time. WG meetings are explicitly not for education: they are 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 do not plan to say anything in the meeting, you should + read, or at least skim, the group's documents before attending so you + can understand what is 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, be + sure to let the chair know about it. 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 are only coming for one WG meeting, you may + have a hard time booking your flight with such little notice, + particularly if the Working Group's meeting changes schedule. Be + sure to keep track of the current agenda so you can schedule flights + and hotels. But, when it comes down to it, you probably shouldn't be + coming for just one WG meeting. It's likely that your knowledge + could be valuable in a few WGs, assuming that you've read the I-Ds + and RFCs for those groups. Work in the IETF is often reciprocal, + contribute positively to others work and you are more likely to + receive comments and feedback on your work. + + If you are on the agenda at a face-to-face meeting, you should + prepare a few slides and mail them to the chair before the meeting. + Don't come with a tutorial; 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 is a 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 possibly even entertaining, + during Working Group sessions is to follow the running commentary on + 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 have + the name of the Working Group followed by "@jabber.ietf.org". Those + rooms are, in fact, available year-round, not just during IETF + meetings, and some are used by active Working Group 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. However, + there are many other mailing lists related to IETF work. For + example, every Working Group has its own discussion list. In + addition, there are some long-term technical debates that have been + moved off of 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 that you wish to attend. The + more work that is done on the mailing lists, the less work that will + need to be done at the meeting, leaving 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 provide a forum for those who wish to follow, + or contribute to, the Working Groups' efforts, but can't attend the + IETF meetings. That's why IETF procedures require all decisions to + be confirmed "on the list" and you will 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 to mailing list subscription and archives. + +4.6 Interim Working Group Meetings + + Working Groups sometimes hold interim meetings between IETFs. + Interim meetings aren't a substitute for IETF meetings, however -- a + group can't 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. Interim meetings need to be announced at least one + month in advance. Location and timing need to allow fair access for + all participants. 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. + + The IESG has rules for advance notice on time and place of interim + Working Group meetings, as well as reporting the results of the + meetings. The purpose of these rules is to make interim meetings + accessible to as many Working Group members as possible and to + maintain the transparency of the Working Group process. + +5 BOFs and Dispatching + + In order to form a Working Group, you need a charter and someone who + is able to be chair. In order to get those things, you need to get + people interested so that 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 do 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 come to a decision about the next + steps: 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. + +6 RFCs and Internet-Drafts + + This section discusses Internet-Drafts and RFCs in the IETF stream, + that is, 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 are looking for a particular RFC + or Internet-Draft, you can use the IETF _Datatracker_. This website, + https://datatracker.ietf.org/ (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 information. A little-known hint is that + _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 the 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 will not 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 a lot of information and resources, + including pointers to online tools that can help. + +6.1 The Overall Process + + The very first step is to have a draft document. Internet-Drafts + should follow a specific format, and 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, then the BOF or Dispatch process mentioned + above can be used to learn which one is appropriate, or 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 have 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 adopt 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; it's quite likely you'll have to publish a new draft. + Then the IESG and the overall IETF reviews 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 that 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 + that come 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 item you'll hear about this is _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, but 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. + +6.2 Common Issues + + There are two major issues that often come up while preparing I-Ds: + copyright and patents. + + We discussed copyright above, but expand on it here. When the IETF + adopts an Internet-Draft, it is required that the _boilerplate_, the + common text that appears in every draft, has a notice that says the + IETF, _and the document authors_ own the copyright. This means that + while the IETF can do what it wants with the document, within + limitations so can you. You cannot, for example, claim this is an + IETF standard, nor use the IETF trademarks. + + Incidentally, the change control on Internet standards doesn't end + when the RFC is published. Things can be changed later for a number + of reasons, such as to solve a newly-discovered problem or address + new use-cases. These later changes are also under the control of the + IETF, not the editors of the standards document. + + The second issue is patents. The goal of the IETF is to have its + standards widely used and validated by the marketplace. If creating + a product that uses a standard requires getting a license for a + patent, people are less likely to implement the standard. Not + surprisingly, then, the general rule has been "use good non-patented + technology where possible." + + Of course, this isn't always possible. Sometimes patents appear + after a standard has been established and there is little the IETF + can do about that. Sometimes there's a patent on something that is + so valuable that there isn't a non-patented equivalent, and generally + the IETF tries to avoid it. + + Sometimes the patent holder is generous and promises to give all + implementors of a standard a royalty-free license to the patent, + thereby making it almost as easy to implement as it would have been + if no patent existed. 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, not just patents but also code samples and the like, are + covered in BCP 78 (https://www.rfc-editor.org/info/bcp78) and BCP 79 + (https://www.rfc-editor.org/info/bcp79). + + If you are writing an Internet-Draft and you know of a patent that + applies to the technology you're writing about, don't list the patent + in the document. Instead, consult the IPR disclosures + (https://datatracker.ietf.org/ipr/about/) page. If you still have + issues, consult with the WG Chair or the responsible AD. + Intellectual property rights aren't mentioned in RFCs because RFCs + never change after they are published, while knowledge of IPR can + change at any time. Therefore, an IPR list in an RFC could be + incomplete and mislead the reader. BCP 79 (https://www.rfc- + editor.org/info/bcp79) provides specific text that should be added to + RFCs where the author knows of 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 are required to have all the content that + should appear in the RFC. This includes a couple of sections + detailed below. A draft may also have more information, such as an + incremental list of changes from previous versions of the draft, or + pointers to online locations for raising issues and suggesting + changes. + + For the past several years, the official canonical source of RFCs as + RFC 7991: The "xml2rfc" Version 3 Vocabulary (https://www.rfc- + editor.org/info/rfc7991). Some people enjoy writing in XML, and some + don't. An alternative for the second group is to use a specific + dialect of markdown, which is then converted to XML as needed (and + especially during the publication process). A recent trend is the + increasing use of markdown, and hosting I-Ds on GitHub to attract a + wider audience of Internet-savvy users. Some information on this can + be found at 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), to contain guides and online tools to + help both new and experienced authors. As of this writing, it's + still a draft but it does contain a great deal of useful content. + You should feel free to use the site, and offer feedback. + + Outside of the formatting decision, the most important document you + can read is Guidelines to Authors of Internet-Drafts + (https://www.ietf.org/how/ids/guidelines). That document explains + the naming conventions, formatting requirements, required content, + and details of how to submit (also called _post_) your draft. + +6.3.1 Internet-Draft Language + + It is common for Internet-Drafts that revise existing RFCs to have + draft names with "bis" in them, meaning "again" or "twice." For + example, a draft might be called "draft-ietf-uta-rfc6125bis" meaning + that this is intended to be a revision of, and eventual replacement + for, RFC6125. + + Writing clear specifications can be a bit of an art, particularly for + people who don't have English as their native language. You can keep + the specification very short, with just a list of requirements, but + that tends to cause implementors to take too much leeway. If you + instead make the specification very wordy with lots of suggestions, + implementors tend to miss the requirements (and often disagree with + your suggestions anyway). An optimal specification is somewhere in + between. + + One way to make it more likely that developers will create + interoperable implementations of standards is to be clear about + what's being mandated in a specification. Over time, the IETF has + realized that defining a few words with specific meanings helps a + great deal. BCP 14 (https://www.rfc-editor.org/info/bcp14) defines + about a dozen keywords that can be used to clarify what are + requirements, as compared to what is purely informative. It defines + the meaning of words like _MUST_ and points out that it has to appear + in all uppercase to its special meaning. + + It is not uncommon for feedback on standards-track I-Ds to question + the particular uses of what is 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 aspect of writing IETF standards that trips up many newcomers is + the rule about how to make _normative references_ to non-IETF + documents or to other RFCs in a standard. A normative reference is a + reference to a document that must be followed in order to implement + the standard. A non-normative reference (sometimes called an + _informative reference_) is one that is helpful to an implementor but + not strictly needed to implement it. + + An IETF standard may make a normative reference to any other + standards-track RFC that is at the same standards level or higher, or + to any "open standard" that has been developed outside the IETF. The + "same level or higher" rule means that before a standard can move + from Proposed to Internet Standard, all of the RFCs that appear as a + normative reference must also be an Internet Standard. This rule + gives implementors assurance that everything in an Internet standard + is quite stable, even the things referenced outside the standard. + This rule, and its exceptions, is described in BCP 97 + (https://www.rfc-editor.org/info/bcp97). + + There is no hard-and-fast rule about what is an "open standard", but + generally this means a stable standard that was made by a generally- + recognized SDO, and that anyone can get a copy of, although not + necessarily for free. If the external standard changes, you have to + reference the particular instantiation of that standard in your + specification, as with a designation of the date of the standard. + Some external standards bodies don't make old standards available, + which is a problem for IETF standards that need to be used in the + future. When in doubt, ask the WG chair or AD if a particular + external standard can be used in an IETF standard. + +6.3.3 About Required Content + + Every draft is required to have some content. Some of this is + boilerplate text about copyright, "2119 keyword," and so on. The + document formatting tools will generate this for you automatically if + you use the right keyword. In addition, there are special sections + that might be required for your draft, and you (and the WG) will have + to write them. + + Many IETF standards have extension points, such as 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 of the large and diverse kinds of registries that + standards require, IANA needs to have specific information about how + to register parameters, what not to register, who (if anyone) + approves any registration requests, and so on. + + Anyone writing a draft that needs one or more registries, or 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 describes how to properly ask + for IANA to make the changes requested in their draft. If there are + no considerations, it is a good idea to 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 will + be one of their major focuses. Don't gloss over the section, or say + things like "use TLS to get security" without explaining how the + protocol uses TLS and what it provides. See BCP 72 (https://www.rfc- + editor.org/info/bcp72), "Guidelines for Writing RFC Text on Security + Considerations", for more information on writing good security + considerations sections. + + Also, a draft might have a "Privacy Considerations" section. An + Informational RFC, RFC 6973: Privacy Considerations for Internet + Protocols (https://www.rfc-editor.org/info/rfc6973), written by the + IAB, is intended to raise the general awareness of privacy on the + Internet. It also provides advice for when a draft should have an + explicit privacy section. + + Some drafts benefit from having 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 the required content can be found online + (https://authors.ietf.org/en/required-content). + +6.4 Standards-Track RFCs + + If the IESG approves the draft to become a standards-track RFC, they + ask the RPC to publish it as a _Proposed Standard_. + + Don't be surprised if a particular standard doesn't progress from + Proposed Standard to Internet Standard. To become an Internet + Standard, an RFC must have multiple interoperable implementations and + the unused features in the Proposed Standard must be removed; there + are additional requirements listed in BCP 9 (https://www.rfc- + editor.org/info/bcp9). Most of the protocols in common use are + Proposed standards and never move forward. This may be because no + one took the time to try to get them to Internet Standard, or some of + the normative references in the standard are still at Proposed + standard, or it may be that everyone found more important things to + do. + +6.5 RFCs Other than Standards-Track + + As mentioned earlier, not all RFCs are standards. In fact, many + important RFCs are not on the standards track at all. At the time of + writing, there are also categories for Informational, Experimental, + Best Current Practice, and Historical for standards that are no + longer recommended for use. The role of Informational RFCs can be + confusing, and people sometimes refer to them as "standards," when + they are not. + + Experimental RFCs are for specifications that are interesting, but + for which it is unclear if there will be widespread deployment, or if + they will scale to work after such deployment. That is, a + specification might solve a problem, but there might not be IETF + consensus that the problem is worth solving or that the specification + is complete enough to address the problem. Experimental RFCs are + also used to get people to experiment with a technology that looks + like it might be standards-track material, but for which there are + still unanswered questions. + + The IESG has created guidelines + (https://www.ietf.org/standards/process/informational-vs- + experimental/) that can help choose between Informational and + Experimental classification. This is a short informal read, and if + are not sure where your document fits, it is worth reading. + + Finally, there are two sub-series of RFCs: Best Current Practice + (BCP) and Internet Standards (STD). BCP describes the application of + various technologies in the Internet, and are also commonly used to + document the many parts of the IETF process. The STD sub-series was + created to identify RFCs that do in fact 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 such as when a new version of a protocol is published. + Likewise, some STDs are actually sets of more than one RFC, and the + "standard" designation 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 fashion, 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. + The standards aren't worth much unless they are available to Internet + users. Implement even the "minor" standards, since they will become + less minor if they appear in more software. Report any problems you + find with the standards to the appropriate Working Group so that the + standard can be clarified in later revisions. Remember the tenet, + "rough consensus and running code," so you can help support the + standards you want to become more widespread by creating more running + code. You can help the development of protocols before they become + standards by implementing I-Ds (but not doing wide-spread deployment) + to ensure that the authors have done a good job. If you find errors + or omissions, offer improvements based on your implementation + experience. A great way to get involved in this 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 receive kinds of technical (and, sadly, sometimes personal) + criticism. Take the technical comments with equanimity and use it to + improve your draft in order to 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 are an implementor, + exhibit a strong preference for IETF standards. If the IETF + standards aren't as good as the proprietary standards, work to make + the IETF standards better. If you're a purchaser, avoid products + that use proprietary standards that compete with the open standards + of the IETF and tell the vendors that you are doing so. + + *Open Up:* If your company owns a patent that is used in an IETF + standard, convince the company to make the patent available at no + cost to anyone who is implementing the standard. Patents have + previously caused many serious problems for Internet standards + because they prevent some companies from being able to freely + implement them. Fortunately, many companies have generously offered + unlimited licenses for particular patents in order to help the IETF + standards flourish. These companies are usually rewarded with + positive publicity for the fact that they are not 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/) which 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 prefer to write standards rather 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: "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 take place directly at the + WG level, with formal relationships and liaison documents in a backup + role. The best place to check to see 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 this writing, the IETF has around two dozen liaisons. + Some of these liaison tasks fall to the IESG, whereas 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 that is helping + move the Internet forward, it's natural for the media to cover its + actions. 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 that the IETF has approved a new standard when it was + an Informational or Individual RFC. Often, the press is not really + to blame for the problem, as they might have been alerted to the + story by a company trying to get publicity for a protocol, or they + see 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 is 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. Fortunately, all WGs have archives + that a reporter can look through for recent indications about what + the progress of a draft is; 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), and + 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 is not 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 other efforts to help newcomers to the IETF 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 that made the Tao + accessible to many different audiences. + + Finally, we also 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 |