RFC 4677
The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force
The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force 🎀
RFC 4677 (FYI 17) by P. Hoffman of the VPN Consortium and S. Harris of the University of Michigan, from the Network Working Group. It's Informational and dated September 2006. It obsoletes RFC 3160 💅
Status of This Memo ✨
This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 💜
Copyright (C) The Internet Society (2006).
Abstract 🌸
This doc is all about how IETF meetings and Working Groups actually work. It also covers the organizations around the IETF and walks you through the standards process. It is not a formal IETF process document. It's more of an informational overview, bestie 🧚
Table of Contents 🍓
1. Introduction ....................................................4
2. Acknowledgements ................................................5
3. What Is the IETF? ...............................................5
3.1. Humble Beginnings ..........................................6
3.2. The Hierarchy ..............................................7
3.2.1. ISOC (Internet Society) .............................7
3.2.2. IESG (Internet Engineering Steering Group) ..........8
3.2.3. IAB (Internet Architecture Board) ..................10
3.2.4. IANA (Internet Assigned Numbers Authority) .........11
3.2.5. RFC Editor .........................................11
3.2.6. IETF Secretariat ...................................12
3.3. IETF Mailing Lists ........................................12
4. IETF Meetings ..................................................13
4.1. Registration ..............................................14
4.2. Take the Plunge and Stay All Week! ........................15
4.3. Newcomer Training .........................................16
4.4. Dress Code ................................................16
4.5. Seeing Spots Before Your Eyes .............................16
4.6. Terminal Room .............................................17
4.7. Meals and Other Delights ..................................17
4.8. Social Event ..............................................18
4.9. Agenda ....................................................18
4.10. EDU to the Rescue ........................................19
4.11. Where Do I Fit In? .......................................19
4.11.1. IS Managers .......................................19
4.11.2. Network Operators and ISPs ........................19
4.11.3. Networking Hardware and Software Vendors ..........20
4.11.4. Academics .........................................20
4.11.5. Computer Trade Press ..............................20
4.12. Proceedings ..............................................21
4.13. Other General Things .....................................21
5. Working Groups .................................................22
5.1. Working Group Chairs ......................................23
5.2. Getting Things Done in a Working Group ....................24
5.3. Preparing for Working Group Meetings ......................25
5.4. Working Group Mailing Lists ...............................26
5.5. Interim Working Group Meetings ............................27
6. BOFs ...........................................................27
7. New to the IETF and Coming to a Meeting? STOP HERE!
(Temporarily) ..................................................28
8. RFCs and Internet Drafts .......................................29
8.1. Getting an RFC Published ..................................29
8.2. Letting Go Gracefully .....................................30
8.3. Internet Drafts ...........................................31
8.3.1. Recommended Reading for Writers ....................32
8.3.2. Filenames and Other Matters ........................33
8.4. Standards-Track RFCs ......................................34
8.4.1. Telling It Like It Is -- Using MUST and SHOULD
and MAY ............................................35
8.4.2. Normative References in Standards ..................36
8.4.3. IANA Considerations ................................37
8.4.4. Security Considerations ............................37
8.4.5. Patents in IETF Standards ..........................37
8.5. Informational and Experimental RFCs .......................38
9. How to Contribute to the IETF ..................................39
9.1. What You Can Do ...........................................39
9.2. What Your Company Can Do ..................................40
10. IETF and the Outside World ....................................40
10.1. IETF and Other Standards Groups ..........................40
10.2. Press Coverage of the IETF ...............................41
11. Security Considerations .......................................42
Appendix A. Related Information ...................................43
A.1. Why "the Tao"? ............................................43
A.2. Useful Email Addresses ....................................43
A.3. Useful Documents and Files ................................44
A.4. Acronyms and Abbreviations Used in the Tao ................44
Appendix B. IETF Guiding Principles ...............................45
B.1. General ...................................................45
B.2. Management and Leadership .................................45
B.3. Process ...................................................46
B.4. Working Groups ............................................46
B.5. Documents .................................................47
Informative References ............................................481. Introduction ✨
Ever since the early years, attendance at Internet Engineering Task Force (IETF) face-to-face meetings has grown phenomenally 📈 Lots of attendees are brand new to the IETF at each meeting, and lots of them end up becoming regulars. When meetings were smaller, it was pretty easy for a newcomer to get into the swing of things. Today a newcomer meets way more new people, some of whom were previously just the authors of documents or those thought-provoking emails 🤯
This doc describes a bunch of aspects of the IETF, with the goal of explaining to newcomers how the IETF works. It's going to give you a warm, fuzzy feeling and help you make the meeting and the Working Group discussions more productive for everyone 🫶
Okay, but it's totally true that a lot of IETF people never go to the face-to-face meetings at all. They're just active on the mailing lists of various IETF Working Groups 📬 Since the inner workings of Working Groups can be hard for newcomers to figure out, this doc gives you the mundane bits of info you'll need to become an active participant 🧠
The IETF is always changing ✨ The principles in this doc are expected to stay largely the same over time, but the practical details may have totally changed by the time you read it. For example, a web-based tool might have replaced an email address for requesting some sort of action 💻
The Tao mentions a lot of IETF documentation types, from BCPs to RFCs, FYIs, and STDs 📚 BCPs make recommendations for Best Current Practices in the Internet. RFCs are the IETF's main technical documentation series, politely known as "Requests for Comments." FYIs give topical and technical overviews that are introductory or appeal to a broad audience. And STDs are RFCs identified as "standards." See Section 8 for more info 🌈
The acronyms and abbreviations in this doc are usually expanded in place and are fully explained in Appendix A 🎀
This document is intended to obsolete FYI 17, RFC 3160. See Section 3.2.5 for info on what it means for one RFC to obsolete another 👑
2. Acknowledgements 🫶
The original version of this doc, published in 1994, was written by Gary Malkin 🦋 His knowledge of the IETF, his insights, and his unmatched writing style set the standard for this later revision, and his contributions to the current document are still super appreciated 💖 Paul Hoffman wrote significant portions of this revision and gave encouragement, expertise, and much-needed guidance 🍓 Other contributors include Brian Carpenter, Scott Bradner, Michael Patton, Donald E. Eastlake III, Tony Hansen, Pekka Savola, Lisa Dusseault, the IETF Secretariat, members of the User Services Working Group, and members of the PESCI design team 🌸
3. What Is the IETF? ✨
okay so the Internet Engineering Task Force is a loosely self-organized group of people who contribute to engineering and evolving Internet technologies 🫶 it's the main body that develops new Internet standard specifications. the vibe is super unusual because it exists as a collection of happenings, but it's not a corporation. no board of directors, no members, no dues 💅 if you want the deeper tea, check out [BCP95], "A Mission Statement for the IETF".
its mission is giving main character energy and includes:
- 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 between vendors, users, researchers, agency contractors, and network managers
the IETF meeting is not a conference, even though there are technical presentations 🙈 the IETF also isn't a traditional standards organization, even though lots of its specs end up becoming standards 🎀 it's made up of volunteers, and a lot of them meet three times a year to get the mission done 🌸
there's no membership in the IETF. anyone can register for and attend any meeting 🦋 the closest thing to being an IETF member is being on the IETF or Working Group mailing lists (see Section 3.3). that's where the best info about what's happening and what people are focused on lives 💜
of course, no organization can be this successful without some structure 👑 for the IETF, that structure comes from other organizations, as described in [BCP11], "The Organizations Involved in the IETF Standards Process". if you participate in the IETF and only read one BCP, make it this one 📚 it's giving essential reading.
the IETF honestly runs on its members' beliefs 🌈 one of the "founding beliefs" comes from an early quote by David Clark: "We reject kings, presidents and voting. We believe in rough consensus and running code". another early quote that became a commonly-held belief in the IETF comes from Jon Postel: "Be conservative in what you send and liberal in what you accept". iconic ✨
the IETF is really about its members 🫶 because the membership policies are so unrestrictive, IETF members come from all over the world and from lots of different parts of the Internet industry. see Section 4.11 for info about the ways that many people fit into the IETF.
one more thing newcomers need to know: the IETF in no way "runs the Internet", no matter what some people mistakenly might say 💀 it makes standards that Internet users often adopt, but it does not control, or even patrol, the Internet. so if you're hoping to be one of the overseers, you may be badly disappointed by the IETF 😭
3.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 one that non-government 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. and the 7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the first meeting with more than 100 attendees 🎉
the 14th IETF meeting was held at Stanford University in July 1989, and it was a major shift in the structure of the IETF universe 🔥 the IAB (then Internet Activities Board, now Internet Architecture Board), which until that point oversaw many "task forces", changed its structure to leave only two: the IETF and the IRTF. the IRTF is tasked with considering long-term research problems in the Internet. the IETF changed at that time too ✨
after the Internet Society (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 🌷 about one in three IETF meetings are now held in Europe or Asia, and the number of non-US attendees stays high, around 50%, even at meetings held in the United States 🌍
3.2. The Hierarchy 🪜
3.2.1. ISOC (Internet Society)
the Internet Society is an international, non-profit, membership organization that fosters the expansion of the Internet 💖 one of the ways ISOC does that is through financial and legal support of the other "I" groups described here, especially the IETF. ISOC provides insurance coverage for many of the people in the IETF process and acts as a public relations channel for the times when one of the "I" groups wants to say something to the press 📣 honestly, ISOC is one of the major unsung (and under-supported) heroes of the Internet 🫶
starting in spring 2005, ISOC also became home base for the IETF's directly employed administrative staff 💼 this is described in more detail in [BCP101], "Structure of the IETF Administrative Support Activity (IASA)". the staff initially includes only an Administrative Director (IAD) who works full-time overseeing IETF meeting planning, operational aspects of support services (the secretariat, IANA (the Internet Assigned Numbers Authority), and the RFC Editor, which are described later in this section), and the budget. he or she (currently it's a he) leads the IETF Administrative Support Activity (IASA), which handles tasks like collecting meeting fees and paying invoices, and also supports the tools for the work of IETF working groups, the IESG, the IAB, and the IRTF (more about these later in this section) 🛠️
the IASA also includes volunteers and ex officio members from the ISOC and IETF leadership 🎀 the IASA and the IAD are directed by the IETF Administrative Oversight Committee (IAOC), which is selected by the IETF community. here's how all this looks:
Internet Society
|
IAOC
|
IASA
|
IADneither the IAD nor the IAOC have any influence over IETF standards development, which is what we're getting to next 👀
3.2.2. IESG (Internet Engineering Steering Group)
the IESG is responsible for technical management of IETF activities and the Internet standards process 🧠 it administers the process according to the rules and procedures ratified by the ISOC Trustees. however, the IESG doesn't do much direct leadership, the kind you'd find in lots of other standards organizations 🙅♀️ as its name suggests, its role is to set directions rather than to give orders. the IESG ratifies or corrects the output from the IETF's Working Groups (WGs), gets WGs started and finished, and makes sure that non-WG drafts that are about to become RFCs are correct ✅
the IESG consists of the Area Directors (ADs), who are selected by the Nominations Committee (usually called "the NomCom") and are appointed for two years. the process for choosing the members of the IESG is detailed in [BCP10], "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees" 📋
the current areas and abbreviations are shown below 👇
Area Description
-----------------------------------------------------------------
Applications (APP) Protocols seen by user programs, such as
email and the web
General (GEN) 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 Operational aspects, network monitoring,
Management (OPS) and configuration
Real-time Delay-sensitive interpersonal
Applications and communications
Infrastructure (RAI)
Routing (RTG) Getting packets to their destinations
Security (SEC) Authentication and privacy
Transport (TSV) Special services for special packetsbecause the IESG has a huge amount of influence over whether Internet Drafts become RFCs, a lot of people treat the ADs like somewhat godlike creatures 😭 IETF participants sometimes reverently ask Area Directors for their opinion on a subject. however, most ADs are nearly indistinguishable from mere mortals and rarely speak from mountaintops 🏔️ in fact, when asked for specific technical comments, the ADs may often defer to members at large whom they feel know more about that area than they do 🫶
the ADs for a particular area are expected to know more about the combined work of the WGs in that area than anyone else 🤓 on the other hand, the entire IESG reviews each Internet Draft proposed to become an RFC. any AD may record a "DISCUSS" ballot position against a draft if they have serious concerns. if those concerns can't be resolved by discussion, an override procedure is defined so that at least two IESG members must express concerns before a draft can be blocked from moving forward. these procedures help make sure an AD's "pet project" doesn't make it onto the standards track if it will hurt the rest of the IETF protocols, and that an AD's "pet peeve" cannot indefinitely block something 🙈
this doesn't mean the IESG never wields power. when the IESG sees a Working Group veering from its charter, or when a WG asks the IESG to make its badly designed protocol a standard, the IESG will act.
because of its high workload, the IESG usually moves in a reactive fashion 😮💨 it eventually approves most WG requests for Internet Drafts to become RFCs, and usually only steps in when something has gone very wrong. another way to think about it is that the ADs are selected to think, not just to run the process 🧠✨ the quality of IETF standards comes both from the review they get in the Working Groups and the scrutiny that the WG review gets from the ADs 💅
the IETF is run by rough consensus, and it's the IESG that judges whether a WG has come up with a result that has community consensus. (see Section 5.2 for more on WG consensus.) because of this, one of the main reasons the IESG might block something produced in a WG is that the result didn't really gain consensus across the IETF as a whole, meaning among all of the Working Groups in all areas. for instance, the result of one WG might clash with a technology developed in a different Working Group 💥 an important job of the IESG is to watch over the output of all the WGs and help prevent IETF protocols from being at odds with each other 🧩 this is why ADs are supposed to review the drafts coming out of areas other than their own 👀
3.2.3. IAB (Internet Architecture Board) 🦋
Okay so the IAB is basically the group keeping an eye on the big picture of the Internet 👀 🌐. They focus on long-range planning and coordinating all the different areas of IETF activity, so nothing gets lost in the chaos. They keep tabs on important long-term issues and flag them to the people who should know. The IAB website is at http://www.iab.org/ 💻✨.
IAB members pay extra close attention to new stuff happening in the IETF 🔥. When someone proposes a new IETF Working Group, the IAB checks its charter for architectural consistency and integrity, which is basically making sure it all fits together and won't break things 🧩. And even before a group gets chartered, IAB members are super happy to chat about new ideas with the people pitching them 💖. Such a supportive crew, honestly 🫶.
The IAB also sponsors and organizes the Internet Research Task Force 🧪, and it runs invitational workshops that take a deep dive into specific Internet architecture issues 🍓. Usually the workshop reports make recommendations to the IETF community and to the IESG, so their ideas actually go somewhere 🚀.
The IAB also:
- Approves NomCom's IESG nominations 📝
- Acts as the appeals board for appeals against IESG actions ⚖️
- Appoints and oversees the RFC Editor 📚
- Approves the appointment of the IANA 👑
- Acts as an advisory body to ISOC 🌸
- Oversees IETF liaisons with other standards bodies 🤝
Like the IESG, IAB members are picked for multi-year positions by the NomCom, and they're approved by the ISOC Board of Trustees. Very official, very iconic 💅.
3.2.4. IANA (Internet Assigned Numbers Authority) 🎀
The core registrar for the IETF's activities is the IANA 🗂️. Lots of Internet protocols need someone to keep track of protocol items that got added after the protocol was already out there 📋. Classic examples are TCP port numbers and MIME types 🔢. The IAB has designated the IANA organization to handle these tasks, and the IANA's activities are financially supported by ICANN, the Internet Corporation for Assigned Names and Numbers 💰.
Ten years ago, nobody would have expected to see the IANA on the front page of a newspaper 📰😭. IANA's role had always been super low key 🙈. But because IANA was also the keeper of the root of the domain name system, it got pushed into the spotlight, and a bunch of people who never looked at what its role actually was ended up trashing it 💀. Nowadays the IETF is generally no longer involved in the IANA's domain name and IP address assignment functions, which are overseen by ICANN 🌈.
Even though being a registrar may not sound exciting, a lot of IETF participants will tell you how important IANA has been for the Internet 🧚. Having a stable, long-term repository run by careful and conservative operators makes it so much easier for people to experiment without worrying about messing everything up 🦋. IANA's founder, Jon Postel, was heavily relied upon to keep things in order while the Internet kept growing by leaps and bounds, and he did an amazing job until his untimely death in 1998 🥺💜.
3.2.5. RFC Editor 📚
The RFC Editor edits, formats, and publishes Internet Drafts as RFCs, working together with the IESG ✍️. An important secondary role is providing one definitive repository for all RFCs (see http://www.rfc-editor.org) 🗄️. Once an RFC is published, it is never revised 🔒. If the standard it describes changes, the standard gets re-published in another RFC that "obsoletes" the first one 🔄.
One of the most popular misconceptions in the IETF community is that the RFC Editor is performed by IANA 🙃. Nope! The RFC Editor is a separate job, although both the RFC Editor and IANA involved the same people for many years 👯. The IAB approves the organization that will act as RFC Editor and the RFC Editor's general policy 📜. The RFC Editor is funded by IASA and can be contacted by email at mailto:rfc-editor@rfc-editor.org 📧.
3.2.6. IETF Secretariat 🗓️
There are, in fact, a few people who are paid to maintain the IETF 💼. The IETF Secretariat provides day-to-day logistical support, which mainly means coordinating face-to-face meetings and running the IETF-specific mailing lists (not the WG mailing lists) 🗓️📬. The Secretariat is also responsible for keeping the official Internet Drafts directory up to date and orderly, maintaining the IETF web site, and helping the IESG do its work 🧹. It provides various tools for use by the community and the IESG 🛠️. The IETF Secretariat is under contract to IASA, which in turn is financially supported by the fees of the face-to-face meetings 💸.
3.3. IETF Mailing Lists 📬
Anyone who plans to attend an IETF meeting should join the IETF announcement mailing list, mailto:ietf-announce@ietf.org 📣. This is where all of the meeting information, RFC announcements, and IESG Protocol Actions and Last Calls get posted 📌. People who want to "get technical" can also join the IETF general discussion list, ietf@ietf.org 🤓. This is where discussions of cosmic significance happen 🌌 (Working Groups have their own mailing lists for discussions related to their work). Another mailing list, mailto:i-d-announce@ietf.org, announces each new version of every Internet Draft as it gets published 🔔.
Subscriptions to these and other IETF-run mailing lists are handled by a program called "mailman" 🐒. Mailman can be somewhat finicky about the format of subscription messages, and sometimes it interacts poorly with email programs that turn every email into an HTML file 😤. Mailman will treat you well, however, if you format your messages just the way it likes 💅.
To join the IETF announcement list, for example, send an email to mailto:ietf-announce-request@ietf.org ✉️. Enter the word 'subscribe' (without the quotes) in the Subject line of the message and in the message body. To join the IETF discussion list, send an email to <mailto:ietf-request@ietf.org> and enter the word 'subscribe' as explained above 🎯. If you decide to withdraw from either list, use the word 'unsubscribe' 👋. Your messages to mailman should have nothing other than the commands 'subscribe' or 'unsubscribe' in them, no extras 🙅♀️. Both lists are archived on the IETF web site, http://www.ietf.org/maillist.html 🗂️.
Do not, ever, under any circumstances, for any reason, send a request to join a list to the list itself! The thousands of people on the list don't need, or want, to know when a new person joins 🙈💀. Similarly, when changing email addresses or leaving a list, send your request only to the "-request" address, not to the main list. This means you!! 🫵💅
The IETF discussion list is unmoderated 🗣️. This means that everyone can express their opinions about issues affecting the Internet 🌍. However, it is not a place for companies or individuals to solicit or advertise, as noted in [BCP45], "IETF Discussion List Charter" 🚫. It is a good idea to read the whole RFC (it's short!) before posting to the IETF discussion list 📖✨. Actually, the list does have two "sergeants at arms" who keep an eye out for inappropriate postings, and there is a process for banning persistent offenders from the list, but thankfully this is extremely rare 👮♀️.
Only the Secretariat and certain IETF office holders can approve messages sent to the announcement list, although those messages can come from a variety of people 🎟️.
Even though the IETF mailing lists "represent" the IETF membership at large, it's important to note that attending an IETF meeting does not mean you'll be automatically added to either mailing list 🙅♀️💜.
4. IETF Meetings 🌸
The computer industry is absolutely rife with conferences, seminars, expositions, and all manner of other meetings 🎪. IETF face-to-face meetings are nothing like these 🦄. The meetings, held three times a year, are week-long "gatherings of the tribes" 🏕️🔥. Their primary goal is to reinvigorate the WGs so they can get their tasks done, and their secondary goal is to promote a fair amount of mixing between the WGs and the areas 🫶. The cost of the meetings is paid by the people attending and by the corporate host for each meeting (if any), although IASA kicks in additional funds for things such as the audio broadcast of some Working Group sessions 💸🎧.
For many people, IETF meetings are a breath of fresh air compared to 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 🧋. IETF meetings are of little interest to sales and marketing folks, but of high interest to engineers and developers 🧑💻🔥.
Most IETF meetings are held in North America, because that's where most of the participants are from 🇺🇸. However, meetings are held on other continents about once every year 🌍✈️. The past few meetings have had about 1,300 attendees 🥳. There have been more than 65 IETF meetings so far, and a list of upcoming meetings is available on the IETF web pages at http://www.ietf.org/meetings/0mtg-sites.txt 🗺️.
Newcomers to IETF face-to-face meetings are often in a bit of shock 😵💫. They expect them to be like other standards bodies, or like computer conferences 🤯. Fortunately, the shock wears off after a day or two, and many new attendees get super animated about how much fun they're having 🎉🥰. One particularly jarring feature of recent IETF meetings is the use of wireless Internet connections throughout the meeting space 📶. It's common to see people in a WG meeting apparently reading email or browsing the web during presentations they find uninteresting 👀. Remember, though, that they may also be checking the drafts under discussion, looking up relevant material online, or following another meeting using instant messaging 🧠💻.
4.1. Registration 💖
okay so, to attend an IETF meeting you have to register AND pay the registration fee 💸. The meeting site and advance registration get announced about two months ahead, earlier if possible ✨. An announcement goes out by email to the IETF-announce mailing list, and the info goes up on the IETF web site, http://www.ietf.org, that same day 📬.
To pre-register, you must submit your registration on the web. You can pre-register and pre-pay, pre-register and head back to the site later to pay with a credit card, pre-register and pay on-site at the meeting, or just register and pay on-site 🎟️. To get the lower registration fee, you must pay by the early registration deadline (about one week before the meeting) 🏃♀️. The fee covers all of the week's meetings, the Sunday evening reception (cash bar), daily continental breakfasts, and afternoon coffee and snack breaks 🥐☕.
Credit card payments on the web are encrypted and secure 🔐. Or, if you prefer, you can use Pretty Good Privacy (PGP) to send your payment info to the Registrar (mailto:ietf-registrar@ietf.org) 💌.
Registration is open the whole week of the meeting. Still, the Secretariat highly recommends that attendees arrive for early registration, usually beginning at noon on Sunday and continuing throughout the Sunday evening reception 🌅. The reception is a popular event where you can grab a small bite to eat and socialize with other early arrivals 🥳.
Registered attendees (and there aren't any other kind) receive a registration packet 🎁. It has lots of useful stuff, including a general orientation sheet, the most recent agenda, and a name tag 🏷️.
Attendees who pre-paid will also find their receipt in their packet 🧾. It's worth noting that neither attendee names and addresses nor IETF mailing lists are ever offered for sale. 🛡️
In your registration packet is a sheet titled "Note Well". You should indeed read it carefully, because it lays out the rules for IETF intellectual property rights 📜✨.
If you need to leave messages for other attendees, you can do that at the cork boards that are often near the registration desk 📌. These cork boards also have last-minute meeting changes and room changes 👀.
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 handed to the hotel or brought back to the Secretariat's office 📦.
Incidentally, the IETF registration desk is often a convenient place to meet people 🫶. If someone says "meet me at registration", they almost always mean the IETF registration desk, not the hotel registration desk. iykyk 😌.
4.2. Take the Plunge and Stay All Week! 🌊
IETF meetings run from Monday morning through Friday lunchtime 🗓️. Associated meetings often happen on the weekends before or after. It's best to plan to be there the whole week, so you can benefit from cross-fertilization between Working Groups and from corridor discussions 🦋. As noted below, the agenda is fluid, and there have been many instances of people missing important sessions because of last-minute scheduling changes after their travel plans were already locked in 😭. Being there the whole week is the only way to dodge that annoyance 🙅♀️.
If you can't find meetings all week that interest you, you can still make the most of it by working between sessions 💻. Most IETF attendees carry laptops, and it's really common to see tons of them in the terminal room or in the hallways working during meeting sessions 🤓. There's often good wireless Internet coverage in lots of places around the venue (restaurants, coffee shops, and so on), so catching up on email when you're not in meetings is a pretty common IETFer move 📨✨.
4.3. Newcomer Training 🧚
Newcomers are encouraged to attend the Newcomer Training, which is specially designed for first-time attendees 🌸. The orientation is organized and run by the IETF EDU team, and it's meant to give you useful intro info 📚. The session covers what's in the attendee packets, what all the dots on name tags mean, the structure of the IETF, and a bunch of other essential and enlightening topics for new IETFers 🎀.
Right after the Newcomers' Training comes the IETF Standards Process Orientation. This session demystifies a lot of the standards process by explaining what stages a document has to pass through on its way to becoming a standard, and what has to happen to advance to the next stage 🪜🔥.
There's usually plenty of time at the end for questions 🙋♀️. The Secretariat provides hard copies of the slides for the "IETF Structure and Internet Standards Process" presentation. These super useful slides are also online at www.ietf.org under "Educational Materials" 💜.
The orientation is normally held on Sunday afternoon, along with tutorials that are good for newcomers and old-timers alike ☀️. Check the agenda for exact times and locations 🗺️.
4.4. Dress Code 👗
Since attendees must wear their name tags, they must also wear shirts or blouses 👚. Pants or skirts are also highly recommended. Seriously though, lots of newcomers feel super embarrassed when they show up Monday morning in suits, only to discover everybody else is in T-shirts, jeans (shorts, if the weather permits) and sandals 🙈💀. There are people in the IETF who refuse to wear anything but suits. Luckily, they're well known (for other reasons), so they get forgiven for this particular idiosyncrasy 👑. The general rule is "dress for the weather" (unless you plan to work so hard that you won't go outside, in which case, "dress for comfort" is the rule!) 🧘♀️🌈.
4.5. Seeing Spots Before Your Eyes 🐞
Some people at the IETF have a little colored dot on their name tag, and a few have more than one 🔴🔵🟢. These dots identify people who are silly enough to volunteer for a lot of extra work 😂. The colors have the meanings shown here 🎨:
Color Meaning
--------------------------------------
Blue Working Group/BOF chair
Green Host group
Red IAB member
Yellow IESG member
Orange Nominating Committee member(Members of the press wear orange-tinted badges 📰.)
Local hosts are the people who can answer your questions about the terminal room, restaurants, and points of interest in the area 🗺️🍕.
It's important that newcomers not 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 🫶✨.
4.6. Terminal Room 💻
One of the most important things the host does (depending on your point of view) is provide Internet access for the meeting attendees 🌐. In general, wired and wireless connectivity is excellent. That's entirely thanks to the Olympian efforts of the local hosts and their ability to beg, borrow, and steal 🏅. The people and companies that donate equipment, services, and time are to be heartily congratulated and thanked 👏💖.
Although preparing far in advance of the meeting is encouraged, there may be some unavoidable "last minute" things to finish in the terminal room 🏃♀️. It can also be really useful for people who need to write trip reports or status reports while things are still fresh in their minds 📝.
You need to be wearing your badge to get into the terminal room 🪪. The terminal room has lots of power strips, lots of Ethernet ports for laptops, wireless (for the people who don't need Ethernet but still want power) 🔌, usually a printer for public use, and sometimes workstations 🖨️. What it doesn't have are terminals; the name is historical 🙃. The help desk in the terminal room is a good place to ask about network failures, although they might point you to different networking staff 🧑💻.
4.7. Meals and Other Delights 🍰
Marshall Rose once remarked that the IETF was a place to go for "many fine lunches and dinners" 🍽️. It's true that some people eat very well at the IETF, but they find the food on their own, because lunches and dinners are not included in the registration fee 😅. The Secretariat does provide appetizers at the Sunday evening reception (not meant to replace dinner), continental breakfast every morning, and (best of all) cookies, brownies, and other yummies during afternoon breaks 🍪🤤.
If you'd rather get out of the hotel for meals, the local host usually provides a list of places to eat within easy reach of the meeting site 🥡.
4.8. Social Event 🎉
Another of the most important things the host organizes and manages is the IETF social event 🥂. Sometimes the social event is computer- or high-tech-related. At one Boston IETF, for example, the social was dinner at the Computer Museum 🖥️✨. Other times, the social might be a dinner cruise or a trip to an art gallery 🎨. Note, however, that not every IETF meeting has a social event 🙃.
Newcomers are encouraged to attend the social event. Everyone is encouraged to wear their name tags and leave their laptops behind 💅. The social event is designed to give people a chance to meet on a social, rather than technical, level 🫧.
4.9. Agenda 📋
The agenda for IETF meetings is a very fluid thing. It's typically sent to the IETF announcement list a few times before the meeting, and it's also available on the web 📬. The final agenda is included in the registration packets. Of course, "final" in the IETF doesn't mean what it does elsewhere in the world 😜. The final agenda is simply the version that went to the printer 🖨️.
The Secretariat posts agenda changes on the bulletin board near the IETF registration desk (not the hotel registration desk) 📌. These late changes aren't capricious. They're made "just in time" as session chairs and speakers become aware of unanticipated clashes ⏰. The IETF is too dynamic for agendas to be locked down weeks in advance 🌪️.
The agenda also shows the room assignments for breakout rooms (where the Working Groups and BOFs meet), plus a map of where the rooms are 🗺️. Room assignments can change as the agenda changes. Some Working Groups meet multiple times during a meeting, and every effort is made to have a Working Group meet in the same room for each session 💜.
4.10. EDU to the Rescue 🦸♀️
If certain aspects of the IETF still mystify you (even after you finish reading the Tao), you'll want to drop in on the on-site training offered by the Education (EDU) team 🧠. These informal classes are designed for newcomers and seasoned IETFers alike 🎓. Besides the Newcomer Training, the EDU team offers workshops for document editors and Working Group chairs, plus an in-depth security tutorial that's a must for both novices and longtime attendees 🔐🔥. EDU sessions are usually held on Sunday afternoons ☀️. You'll find more about the EDU team at http://edu.ietf.org/ 💖.
4.11. Where Do I Fit In? 🤔
The IETF is different things to different people 🌈. Lots of people have been super active in the IETF without ever attending a meeting 🦋. You should not feel obligated to come to an IETF meeting just to get a feel for the IETF 🙅♀️. 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 the best use of your time at your first meeting would be 🫶✨.
4.11.1. IS Managers ✨
Okay so, as we've been saying this whole time, an IETF meeting is nothing like a trade show 💅. If you're going in hoping to find out what's gonna be hot in the Internet industry next year, honestly? Wrong place, bestie 🙈. You can safely assume that sitting in Working Group meetings will confuse you more than it helps you figure out what is happening, or what will be happening, in the industry 💀.
That said, nobody from the industry should NOT come, lol. As an IS manager, you might wanna think about sending specific people who are responsible for technologies that are being developed in the IETF 🦋. As these people read the current Internet Drafts and the traffic on the relevant Working Group lists, they'll get a sense of whether showing up would be worthwhile for your company or for the Working Groups 🔥.
4.11.2. Network Operators and ISPs
Running a network is already hard enough without having to grapple with new protocols or new versions of the protocols you're already dealing with 😭. If you work for the type of network that always uses the very latest hardware and software, and you're following the relevant Working Groups in your copious free time, you could absolutely find participating in the IETF valuable 💜. A fair amount of IETF work also covers many other parts of operations of ISPs and large enterprises, and operator input is super valuable for keeping this work vibrant and relevant 🫶. Honestly, many of the best operations documents from the IETF come from real-world operators, not vendors and academics 👑.
4.11.3. Networking Hardware and Software Vendors
The image of the IETF being mostly ivory tower academics may have been true in the past, but the jobs of typical attendees are now 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 and nobody from your company has ever attended an IETF meeting, it really behooves you to come to one, if for no other reason than to tell everyone else how relevant the meeting was or was not to your business 🎀.
Companies should NOT close up shop during IETF meeting weeks so everyone can go, lowkey 🙅♀️. Marketing folks, even technical marketing folks, are usually safe 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 aren't 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 write 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 🧚.
4.11.4. Academics
IETF meetings are often excellent places for computer science folks to find out what's happening with soon-to-be-deployed protocols 🤓. Professors and grad students (and sometimes overachieving undergrads) 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, no cap 🌈. Researchers are also, of course, likely to be interested in IRTF activities 🔬.
4.11.5. Computer Trade Press
If you're a member of the press and you're considering attending IETF, we've prepared a special section of the Tao just for you 🎤 -- please see Section 10.2 📰.
4.12. Proceedings
IETF proceedings are compiled in the two months following each meeting and are available on the web and on CD 💿. Be sure to look through a copy, because the proceedings are filled with information about IETF that you're not likely to find anywhere else 😍. For example, you'll find snapshots of most WG charters at the time of the meeting, which gives you a better understanding of how any given effort evolved 📜.
The proceedings sometimes start with an informative (and highly entertaining) message 🤭. Each volume contains the final (hindsight) agenda, an IETF overview, area and Working Group reports, and slides from the protocol and technical presentations 🖼️. The Working Group reports and presentations are sometimes incomplete, if the materials haven't been turned in to the Secretariat in time for publication 🥲.
An attendee list is also included, which contains names and affiliations as provided on the registration form 👀. For information about obtaining copies of the proceedings, see the web listing at http://www.ietf.org/proceedings/directory.html 🔗.
4.13. Other General Things
The IETF Secretariat, and 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 🙋♀️.
Hallway conversations are super 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 "bar BOF" is an unofficial get-together, usually in the late evening, during which a lot of work gets done over drinks 🍸. Bar BOFs spring up all over the place around an IETF meeting, like restaurants, coffee shops, and (if we are so lucky) pools 🏊♀️.
It's unwise to get between a hungry IETFer (and there isn't any other kind) and the coffee break brownies and cookies, no matter how interesting a hallway conversation is 🍪🍫. Iconic behavior, honestly.
IETFers are fiercely independent 🦁. It's safe to question opinions and offer alternatives, but don't expect an IETFer to follow orders 🙅♀️.
The IETF meetings, and the plenary session in particular, are not places for vendors to try to sell their wares 🛍️. People can totally answer questions about their company and its products, but bear in mind that the IETF is not a trade show. This does not preclude people from recouping costs for IETF-related T-shirts, buttons, and pocket protectors 👕.
There is always a "materials distribution table" near the registration desk 📋. This desk is used to make appropriate information available to 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, because the Secretariat has the right to remove material that he or she feels is not appropriate 🙏.
If you rely on your laptop during the meeting, it's a good idea to bring an extra battery 🔋. It's not always easy to find a spare outlet in some meeting rooms, and using the wireless access can drain your battery faster than you might expect 😩. If you're sitting near a power strip in a meeting room, expect to be asked to plug and unplug for others around you 🔌. Many people bring an extension cord with spare outlets, which is a great way to make friends with your neighbor in a meeting 🫶. If you need an outlet adapter, you should try to buy it in advance, because the one you need is usually easier to find in your home country ✈️.
5. Working Groups
The vast majority of the IETF's work is done in many Working Groups 🧠. At the time of this writing, there are about 115 different WGs. (The term "Working Group" is often seen capitalized, but probably not for any good reason 🙃.) [BCP25], "IETF Working Group Guidelines and Procedures", is an excellent resource for anyone participating in WG discussions 📖.
A WG is really just a mailing list with a bit of adult supervision 👩🏫. You "join" the WG by subscribing to the mailing list, and all mailing lists are open to anyone 💌. Anyone can post to a WG mailing list, although most lists require non-subscribers to have their postings moderated 🛡️. Each Working Group has one or two chairs 👑.
More important, each WG has a charter that the WG is supposed to follow 📜. The charter states the scope of discussion for the Working Group, as well as its goals 🎯. The WG's mailing list and face-to-face meetings are supposed to focus on just what's in the charter and not wander off onto 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 🤩.
5.1. Working Group Chairs
The role of the WG chairs is described in both [BCP11] and [BCP25] 📘. The IETF EDU team also offers special training for WG chairs on Sunday afternoons preceding IETF 🎓.
As volunteer cat-herders 🐈, a chair's first job is to determine the WG consensus goals and milestones, and to keep the charter up to date ✏️. Next, often with the help of WG secretaries or document editors, 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 📬. Chairs have responsibility for the technical and non-technical quality of WG output 💯. 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 😬.
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 the Working Group did 💬.) In the IETF, it's a mark of success when the WG closes up because it fulfilled its charter 🏆. This is one of the aspects of the IETF that newcomers with experience in other standards bodies have a hard time understanding 🤔. However, some WG chairs never manage to get their WG to finish, or keep adding new tasks to the charter so that the Working Group drags on for many years 🫠. The output of these aging WGs is often not nearly as useful as the earlier products, and the messy results are sometimes attributed to what's called "degenerative Working Group syndrome" 💀.
There is an official distinction between WG drafts and independent drafts, but in practice, there sometimes isn't much procedural difference 🌸. For example, many WG mailing lists also discuss independent drafts (at the discretion of the WG chair) 🦋. Procedures for Internet Drafts are covered in much more detail later in this document 📚.
WG chairs are strongly advised to go to the WG leadership training that usually happens on the Sunday preceding the IETF meeting 🎀. There's also usually a WG chairs lunch mid-week during the meeting, where chair-specific topics are presented and discussed 🥪. If you're interested in what they hear there, take a look at the slides at http://edu.ietf.org/ 👀✨
5.2. Getting Things Done in a Working Group ✨
okay bestie, the first thing that confuses SO many newbies is that face-to-face WG meetings are way less important at the IETF than they are at most other orgs 🙈. Any decision made at a face-to-face meeting also has to gain consensus on the WG mailing list. There are loads of examples of big decisions made in WG meetings that got overturned later on the list, often because someone who couldn't make it to the meeting spotted a serious flaw in the logic 💀. Also, WG meetings aren't "drafting sessions" like they are in some other standards bodies. At the IETF, drafting happens somewhere else 📝.
Another thing that messes with people's heads is that there's no formal voting 🫠. The general rule on disputed topics is that the Working Group has to reach "rough consensus," which means a very large majority of the people who care must agree. How rough consensus gets determined varies from WG to WG. Sometimes it's "humming" 🎶. If you agree with a proposal, you hum when the chair asks, and if you disagree, you keep your silence. Newcomers find it super peculiar, but it works 💅. It's up to the chair to decide when the WG has reached rough consensus 👑.
The lack of formal voting has caused some really long delays for certain proposals, but most IETF folks who've watched rough consensus come out of acrimonious debates feel the delays often lead to better protocols 🌸. (And honestly, think about it: how could you even have "voting" in a group that anyone can join, when it's impossible to count the participants? 🤷♀️) Rough consensus has been defined in lots of ways. A simple version is that strongly held objections must be debated until most people are satisfied that those objections are wrong 💜.
Some WGs have complex documents, or a complex set of documents (or even both) 😭. Shaking all the bugs out of one or more complex documents is a daunting task. To help with that, some WGs use "issue trackers," which are online lists of the open issues with the documents, the status of each issue, proposed fixes, and so on 🦋. An issue tracker doesn't just stop the WG from forgetting to do something important. It also helps when someone asks later why something was done in a particular fashion 🧠.
Another method some WGs adopt is a Working Group "secretary" to handle the juggling of the documents and the changes 🗂️. The secretary can run the issue tracker if there is one, or can simply be in charge of watching that all the decisions made on the mailing list are reflected in newer versions of the documents 🎀.
One thing you might find helpful, and possibly even entertaining, during WG sessions is following the running commentary in the Jabber room associated with that WG 💬. The running commentary is often the basis for the minutes of the meeting, but it can also include jokes, sighs, and other extraneous chatter 😂. Jabber is a free, streaming XML technology mainly used for instant messaging. You can find pointers to Jabber clients for many platforms at http://www.jabber.org. 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 WG participants during protocol development 🌈.
5.3. Preparing for Working Group Meetings 🧁
The most important thing that everyone (newcomers AND seasoned experts) should do before coming to a face-to-face meeting is read the Internet Drafts and RFCs ahead of time 📚. WG meetings are explicitly not for education. They're for developing the group's documents 🛠️. Even if you don't plan to say anything in the meeting, you should read the group's documents before attending so you can understand what's being said 👀.
It's up to the WG chair 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 (see http://www.ietf.org/meetings/wg_agenda_xx.html, where 'xx' is the meeting number), but many WG chairs are lax (if not totally negligent) about turning them in 🙄.
The Secretariat only schedules WG meetings a few weeks in advance, and the schedule often changes as little as a week before the first day ✈️. If you're only coming for one WG meeting, you may have a hard time booking your flight with such little notice, particularly if the Working Group's meeting changes schedule 😩. So keep track of the current agenda so you can book flights and hotels. But honestly? You probably shouldn't be coming for just one WG meeting 💁♀️. Your knowledge could be valuable in a few WGs, assuming you've read the drafts and RFCs for those groups 🌟.
If you're on the agenda at a face-to-face meeting, you should probably come with a few slides prepared. But don't bring a tutorial, because people are supposed to read the drafts in advance 🙅♀️. Projectors for laptop-based presentations are available in all the meeting rooms 📽️.
And here's a tip for your slides in WG or plenary presentations: don't put your company's logo on every one, even though that's 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 they're presented 💖.
5.4. 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 tons of other mailing lists related to IETF work. For example, every Working Group has its own discussion list. On top of that, some long-term technical debates have been moved off the IETF list onto lists created specifically for those topics 🗣️. It is highly recommended that you follow the discussions on the mailing lists of the Working Groups you want to attend 🫶. The more work that gets done on the mailing lists, the less work needs to be done at the meeting, which leaves time for cross pollination (i.e., attending Working Groups outside one's primary area of interest in order to broaden one's perspective) 🌈.
The mailing lists also give a forum to people who want 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'll often hear a WG chair say, "Let's take it to the list," to close a discussion 🔒.
Many IETF discussion lists use either mailman or another list manager, Majordomo 📮. They usually have a "-request" address (-request) that handles the administrative details of joining and leaving the list. (See Section 3.3 for more information on mailman.) It's generally frowned upon when this administrivia shows up on the discussion mailing list 🙃.
Most IETF discussion lists are archived 🗄️. That means all the messages sent to the list are automatically stored on a host for anonymous HTTP or FTP access. Many such archives are listed online at ftp://ftp.ietf.org/ietf-mail-archive/, or they're in a web-based archive. If you don't find the list you're looking for, send a message to the list's "-request" address (not to the list itself!) 🙋♀️. The Working Group charter listings at http://www.ietf.org/html.charters/wg-dir.html are a super useful source, but note that the page has links to old, concluded WGs 📜.
Some WG lists apply size limits on messages, particularly to keep large documents or presentations from landing in everyone's mailbox 📦. It's well worth remembering that participants don't all have broadband connections (and even those with broadband sometimes get their mail on slow connections when they travel), so shorter messages are greatly appreciated 🐢. Documents can be posted as Internet Drafts. Presentation material can be posted to a web site controlled by the sender, or sent personally to people who ask for it. Some WGs set up special sites to hold these large documents, so senders can post there first and then just send the list the URL of the document 🔗.
5.5. Interim Working Group Meetings 🌸
Working Groups sometimes hold interim meetings between IETFs 🧳. Interim meetings aren't a substitute for IETF meetings, though. 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 require AD approval and 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 send them to mailto:proceedings@ietf.org, and the group needs to take attendance 📝. Decisions tentatively made during an interim WG meeting still have to be ratified on the mailing list 💌.
6. BOFs 🦋
In order to form a Working Group, you need a charter and someone who's able to be chair 📜. To get those things, you need to get people interested so they can help focus the charter and convince an Area Director that the project is worthwhile 🙌. A face-to-face meeting is super useful for this. In fact, very few WGs get started by an Area Director. Most start after a face-to-face BOF, because attendees have expressed interest in the topic 🎉.
A Birds of a Feather (BOF) meeting has to be approved by the Area Director in the relevant area before it can be scheduled 🪶. If you think you really need a new WG, approach an AD informally with your proposal and see what they think 💭. The next step is to request a meeting slot at the next face-to-face meeting. Of course, you don't need to wait for that meeting to get some work done. You can start setting up a mailing list and discussing a charter right away 💪.
BOF meetings have a very different tone than WG meetings 🎭. The purpose of a BOF is to make sure a good charter with good milestones can be created, and that there are enough people willing to do the work needed to create standards 🏗️. Some BOFs already have Internet Drafts in process, whereas others start from scratch 🌱.
Having a draft before the BOF has an advantage: it helps focus the discussion 🔍. On the other hand, having a draft might limit what the other folks in the BOF want to do in the charter 🙃. It's important to remember that most BOFs are held to get support for an eventual Working Group, not to get support for a particular document 💜.
Many BOFs don't turn into WGs, for a variety of reasons 😔. A common problem is that not enough people can agree on a focus for the work. Another typical reason is that the work wouldn't end up being a standard. For example, the document authors might not really want to relinquish change control to a WG. (We'll discuss change control later in this document.) Only two meetings of a BOF can be scheduled on a particular subject. Either a WG has to form, or the topic should be dropped 🥀.
7. New to the IETF and Coming to a Meeting? STOP HERE! (Temporarily) 🛑
okay bestie, if you're new to the IETF and this is the only doc you plan to read before the meeting, stop here... at least for now 🫶 Then on your flight home, read the rest of the Tao ✈️🧚 By then you'll be ready to get actively involved in the Working Groups that caught your eye at the meeting, and the Tao will get you started on your way 💅
If you're planning to take part in the IETF remotely, through reading email lists and the proceedings, keep going!! 💖
8. RFCs and Internet Drafts 📚
if you're a new IETF participant and you're hunting for a particular RFC or Internet Draft, head to the RFC Editor's web pages at http://www.rfc-editor.org/rfc.html 🔍 That site also links to other RFC collections, and a lot of them have search features. If you know the number of the RFC you want, check the IETF RFC pages at http://www.ietf.org/rfc.html. For Internet Drafts, the best resource is the IETF website at http://www.ietf.org/ID.html, where you can search by title and keyword 🎀
8.1. Getting an RFC Published 🎓
one of the most common questions seasoned IETFers get from newcomers is, "How do I get an IETF standard published?" 🙈 A much better question is, "Should I write an IETF standard?" because the answer isn't always "yes" 💀 If you do decide to write a document that becomes an IETF standard, be warned that the whole process can be arduous, even though the individual steps are pretty straightforward. Lots of people get through it unscathed, though, and there's a ton of written guidance that helps authors come out with their ego more or less intact 🫶
Every IETF standard is published as an RFC (a "Request for Comments," but everyone just calls them RFCs), and every RFC starts out as an Internet Draft (usually called an "I-D") ✨ The basic steps for getting something published as an IETF standard go like this:
- Publish the document as an Internet Draft.
- Receive comments on the draft.
- Edit your draft based on the comments.
- Repeat steps 1 through 3 a few times.
- Ask an Area Director to take the draft to the IESG (if it's an individual submission). If the draft is an official Working Group product, the WG chair asks the AD to take it to the IESG.
- Make any changes deemed necessary by the IESG (this might include giving up on becoming a standard).
- Wait for the document to be published by the RFC Editor.
A much more complete explanation of these steps is in [BCP9], "The Internet Standards Process" 📖 Anyone writing drafts they hope will become IETF standards must read BCP 9 so they can follow their document's path through the process. BCP 9 (and various other documents that update it) goes into great detail on something that gets really misunderstood, even by seasoned IETF people: different types of RFCs go through different processes and have different rankings. There are six kinds of RFCs:
- Proposed standards
- Draft standards
- Internet standards (sometimes called "full standards")
- Informational documents
- Experimental protocols
- Historic documents
Only the first three (proposed, draft, and full) are standards within the IETF. A good summary of this is in [RFC1796], "Not All RFCs Are Standards," which is an aptly titled read 🙌
There are also three sub-series of RFCs, known as FYIs, BCPs, and STDs 🌈 The For Your Information sub-series was created to document overviews and topics that are introductory or that appeal to a broad audience, but honestly that series hasn't been added to in a long time 🥲 Best Current Practice documents describe how various technologies are applied on the Internet. The STD sub-series was created to identify RFCs that actually specify Internet standards. Some STDs are sets of more than one RFC, and the "standard" label applies to the whole set of documents 💜
8.2. Letting Go Gracefully 🕊️
The biggest reason some people don't want their documents on the IETF standards track is that they have to give up change control of the protocol. Like, the second you propose that your protocol become an IETF standard, you must fully relinquish control of it 😭 If there's general agreement, parts of the protocol can be completely changed, whole sections can be ripped out, new things can be added, and the name can be changed. Iconic? Maybe not for your ego, but it's how it works 💅
Some authors find it super hard to give up control of their pet protocol. If you're one of those people, don't even think about trying to make your protocol an IETF standard 🙈 On the other hand, if your goal is the best standard possible with the widest implementation, the IETF process might be right up your alley 🔥
Also, change control on Internet standards doesn't end once the protocol hits the standards track 👀 The protocol itself can be changed later for a number of reasons, and the most common one is that implementors discover a problem while they're implementing the standard. Those later changes are also under the control of the IETF, not the editors of the standards document. Main character energy for the IETF, not the editors 👑
IETF standards exist so that people will use them to write Internet programs that interoperate 🧩 They don't exist to document the (possibly wonderful) ideas of their authors, and they don't exist so a company can say, "We have an IETF standard." If a standards-track RFC only has one implementation (whereas two are required for it to advance on the standards track), it was probably a mistake to put it on the standards track in the first place 💀
8.3. Internet Drafts 📝
First things first: every document that ends up in the RFC repository starts life as an Internet Draft 🌸 Internet Drafts are tentative. They're meant for readers to comment on, so authors can mull over those comments and decide which ones to incorporate. To remind everyone of how tentative they are, Internet Drafts are automatically removed from the online directories after six months ⏳ They are most definitely not standards or even specifications. As [BCP9] says:
"An Internet Draft is NOT a means of 'publishing' a specification; specifications are published through the RFC mechanism.... Internet Drafts have no formal status, and are subject to change or removal at any time. Under no circumstances should an Internet Draft be referenced by any paper, report, or Request-for-Proposal, nor should a vendor claim compliance with an Internet Draft".
You can always tell when someone doesn't understand the IETF (or is intentionally trying to fool people) because they brag about having published an Internet Draft 🙄 It takes no significant effort, bestie.
When you submit an Internet Draft, you give some publication rights to the IETF 🎁 That's so your Internet Draft is freely available to everyone who wants to read and comment on it. The rights you do and don't give up are described in [BCP78], "IETF Rights in Contributions" ⚖️
There's a super useful checking tool at http://tools.ietf.org/tools/idnits/idnits.pyht 🧹 Using it before you turn in an Internet Draft will help keep the draft from getting rejected for errors in form and formatting. Lowkey a must-do.
An I-D should have approximately the same format as an RFC. Contrary to what many people believe, an I-D does not need to look exactly like an RFC, but if you use the same formatting procedures the RFC Editor uses when you create your I-Ds, it'll make the RFC Editor's life easier when your draft gets published as an RFC 🥰 [RFC2223], "Instructions to RFC Authors", describes the nroff formatting the RFC Editor uses. There's also a tool called "xml2rfc," available from http://xml.resource.org/, that takes XML-formatted text and turns it into a valid Internet Draft 🫧
An Internet Draft can be either a Working Group draft or an individual submission. Working Group drafts are usually reviewed by the Working Group before being accepted as a WG item, although the chairs have the final say 👑
If you want to check the status of a particular draft, can't remember its exact name, or want to find out which drafts a WG is working on, there are two handy tools 🔎 The "Internet Drafts Database Interface," at https://datatracker.ietf.org/public/idindex.cgi, lets you search for a draft by author, Working Group, date, or filename. The "I-D Tracker," at https://datatracker.ietf.org/public/pidtracker.cgi, is especially useful for authors who want to track their draft's progress through the publication process 📈
There are some informal rules for Internet Draft naming that have evolved over the years 🎀 Internet Drafts that revise existing RFCs often have "bis" in their draft names, meaning "again" or "twice." For example, a draft might be called "draft-someone-rfc2345bis-00.txt" ✨
8.3.1. Recommended Reading for Writers 📚💖
Before you create the first draft of your Internet Draft, you should read four documents 🤓
- More important than just explaining formatting, [RFC2223] also explains what needs to be in an Internet Draft before it can become an RFC. It describes all the sections and notices that will need to be in your document, and it's good to have them there from the beginning so readers aren't surprised when you add them in later versions.
- [BCP22], "Guide for Internet Standards Writers," gives tips that will help you write a standard that leads to interoperability. For instance, it explains how to choose the right number of protocol options, how to respond to out-of-spec behavior, and how to show state diagrams 🧠
- The online "Guidelines to Authors of Internet Drafts," at
http://www.ietf.org/ietf/1id-guidelines.txt, has up-to-date information about the process for turning in Internet Drafts, along with the most current boilerplate that has to be included in each one 📋 - When you think you're finished with the draft process and are ready to request that the draft become an RFC, you should definitely read "Checklist for Internet Drafts (I-Ds) Submitted for RFC Publication," at
http://www.ietf.org/ID-Checklist.html. It's a list of common issues that have been known to stop documents at the IESG 🚫 Honestly, you should read it well before you're finished, so you don't have to make a bunch of last-minute changes 😭
Also, visit the IETF Tools web pages at http://tools.ietf.org, where you'll find pointers to other tools that will automate some of your work for the IETF 🤖🫶
8.3.2. Filenames and Other Matters ✨
okay bestie, when your Internet Draft is ready to go, send it to the Internet Drafts administrator at mailto:internet-drafts@ietf.org 💌 There's a real human on the other end whose job is to check you've got the minimum stuff needed before the draft can be published. 🫶 When you submit version one, you also tell the admin the filename you'd like. 📁 If the draft is an official Working Group product, the name starts with draft-ietf-, then the WG's designation, then a descriptive word or two, then 00.txt. 🎀
For example, a draft from the S/MIME WG about creating keys could be draft-ietf-smime-keying-00.txt 🔑 If it's not a WG product, the name starts with draft-, then the last name of one of the authors, then a descriptive word or two, then 00.txt. 💅 So a draft by someone named Smith could be draft-smith-keying-00.txt. If you're an individual submission but your draft is about a particular WG, authors sometimes add the WG name after their own name, like draft-smith-smime-keying-00.txt. 🦋
You're totally allowed to suggest names! 🌈 But the final call belongs to the Internet Drafts administrator (and, if it's an official WG draft, the WG chair) 👑 If you follow the naming guidelines at http://www.ietf.org/ietf/1id-guidelines.txt, your suggestion has a really good chance of being approved. 💖
After the first edition, the number in the filename goes up. So the second edition of that S/MIME draft would be draft-ietf-smime-keying-01.txt ✨ Heads up though: sometimes the filename changes after a few versions, like when a personal effort gets adopted by a Working Group. 🌸 When that happens, the number goes back to -00. And please, please tell the Internet Drafts administrator the old name so the databases stay accurate. 🙈💜
8.4. Standards-Track RFCs 🔥
okay so the whole process for creating and advancing a standard is written up in [BCP9] 📖 Once an Internet Draft has been discussed enough and there's rough consensus that what it says would make a useful standard, it gets presented to the IESG for consideration. 👑 If it's an official WG draft, the WG chair sends it to the right Area Director after it's gone through Working Group last call. If it's an individual submission, the author or editor sends it to the right Area Director themselves. 💅 [BCP9] also explains the appeals process for anyone who feels a WG chair, an AD, or the IESG got a decision wrong about creating or advancing a standard. ⚖️
After the I-D is submitted to the IESG, they announce an IETF-wide last call. 📣 This gets the attention of people who weren't following along, and it can sometimes lead to more changes in the draft. 🌟 It's also the moment when WG folks who felt unheard can share their comments with everyone. 🫶 The IETF last call lasts two weeks for drafts from WGs and four weeks for individual submissions. ⏰
If the IESG approves the draft to become an Internet standard, they ask the RFC Editor to publish it as a Proposed standard. 🎉 After it's been a Proposed standard for at least six months, the RFC's author (or the right WG chair) can ask for it to become a Draft standard. 🦋 But before that happens, someone has to convince the right Area Director that there are at least two independent, interoperable implementations of each part of the standard 🔥 This is a super solid test of whether the standard is useful as a whole, and it's also an excellent way to check whether the standard was actually readable. 📚🙈
A few things usually happen at this stage. First, it's really common to find that some specifications need rewording, because one implementor thought they meant one thing and another implementor thought they meant something totally different. 😭 Another classic moment is when none of the implementations actually tried to build a few of the features. Those features get removed, not just because nobody tested them, but also because they weren't needed. 🧹✨
Don't be shocked if a standard never graduates from Proposed to Draft. Honestly? Most of the standards people actually use are Proposed standards that never move forward. 💀 Maybe nobody took the time to push them along, or maybe some of their normative references are still at Proposed standard, or maybe everyone just had more important stuff going on. 🌈
A few years after a document has been a Draft standard, it can become an Internet standard, also called a "full standard." 👑 This can technically happen in as little as four months, but it's rare. It doesn't happen often, and it's usually saved for protocols that the Internet absolutely cannot function without. 🫶 The IESG goes over the document with a fine-tooth comb and looks for evidence of widespread deployment before making a Draft standard an Internet standard. 🔍💖
8.4.1. Telling It Like It Is -- Using MUST and SHOULD and MAY 💅
Writing specs that get implemented the way you actually want is a bit of an art form 🎨 If you keep the spec super short, with just a list of requirements, implementors tend to take way too much leeway. 😬 But if you make it super wordy with lots of suggestions, implementors tend to miss the actual requirements (and often disagree with your suggestions anyway) 🙃 The sweet spot is somewhere in between. ✨
One way to make interoperable implementations more likely is to be really clear about what's being mandated. 💜 Early RFCs used all kinds of expressions to explain what was needed, so implementors didn't always know which parts were suggestions and which were requirements. 🤷♀️ So IETF standards writers generally agreed to limit their wording to a few specific words with a few specific meanings. 🎀
[STD3], "Requirements for Internet Hosts -- Application and Support", written way back in 1989, had a short list of words that seemed useful: "must", "should", and "may". 🦕 Those definitions were later updated and refined in [BCP14], "Key words for use in RFCs to Indicate Requirement Levels", which is widely referenced in current Internet standards. 🌟 BCP 14 also specifically defines "must not" and "should not", and it lists a few synonyms for the defined words. 📖
So, in a standard, if you want to make it clear you're using the BCP 14 definitions, you should do two things. 💅 First, refer to BCP 14 (most people call it RFC 2119, because that's what BCP 14 tells you to do), so the reader knows how you're defining your words. 🫶 Second, point out which instances of the words come from BCP 14. The accepted way to do that is to capitalize them, which is why you see "MUST" and "SHOULD" in capitals in IETF standards. 🔠✨
BCP 14 is a short doc, and honestly everyone reading or writing IETF standards should read it 🙌 The definitions of "must" and "must not" are pretty clear. The definitions of "should" and "should not" though? Those cause a LOT of discussion in WGs 😭 When someone reviews an Internet Draft, the question often comes up: "Should that sentence have a MUST or a SHOULD in it?" 🤔 It's a really good question, because specs shouldn't have gratuitous MUSTs, but they also shouldn't have SHOULDs where a MUST is needed for interoperability. 🎯 This gets right to the heart of the over-specifying vs. under-specifying debate. 🔥
8.4.2. Normative References in Standards 📚
Writing IETF standards gets tricky for a lot of newcomers (and plenty of long-time IETF folks too 🙈) with the rule about "normative references" to non-IETF documents or to other RFCs. 💅 A normative reference points to a document that must be followed in order to implement the standard. 🫶 A non-normative reference, sometimes called an "informative reference," is helpful to an implementor but isn't needed. 💡
An IETF standard may make a normative reference to any other standards-track RFC at the same standards level or higher, or to any "open standard" developed outside the IETF. 🌈 The "same level or higher" rule means that before a standard can move from Proposed to Draft, every RFC it normatively references must also be at Draft or Internet standard. 👑 This gives implementors assurance that everything in a Draft or Internet standard is really stable, even the stuff referenced from outside. 🦋 The catch is that this can delay publication of the Draft or Internet standard by many months (sometimes even years) while the other documents catch up. 😩⏳
There's no hard-and-fast rule for what counts as an "open standard," but generally it means a stable standard that anyone can get a copy of (they might have to pay for it), made by a generally recognized standards group. 📖 If the external standard changes, you have to reference the particular version of it in your spec, like by stating its date. 📅 Some external standards bodies don't keep old standards around, which is a problem for IETF standards that need to be used in the future. 😬 When in doubt, a draft author should ask the WG chair or the appropriate Area Director whether a particular external standard can be used in an IETF standard. 🫶✨
8.4.3. IANA Considerations 🧚
More and more IETF standards need to register various protocol parameters, like named options in the protocol. 📋 As we noted in Section 3.2.4, the main registry for all IETF standards has long been IANA. 💜 Because the registries that standards need are so large and varied, IANA needs specific info about how to register parameters, what not to register, who (if anyone) decides what gets registered, and so on. 🗂️
Anyone writing an Internet standard that may need a new IANA registry, or new values in an existing one, needs to read [BCP26], "Guidelines for Writing an IANA Considerations Section in RFCs" 🙌 It explains how RFC authors should properly ask IANA to start a registry or take one over. 🌸 And just so you know, IANA also maintains registries that were started long before BCP 26 existed. 🕰️💅
8.4.4. Security Considerations 🔐
Okay, this one is serious, bestie. 😭 Every RFC and Internet Draft is required to have a "Security Considerations" section. 🔒 This section should describe any known vulnerabilities of the protocol, possible threats, and mechanisms or strategies to address them. 🛡️ Don't gloss over this section. Especially don't write something like "Here's our protocol, if you want security, just use IPsec." 💀 That absolutely won't fly, because it doesn't answer the question of how IPsec interacts with your protocol, and vice versa. 🙅♀️ If you're not sure how to handle this section in your draft, check with your WG chair 👑 For more on writing a good security considerations section, see [BCP72], "Guidelines for Writing RFC Text on Security Considerations." 🫶🔐✨
8.4.5. Patents in IETF Standards 💡
okay bestie, patents have been causing SO much drama lately 😭 the IETF wants its standards used everywhere and actually tested out in the real world, right? but if making a product means you have to pay for a patent license, people are way less likely to implement the standard 💀 so the classic rule is "use good non-patented technology where possible" 🎀
BUT it's not always possible 🙈 sometimes a patent shows up after a standard already exists. sometimes there's a patent on something so valuable there's no non-patented equivalent. and sometimes the patent holder is super generous 🫶 and promises every implementor a royalty-free license, which makes it almost as easy as if no patent existed at all ✨
how the IETF handles patents is seriously a hot topic. the official rules for ALL intellectual property rights (IRP) in IETF docs, not just patents, live in [BCP78] and [BCP79], "Intellectual Property Rights in IETF Technology". if you're in an IETF Working Group, these are honestly worth reading 📚 because they're the rules everyone agrees to follow 💅
patent holders who freely let people use their patents to implement IETF standards get SO much goodwill 🌸 and it's more common than you'd think! for example, RFC 1822 is a license from IBM for one of its security patents, and the security community loved them for it 🥹 (meanwhile a bunch of other companies became total pariahs for being intractable about their security patents 💀)
if you're writing an Internet Draft and you know about a patent that applies to your tech, do not list the patent in the document 🚫 instead, check the IETF IPR Disclosure Page (linked off the main IETF web site) to see how to proceed. RFCs don't mention IPR because RFCs never change once published, but IPR knowledge can change at any time 🦋 so an IPR list inside an RFC could end up incomplete and misleading. [BCP9] has the specific text to add to RFCs when the author knows about IPR issues 🫶
8.5. Informational and Experimental RFCs 🧚
as we mentioned earlier, not every RFC is a standard 🙌 tons of important RFCs aren't on the standards track at all! right now there are two designations for RFCs that aren't meant to be standards: Informational (like the Tao ☯️) and Experimental. (there's also a third one, Historic, but that's reserved for docs that were on the standards track and got removed because nobody uses them anymore, or because newer thinking shows the tech is actually harmful to the Internet 💀)
the role of Informational RFCs gets debated constantly 😭 a lot of people love having them, especially for specs created outside the IETF that IETF docs still reference. they're also handy for specs that come before work a Working Group is doing. BUT some people call Informational RFCs "standards" even though they're not, usually to trick the gullible public into buying or supporting something 🙄 when that happens, the debate starts all over again 🔥
Experimental RFCs are for specs that are interesting but where it's unclear whether many people will implement them, or whether they'll even work once deployed 🧪 so if a spec solves a problem but nobody seems to think the problem matters, or nobody's gonna bother fixing it with the spec, it might get labeled Experimental. if it gets popular later (or proves it works well) it can be re-issued as a standards-track RFC ✨ Experimental RFCs are also used to get people experimenting with tech that looks standards-track material but still has unanswered questions 👀
the IESG has guidelines on how it picks between Informational and Experimental status: http://www.ietf.org/u/ietfchair/info-exp.html. if you're making a doc that might end up Experimental, knowing the current thinking will help you justify your choice 💖
9. How to Contribute to the IETF 🌈
9.1. What You Can Do 🙋♀️
Read 👀 -- review the Internet Drafts in your area of expertise and comment on them in the Working Groups. jump into the discussion in a friendly, helpful way, with the goal being the best Internet standards possible. listen way more than you speak 🫶 if you disagree, debate the technical issues: never attack the people 🚫
Implement 💻 -- write programs that use the current Internet standards. standards aren't worth much unless Internet users can actually get them ✨ implement even the "minor" standards, since they'll become less minor once they show up in more software 😭 if you find any problems with the standards, report them to the appropriate Working Group so the standard can be clarified in later revisions. one of the oft-quoted tenets of the IETF is "running code wins" 🔥 so you can help the standards you love spread by creating more running code 🎀
Write ✍️ -- edit or co-author Internet Drafts in your area of expertise. do it for the benefit of the Internet community, NOT to get your name (or, even worse, your company's name) on a document 💅 draft authors get all kinds of technical (and sometimes personal) criticism, so receive it with equanimity 🧘♀️ and use it to make your draft better, so you can produce the best and most interoperable standard 💜
9.2. What Your Company Can Do 🏢
Share 🤝 -- avoid proprietary standards. if you're an implementor, show a strong preference for IETF standards 💖 if the IETF standards aren't as good as the proprietary ones, work to make the IETF standards better 🛠️ if you're a purchaser, avoid products that use proprietary standards competing with the IETF's open standards, and tell the companies you buy from that you're doing so 🙅♀️
Open Up 🔓 -- if your company controls a patent used in an IETF standard, convince the company to make it available at no cost to everyone implementing the standard. in the past few years, patents have caused a lot of serious problems for Internet standards because they stop some companies from implementing the standards freely 😭 luckily, lots of companies have generously offered unlimited licenses for particular patents to help IETF standards flourish 🌟 those companies usually get positive publicity for not being as greedy or short-sighted as other patent holders 👑
Join 🧡 -- become a member of ISOC. even more important, urge any company that has benefited from the Internet to become a corporate member of ISOC, since that has the greatest financial benefit for the group 🎉 it'll also, of course, benefit the Internet as a whole 🌍
10. IETF and the Outside World 🌍
10.1. IETF and Other Standards Groups 🤝
as much as many IETF folks would love to think otherwise, the IETF does NOT exist in a standards vacuum 🙃 there are lots of (maybe too many!) other standards organizations whose decisions affect the Internet 💀 there are also a fair number of standards bodies that ignored the Internet for ages and now want a piece of the action 👀
in general, the IETF tries to keep cordial relationships with other significant standards bodies 💖 this isn't always easy, since many of those bodies are structured very differently from the IETF, and the IETF is mostly run by volunteers who would honestly rather write standards than meet with representatives from other bodies 😅 still, some other standards bodies make a huge effort to interact well with the IETF despite the obvious cultural differences 🫶
at the time of writing, the IETF has liaisons with big standards bodies, including the ITU (International Telecommunication Union), the W3C, the Unicode Consortium, and ISO/IEC JTC1 (Joint Technical Committee of the International Organization for Standardization and International Electrotechnical Commission) 🌈 as the IAB Charter [BCP39] puts it, "Liaisons are kept as informal as possible and must be of demonstrable value in improving the quality of IETF specifications" ✨ in practice, the IETF prefers liaisons to happen directly at the Working Group level, with formal relationships and liaison documents in a backup role 🎀
some of these liaison tasks fall to the IESG, and others fall to the IAB 🧩 detail-oriented readers will learn tons about the formal methods for dealing with other standards bodies in [BCP102], "IAB Processes for Management of IETF Liaison Relationships", and [BCP103], "Procedures for Handling Liaison Statements to and from the IETF" 🤓 the best place to check whether the IETF has any formal liaison at all is the list of IETF liaisons at www.ietf.org/liaisonActivities.html 🔍 the list shows there are many different liaisons to ISO/IEC JTC1 subcommittees 💜
10.2. Press Coverage of the IETF 📰✨
okay so the IETF is one of the most well-known groups helping move the Internet forward, so of course the computer press (and even the trade press) wants to cover what it does 👀 lately a few magazines have assigned reporters and editors to cover the IETF in depth over a long stretch of time. these reporters have plenty of scars from articles they got wrong, like incorrect statements about the status of Internet Drafts, quotes from people who aren't involved in the IETF work, and so on 🫶
there are two big categories of press mistakes 💅 the first is saying the IETF is considering something when really there's just an Internet Draft sitting in a Working Group. the second is saying the IETF approved something when all that actually happened was that an Informational RFC got published. honestly the press isn't fully to blame, since they usually get the story from a company trying to get publicity for a protocol it developed or at least supports 🙈 a little research would probably get reporters in touch with someone who could set them straight, like a WG chair or an Area Director. the default press contact for the IETF is the IAD, who can be reached at mailto:iad@ietf.org 💖
the fact that reporters who got it wrong once still come back to IETF meetings proves it's possible to get it right eventually 🌈 still, IETF meetings are definitely not for reporters who are naive about the IETF process (but if you're a reporter reading this document, that's a very good sign!!) 🎀 and if you think you'll walk out of a meeting with a hot story, you're likely to be disappointed 😭
so it's not surprising that some IETFers would rather keep the press as far away from meetings as possible 🙈 a bit of press for protocols that are almost finished and will matter to the industry within the next year can be a good thing ✨ but it's the rare reporter who can resist over-hyping a baby protocol as the next savior of the Internet. those stories do way more harm than good, both for the readers and for the IETF 💀
the main reason a reporter might want to attend a meeting isn't to cover hot technologies (you can do that from your desk by reading the mailing lists) but to meet people face-to-face 🦋 the catch is that the most interesting people are also the busiest during the meeting, and some folks tend to run away the second they see a press badge 😭 still, meetings are excellent places to meet and talk with document authors and Working Group chairs, which is super valuable for reporters covering how protocols are progressing 🧚
reporters who want to know "what the IETF is doing" on a particular topic would be wise to talk to more than one person who's active on that topic, and should probably talk to the WG chair in any case 💅 you can't figure out what will happen with a draft by looking at the draft or asking its author. the good news is all WGs have archives a reporter can dig through for recent signs of where a draft is headed 📜 the bad news is few reporters have the time or the inclination to do that research 😩 and because the IETF doesn't have a press liaison, magazines or newspapers that run a story with errors won't hear about it directly from the IETF, so they often don't know what they did wrong and might easily do it again later 💔
11. Security Considerations 🔐
okay this one's short and sweet bestie 💖 Section 8.4.4 explains why each RFC is required to have a Security Considerations section, and gives some idea of what it should and should not contain. other than that info, this document doesn't touch on Internet security at all 🙈
Appendix A. Related Information 📚
A.1. Why "the Tao"? ☯️
pronounced "dow" 🌸 Tao is the basic principle behind the teachings of Lao-tse, a Chinese master. its familiar symbol is the black-and-white yin-yang circle ✨ Taoism sees the universe as a single organism, with human beings as interdependent parts of a cosmic whole 🌈 Tao is sometimes translated as "the way," but according to Taoist philosophy the true meaning of the word can't be expressed in words 🫶
A.2. Useful Email Addresses 💌
here are some useful email addresses 💕 these may change from time to time, so it's a good idea to check the IETF web pages for the correct address before you send your mail 🙈
Address Description
-----------------------------------------------------------------
agenda@ietf.org Requests for agenda slots at IETF
meetings
ietf-action@ietf.org Requests for things to be done when you
don't know exactly where to send the
request
ietf-info@ietf.org General questions about the IETF
ietf-registrar@ietf.org Questions about registration, meeting
locations, and fees
ietf-request@ietf.org Requests to join/leave IETF lists
ietf-secretary@ietf.org Questions for the Secretariat
ietf-web@ietf.org Questions or comments about the IETF
web site
internet-drafts@ietf.org Internet Draft submissions and queries
proceedings@ietf.org Where to send Working Group minutes and
slides for the IETF Proceedings
iana@iana.org Internet Assigned Numbers Authority
rfc-editor@rfc-editor.org RFC Editor
statements@ietf.org Incoming liaison statements from other
organizationsonline upload pages are planned for the future to make it easier to submit Internet Drafts, Proceedings, and Liaison statements 🚀
A.3. Useful Documents and Files 🗂️
the IETF web site, http://www.ietf.org, is the best source for info about meetings, Working Groups, Internet Drafts, RFCs, IETF email addresses, and so much more 🌟 click on "Additional Information" to find a bunch of helpful links. Internet Drafts and other documents are also available in the "ietf" directory on anonymous FTP sites worldwide 💾 for a list of those sites, see http://www.ietf.org/shadow.html.
check the IESG web pages, http://www.ietf.org/iesg.html, for up-to-date info about drafts processed, RFCs published, and documents in Last Call, plus the monthly IETF status reports 📊
A.4. Acronyms and Abbreviations Used in the Tao 🔤
here are some of the acronyms and abbreviations from this document, so you're never lost in the alphabet soup 🍜
Term Meaning
-----------------------------------------------------------------
AD Area Director
BCP Best Current Practice
BOF Birds of a Feather
FAQ Frequently Asked Question(s)
FYI For Your Information (RFC)
IAB Internet Architecture Board
IAD IETF Administrative Director
IANA Internet Assigned Numbers Authority
IAOC IETF Administrative Oversight Committee
IASA IETF Administrative Support Activity
ICANN Internet Corporation for Assigned Names and
Numbers, http://www.icann.org/
I-D Internet Draft
IESG Internet Engineering Steering Group,
http://www.ietf.org/iesg.html
IETF Internet Engineering Task Force,
http://www.ietf.org/
INET Internet Society Conference,
http://www.isoc.org/isoc/conferences/inet/
IPR Intellectual property rights
IRTF Internet Research Task Force, http://www.irtf.org/
ISO International Organization for Standardization,
http://www.iso.ch/
ISO-IEC/JTC1 Joint Technical Committee of the International
Organization for Standardization and
International Electrotechnical Commission,
http://www.jtc1.org/
ISOC Internet Society, http://www.isoc.org
ITU International Telecommunication Union,
http://www.itu.int
RFC Request for Comments
STD Standard (RFC)
W3C World Wide Web Consortium, http://www.w3.org/
WG Working GroupAppendix B. IETF Guiding Principles 🧭✨
okay bestie, if you've made it this far in the Tao, you've learned a LOT about how the IETF works 🥹 this appendix sums up much of what you've read and adds a few new points to ponder 💜 make sure you read through all the principles, because taken together they give you a whole new slant on what makes the IETF work 🌈
B.1. General 🌸
P1. the IETF works by an open process and by rough consensus 🫶 this applies to everything about how the IETF runs, including creating IETF documents and deciding on the processes that get used. but the IETF also watches experiments and running code with interest, and that should apply to the organization's operational processes too 🔥
P2. the IETF works in areas where it has, or can find, technical competence 🧠
P3. the IETF depends on a volunteer core of active participants 💖
P4. membership in the IETF or its WGs isn't fee-based or organizationally defined 💅 it's based on self-identification and active participation by individuals 🦋
B.2. Management and Leadership 👑
P5. the IETF recognizes leadership positions and gives decision-making power to the leaders, but decisions are subject to appeal ⚖️
P6. delegation of power and responsibility is essential to the IETF working well 🙌 as many individuals as possible will be encouraged to take on leadership of IETF tasks 🌟
P7. dissent, complaint, and appeal are a consequence of the IETF's nature and should be treated as normal events 😅 but ultimately it's a fact of life that certain decisions can't be effectively appealed 💀
P8. leadership positions are for fixed terms (although there's no formal limit on the number of terms that may be served) 🗓️
P9. it's important to develop future leaders within the active community 🌱
P10. a community process is used to select the leadership 🗳️
P11. leaders are empowered to make the judgment that rough consensus has been demonstrated 💜 without formal membership, there are no formal rules for consensus 🤷♀️
B.3. Process 🛠️
P12. although the IETF needs clear, publicly documented process rules for the normal cases, there should be enough flexibility for unusual cases to be handled with common sense 🧚 we apply personal judgment and only codify things when we're certain (but we do codify who can make personal judgments) 📜
P13. technical development work should be carried out by tightly chartered and focused Working Groups 🎯
P14. parts of the process that have proved impractical should be removed or made optional ✂️
That's the end of this part, and the Tao is seriously iconic 🌈💖
B.4. Working Groups ✨
P15. Working Groups (WGs) should be primarily responsible for the quality of their output, and therefore for obtaining early review. WG chairs, as WG leaders, are backed up by the IETF leadership, which should act as a quality backstop 🫶
P16. WGs should be primarily responsible for assessing the negative impact of their work on the Internet as a whole, and therefore for obtaining cross-area review. The IETF leadership should act as a cross-area backstop 🌍
P17. Early review of documents is more effective in dealing with major problems than late review. Catch it early, bestie 💅
P18. Area Directors (ADs) are responsible for guiding the formation and chartering of WGs, for giving them direction as necessary, and for terminating them 👑
P19. WG chairs are responsible for ensuring that WGs execute their charters, meet their milestones, and produce deliverables that are ready for publication 📋
P20. ADs are responsible for arranging backstop review and final document approval 🎀
B.5. Documents 📄
P21. IETF documents often start as personal drafts, may become WG drafts, and are approved for permanent publication by a leadership body independent of the WG or individuals that produced them. It's a whole glow-up arc 🦋
P22. IETF documents belong to the community, not to their authors. But authorship is recognized and valued, and so are lesser contributions than full authorship 🫶
P23. Technical quality and correctness are the primary criteria for reaching consensus about documents. Facts over vibes, always ✨
P24. IETF specifications may be published as Informational, Experimental, Standards Track, or Best Current Practice 🌸
P25. IETF Standards Track specifications are not considered to be satisfactory standards until interoperable independent implementations have been demonstrated. (This is the embodiment of the "running code" slogan.) But, on legal advice, the IETF does not take responsibility for interoperability tests and does not certify interoperability. Receipts first, badges later 🧾💜
P26. IETF processes are currently published as Best Current Practice documents 🍓
P27. Useful information that is neither a specification nor a process may be published as Informational 🧚
P28. Obsolete or deprecated specifications and processes may be downgraded to Historic. Retirement arc, but make it iconic 🌈
P29. The standards track should distinguish specifications that have been demonstrated to interoperate ⭐
P30. Standards Track and Best Current Practice documents must be subject to IETF wide rough consensus (Last Call process). WG rough consensus is normally sufficient for other documents 📣
P31. Substantive changes made after a document leaves a WG must be referred back to the WG. No sneaky edits after the WG hands it off, periodt 🙅♀️
P32. The IETF determines requirements for publication and archiving of its documents 🗂️
Informative References 📚
- [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [BCP10] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004.
- [BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
- [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [BCP22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [BCP25] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
- [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [BCP39] Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.
- [BCP45] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005, November 2000.
- [BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
- [BCP78] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
- [BCP79] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
- [BCP95] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004.
- [BCP101] Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005.
- [BCP102] Daigle, L. and Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005.
- [BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005.
- [RFC1796] Huitema, C., Postel, J., and S. Crocker, "Not All RFCs are Standards", RFC 1796, April 1995.
- [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
- [STD3] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
Authors' Addresses 🧑💻
Paul Hoffman
VPN Consortium
127 Segre Place
Santa Cruz, CA 95060
US
EMail: paul.hoffman@vpnc.org
Susan Harris
1722 Chandler Road
Ann Arbor, MI 48104
US
EMail: srh@umich.eduFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔐
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🙏
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌷
📦 where this page comes from
- ietf: rfc4677 2006-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms