RFC 3160
The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force
RFC 3160: The Tao of IETF, the Novice's Guide 💖
Okay bestie, this is the FYI that tells you how the IETF actually works!! 🎀✨
Here's the quick title-block tea 🫖:
- RFC 3160 (filed as FYI 17 🦋), The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force
- Author: S. Harris, from Merit Network 💅
- Date: August 2001 🌸
- Category: Informational. It's giving "here's some info," not "you must do this" 🧚
- Obsoletes: RFC 1718 💀 (this one is the glow-up)
Status of This Memo
Okay so this memo is just here to give information to the Internet community 🌈. It does not specify an Internet standard of any kind, so don't treat it like a rulebook. Distribution is unlimited, so share it with everyone 💜.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. 🔒
Abstract
This doc is the inside scoop on how IETF meetings and Working Groups run 🎀. It also covers the organizations that are connected to the IETF and gives you the rundown on the standards process 📚. Super helpful, no cap 💅.
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 3
1. What Is the IETF? . . . . . . . . . . . . . . . . . . . . . 4
1.1 Humble Beginnings. . . . . . . . . . . . . . . . . . . . 5
1.2 The Hierarchy . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 ISOC . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 IESG . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 IAB. . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 IANA . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 RFC Editor . . . . . . . . . . . . . . . . . . . . 8
1.2.6 IETF Secretariat . . . . . . . . . . . . . . . . . 9
1.3 IETF Mailing Lists. . . . . . . . . . . . . . . . . . . 9
2. IETF Meetings . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Registration . . . . . . . . . . . . . . . . . . . . . 11
2.2 Newcomers' Orientation. . . . . . . . . . . . . . . . . 12
2.3 Dress Code. . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Seeing Spots Before Your Eyes . . . . . . . . . . . . . 13
2.5 Terminal Room . . . . . . . . . . . . . . . . . . . . . 13
2.6 Meals and Other Delights. . . . . . . . . . . . . . . . 14
2.7 Social Event. . . . . . . . . . . . . . . . . . . . . . 14
2.8 Agenda. . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9 Where Do I Fit In?. . . . . . . . . . . . . . . . . . . 15
2.9.1 IS Managers. . . . . . . . . . . . . . . . . . . 15
2.9.2 Network Operators and ISPs . . . . . . . . . . . 15
2.9.3 Networking Hardware and Software Vendors . . . . 15
2.9.4 Academics . . . . . . . . . . . . . . . . . . . 16
2.9.5 Computer Trade Press . . . . . . . . . . . . . . 16
2.10 Proceedings. . . . . . . . . . . . . . . . . . . . . . 16
2.11 Other General Things . . . . . . . . . . . . . . . . . 17
3. Working Groups. . . . . . . . . . . . . . . . . . . . . . . 18
3.1 Working Group Chairs . . . . . . . . . . . . . . . . . .18
3.2 Getting Things Done in a Working Group. . . . . . . . . 19
3.3 Preparing for Working Group Meetings . . . . . . . . 19
3.4 Working Group Mailing Lists . . . . . . . . . . . . . 20
3.5 Interim Working Group Meetings . . . . . . . . . . . . 21
4. BOFs. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5. New to the IETF? STOP HERE! (Temporarily). . . . . . . . . 22
6. RFCs and Internet Drafts . . . . . . . . . . . . . . . . . 22
6.1 Getting a Standard Published . . . . . . . . . . . . . 22
6.2 Letting Go Gracefully . . . . . . . . . . . . . . . . . 24
6.3 Internet Drafts . . . . . . . . . . . . . . . . . . . . 24
6.3.1 Recommended Reading for Writers . . . . . . . . . 25
6.3.2 Filenames and Other Matters . . . . . . . . . . . 26
6.4 Standards-Track RFCs . . . . . . . . . . . . . . . . . 26
6.4.1 Telling It Like It Is -- Using MUST and
SHOULD and MAY. . . . . . . . . . . . . . . . . . 27
6.4.2 Normative References in Standards . . . . . . . . 28
6.4.3 IANA Considerations . . . . . . . . . . . . . . . 29
6.4.4 Security Considerations . . . . . . . . . . . . . 29
6.4.5 Patents in IETF Standards . . . . . . . . . . . . 30
6.5 Informational and Experimental RFCs . . . . . . . . . . 31
7. How to Contribute to the IETF -- What You Can Do . . . . . . 31
7.1 What Your Company Can Do . . . . . . . . . . . . . . . 32
8. IETF and the Outside World . . . . . . . . . . . . . . . . . 33
8.1 IETF and Other Standards Groups . . . . . . . . . . . . 33
8.2 Press Coverage of the IETF. . . . . . . . . . . . . . . 33
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1 Tao . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.2 Useful E-mail Addresses . . . . . . . . . . . . . . . . 35
9.3 Useful Documents and Files. . . . . . . . . . . . . . . 35
9.4 Acronyms and Abbreviations Used in the Tao . . . . . . 36
9.5 Documents Cited in the Tao . . . . . . . . . . . . . . 36
Security Considerations . . . . . . . . . . . . . . . . . . . . 37
Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 37
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 38Introduction
Okay so over the last few years, the number of people showing up to IETF face-to-face meetings has grown phenomenally 📈😭. A lot of attendees are brand new at every meeting, and lots of them end up becoming regulars 🫶. Back when the meetings were smaller, it was pretty easy for a newcomer to find their footing 🌸. Now? A newcomer meets SO many new people, and some of them were previously just the authors of docs or those thought-provoking emails they've been reading 🤯.
This doc walks through a bunch of IETF stuff, with the goal of explaining to newcomers how the IETF works 💅. It's meant to give you a warm, fuzzy feeling 🧸 and help you make the meetings and Working Group discussions more productive for everyone 🔥.
Of course, it's true that lots of IETF people never go to the face-to-face meetings at all 🙈. Instead, they're super active on the mailing lists of various IETF Working Groups 📬. Since Working Groups can be hard for newcomers to figure out, this FYI gives you the mundane bits of info you'll need to become an active participant 💖.
There are a lot of IETF document types mentioned in the Tao, from BCPs to RFCs and FYIs 📄. (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," and FYIs provide topical and technical overviews that are introductory or appeal to a broad audience. See Section 6 for more information.) 🦋
The acronyms and abbreviations in this doc are usually expanded right where they show up, and they're all explained fully in Section 9 📚✨.
Acknowledgements
The original version of this document, 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 🌟. His contributions to the current draft are also super appreciated 🫶. Paul Hoffman wrote significant portions of this revision and gave encouragement, expertise, and much-needed guidance 💜. Other contributors include Scott Bradner, Michael Patton, Donald E. Eastlake III, the IETF Secretariat, and members of the User Services Working Group 🎀.
1. What Is the IETF?
The Internet Engineering Task Force is a loosely self-organized group of people who contribute to the engineering and evolution of Internet technologies. 💖 It's the principal body engaged in developing new Internet standard specifications 🔥. The IETF is unusual because it exists as a collection of happenings, but it's not a corporation and has no board of directors, no members, and no dues 🦋. Main character energy, honestly 👑.
Its mission 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 🌈; and
- 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, although there are technical presentations 🎤. The IETF is also not a traditional standards organization, even though lots of specifications get made that become standards ✨. The IETF is made up of volunteers, and many of them meet three times a year to get the IETF mission done 💅.
There is no membership in the IETF 🙅♀️. Anyone may 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 1.3) 📬. That's where the best info about current IETF activities and focus can be found 💜.
Of course, no organization can be as successful as the IETF is without having some sort of structure 🏗️. In the IETF's case, that structure is provided by other organizations, as described in BCP 11, "The Organizations Involved in the IETF Standards Process." If you participate in the IETF and only read one BCP, this is the one you should read. 📖🔥
1.1 Humble Beginnings
Okay, the origin story is iconic 🥹. 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 🚀. Then the 7th IETF, held at MITRE in McLean, Virginia in July, 1987, was the first meeting with over 100 attendees 🎉😭.
The 14th IETF meeting was held at Stanford University in July 1989 🌲. It marked a major change in the structure of the IETF universe 🌌. The IAB (then Internet Activities Board, now Internet Architecture Board), which until that time 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 also changed at that time 💅.
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 🌍. Now one in five IETF meetings are held in Europe or Asia, and the number of non-US attendees continues to be high, about 50%, even at meetings held in the US 🫶✨.
1.2 The Hierarchy
1.2.1 ISOC (Internet Society) ✨
Okay bestie, the Internet Society is an international, non-profit, membership organization that fosters the expansion of the Internet 🌐. One of the ways ISOC does this is by giving financial and legal support to the other "I" groups, especially the IETF 💖. ISOC's oversight of the IETF is remarkably hands-off, so lowkey loads of IETF participants don't even know it's there 🙈. ISOC provides insurance coverage for many of the people in the IETF process, and it acts as a public relations channel when one of the "I" groups wants to say something to the press 📣. Honestly, ISOC is one of the major unsung (and under-funded) heroes of the Internet 🦸♀️💅
1.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 that have been ratified by the ISOC Trustees. However, the IESG doesn't do much direct leadership, the kind you'd find in many other standards organizations, so it's not giving "boss" 🙃. The IESG ratifies or corrects the output from the IETF's Working Groups, 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 (which is usually called "Nomcom") and are appointed for two years. The process for choosing the members of the IESG is detailed in BCP 10, "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees."
The current areas and abbreviations are:
- Applications (APP) Protocols seen by user programs, such as
e-mail 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
- Routing (RTG) Getting packets to their destinations
- Security (SEC) Authentication and privacy
- Transport (TSV) Special services for special packets
- User Services (USV) Support for end users and user support
organizationsBecause the IESG has a great deal of influence on whether Internet Drafts become RFCs, a lot of people look at the ADs as somewhat godlike creatures 😭. IETF participants sometimes reverently ask an Area Director 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 have more knowledge than they do in that area 🙌.
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 discusses each Internet Draft that is proposed to become an RFC. At least two IESG members must express concerns before a draft can be blocked from moving forward. These checks help make sure that an AD's "pet project" doesn't make it onto the standards track if it will have a negative effect on the rest of the IETF protocols 🛡️.
This is not to say that 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 the WG's badly designed protocol a standard, the IESG will act. In fact, because of its high workload, the IESG usually moves in a reactive fashion. It 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 to just run the process 🧠. The quality of IETF standards comes both from the review they get in the Working Groups and the review that the WG review gets from the ADs ✨.
The IETF is run by rough consensus, and it is the IESG that decides if a WG has come up with a result that has a real consensus 🤝. Because of this, one of the main reasons the IESG might block something produced in a WG is that the result did not really gain consensus in the IETF as a whole, that is, 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 to help prevent IETF protocols that are at odds with each other 🫶. This is why ADs are supposed to review the drafts coming out of areas other than their own.
1.2.3 IAB (Internet Architecture Board) 🔭
The IAB is responsible for keeping an eye on the "big picture" of the Internet 🌌. It focuses on long-range planning and coordination among the various areas of IETF activity. The IAB stays informed about important long-term issues in the Internet, and brings these topics to the attention of people it thinks should know about them.
IAB members pay special attention to emerging activities in the IETF. When a new IETF working group is proposed, the IAB reviews its charter for architectural consistency and integrity. Even before the group is chartered, IAB members are more than willing to discuss new ideas with the people proposing them 💬.
The IAB also sponsors and organizes the Internet Research Task Force, and convenes invitational workshops that provide in-depth reviews of specific Internet architectural issues. Typically, the workshop reports make recommendations to the IETF community and to the IESG 📝.
The IAB 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 the ISOC
- Oversees IETF liaisons with other standards bodies
Like the IESG, IAB members are selected for multi-year positions by the Nomcom, and are approved by the Board of Trustees of the ISOC 🎀.
1.2.4 IANA (Internet Assigned Numbers Authority) 🗂️
The core registrar for the IETF's activities is the IANA 📚. Many Internet protocols require that someone keep track of protocol items that were added after the protocol came out. Typical examples of the kinds of registries needed are for TCP port numbers and MIME types. The IAB has designated the IANA organization to perform these tasks, and the IANA's activities are financially supported by ICANN, the Internet Corporation for Assigned Names and Numbers.
Five years ago, nobody would have expected to ever see the IANA mentioned on the front page of a newspaper 📰. IANA's role had always been very low key. The fact that IANA was also the keeper of the root of the domain name system forced it to become a much more public entity, one which was badly maligned by a variety of people who never looked at what its role was 😤. 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 interesting, many IETF participants will testify to how important IANA has been for the Internet 🥹. Having a stable, long-term repository run by careful and conservative operators makes it much easier for people to experiment without worrying about messing things up. 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 a fine job of it until his untimely death in 1998 🕊️.
1.2.5 RFC Editor 📝
The RFC Editor edits, formats, and publishes Internet Drafts as RFCs, working in conjunction with the IESG. An important secondary role is to provide 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 will be re-published in another RFC that "obsoletes" the first 🔁.
One of the most popular misconceptions in the IETF community is that the role of the RFC Editor is performed by IANA 🙈. In fact, 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 ISOC and can be contacted by e-mail at rfc-ed@rfc-editor.org 💌.
1.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. The IETF Secretariat is financially supported by the fees of the face-to-face meetings 🍓.
1.3. IETF Mailing Lists 📬
okay so if you're planning to attend an IETF meeting, you should totally join the IETF announcement mailing list, ietf-announce@ietf.org 💌 This is where all the meeting info, Internet Draft and RFC announcements, and IESG Protocol Actions and Last Calls get posted. If you want to "get technical," you can also join the IETF discussion list, ietf@ietf.org 🤓 This is where discussions of cosmic significance happen! (Working Groups have their own mailing lists for talking about their own work.)
Subscriptions to these and other IETF lists are handled by a program called Majordomo. Majordomo is kinda finicky about how subscription messages are formatted, and it doesn't get along well with email programs that turn every message into an HTML file 🙄 It will treat you well, though, if you format your messages exactly how it likes. To join the announcement list, for example, send an email to:
ietf-announce-request@ietf.orgPut the word 'subscribe' (without the quotes) in the Subject line and in the message body. To join the discussion list, send an email to:
ietf-request@ietf.organd put 'subscribe' in there the same way. If you ever want to leave either list, use the word 'unsubscribe.' Your messages to Majordomo should contain nothing but the commands 'subscribe' or 'unsubscribe' 💅
Both lists are archived on the IETF web site:
http://www.ietf.org/maillist.htmlOkay, this next part is so important. 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 there don't need, or want, to know when someone new joins 😭 Same goes for changing your email address or leaving a list: send that request only to the "-request" address, not the main list. This means you!! 🫵
The IETF discussion list is unmoderated, so anyone can share their opinions about issues affecting the Internet ✨ But it's not a place for companies or individuals to solicit or advertise, as noted in "IETF Discussion List Charter," RFC 3005. It's a good idea to read the whole RFC before posting to the IETF discussion list (it's short, I promise!) 🌸
Only the Secretariat can send messages to the announcement list.
Even though the IETF mailing lists "represent" the IETF membership at large, attending an IETF meeting does not mean you'll be automatically added to either one. Not gonna lie, that one stings a little 🥺 but it's important to know!
2. IETF Meetings 🎀
The computer industry is absolutely rife with conferences, seminars, expositions, and all kinds of other meetings. IETF face-to-face meetings are nothing like those! These meetings happen three times a year and they're week-long dweebfests 🤓 Their primary goal is to reinvigorate the WGs so they can get their tasks done, and their secondary goal is to get a fair amount of mixing going between the WGs and the areas. The people attending and the corporate host for each meeting pay the costs, although ISOC kicks in extra funds for things like the multicast simulcast of some Working Group sessions 💸
For a lot of people, IETF meetings are a total breath of fresh air compared to standard computer industry conferences. There's no exposition hall, few tutorials, and no big-name industry pundits. Instead there's lots of work, plus a healthy amount of time for socializing 🧚 IETF meetings aren't really for sales and marketing folks, but they're super interesting to engineers and developers.
Most IETF meetings are held in North America, because that's where most of the participants are from. Meetings do happen on other continents about once every year or two 🌍 The past few meetings have had about 2,500 attendees. There have been over 50 IETF meetings so far, and you can check out a list of upcoming ones on the IETF web pages:
http://www.ietf.org/meetings/0mtg-sites.txtNewcomers 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. Luckily, the shock wears off after a day or two, and lots of new attendees get super animated about how much fun they're having 🦋 One especially jarring feature of recent IETF meetings is the use of wireless Internet connections throughout the meeting space. It's super common to see half the people in a WG meeting reading email or browsing the web during presentations they find uninteresting 💀
2.1. Registration 📝
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 of the meeting (earlier if possible) ⏰ An announcement goes out by email to the IETF-announce mailing list, and information shows 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 have a few options: you can pre-register and pre-pay, pre-register and come back to the Web site later to pay with a credit card, pre-register and pay on-site at the meeting, or just register and pay on-site 💳 If you want the lower registration fee, you have to pay by the early registration deadline (about one week before the meeting). Your registration fee covers all of the week's meetings, the Sunday evening reception (cash bar), daily continental breakfasts, and afternoon coffee breaks ☕
Credit card payments on the web are encrypted and secure. Or, if you'd rather, you can use PGP to send your payment information to the Registrar at ietf-registrar@ietf.org 🔐
Registration is open all week during the meeting. However, the Secretariat highly recommends that attendees arrive for early registration, starting at noon on Sunday and going on through the 5:00 Sunday evening reception 🥂 The reception is a popular event where you can grab a bite to eat and socialize with other early arrivals.
Registered attendees (and there aren't any other kind) get a registration packet 🎁 It has lots of useful stuff in it, including a general orientation sheet, the most recent agenda, and a name tag. If you pre-paid, your receipt will be in your packet too. It's worth knowing that neither attendee names and addresses nor IETF mailing lists are ever offered for sale. Pinky promise 🤙
2.2. Newcomers' Orientation 🧭
Newcomers are encouraged to attend the Newcomers' Orientation, which is especially designed for first-time attendees 🌈 It's organized and run by the IETF Secretariat, and it's meant to provide useful introductory info. The orientation usually lasts about 30 minutes and covers what's in the attendee packets, what all the dots on name tags mean, the structure of the IETF, and lots of other essential and enlightening topics for new IETFers.
Right after the Newcomers' Orientation 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 be done to move on to the next stage 📚 The Standards Process Orientation also lasts about 30 minutes.
There's plenty of time at the end for questions. The Secretariat also hands out materials that include an overview of the IETF, a list of important files available online, and hard copies of the slides from the "IETF Structure and Internet Standards Process" presentation. These super useful slides are also available online at www.ietf.org under "Additional Information" 🗂️
The orientation is held on Sunday afternoon before the 5:00 p.m. reception (check the agenda for the exact time and location). Be advised that attending the orientation does NOT mean you can go to the reception early! 🙃
2.3. 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 are embarrassed when they show up Monday morning in suits, only to find that everybody else is wearing t-shirts, jeans (shorts, if the weather permits), and sandals 😅 There are people in the IETF who refuse to wear anything other than suits. Fortunately, they're well known (for other reasons), so they're forgiven for this particular idiosyncrasy. The general rule is "dress for the weather" (unless you plan to work so hard you won't go outside, in which case, "dress for comfort" is the rule!) 🌤️
2.4. Seeing Spots Before Your Eyes 🔵
Some people at the IETF will have a little colored dot on their name tag, and a few people have more than one 🎯 These dots identify people who are silly enough to volunteer for a lot of extra work. The colors mean the following:
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 🫶
2.5. 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 📶 This is entirely thanks to the Olympian efforts of the local hosts and their ability to beg, borrow, and steal. The people and companies who donate their equipment, services, and time are to be heartily congratulated and thanked 👑
While preparation far in advance of the meeting is encouraged, there may be some unavoidable "last minute" things that can get done in the terminal room. It can also be useful for people who need to write trip reports or status reports while things are still fresh in their minds 📝 The terminal room provides workstations, one or two printers, and ports for laptops.
2.6. 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 prefer to get out of the hotel for meals, the local host usually provides a list of places to eat within easy reach of the meeting site 🌮
2.7. Social Event 🎉
Another of the most important things organized and managed by the host is the IETF social event. Sometimes the social event is computer or high-tech related. At the 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 🎨
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. Put the laptop down, bestie 💖
2.8 Agenda ✨
okay so the agenda is a very fluid thing 🌊 It gets sent to the IETF announcement list, updated, three times before the meeting, and it's also up on the web. The agenda for the 50th IETF, for example, lives at http://www.ietf.org/meetings/agenda_50.html 💻 The final agenda comes in the registration packets. BUT "final" in the IETF doesn't mean what it means everywhere else 🙃 The final agenda is just whichever version went to the printer. The Secretariat posts agenda changes on the bulletin board near the IETF registration desk (not the hotel registration desk) 📌 Don't go to the wrong desk, bestie!
The agenda also shows the breakout room assignments (that's where the Working Groups and BOFs meet) plus a map of where the rooms are 🗺️ Room assignments can change as the agenda changes, so keep checking. Some Working Groups meet more than once during a meeting, and every attempt is made to have a Working Group meet in the same room for each session 🫶
2.9 Where Do I Fit In? 🦋
the IETF is different things to different people 💅 Lots of people have been super active in the IETF and have never attended an IETF meeting. You should not feel obligated to come to an IETF meeting just to get a feel for the IETF. The guidelines below (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 🌸
2.9.1 IS Managers
as discussed throughout this document, an IETF meeting is nothing like any trade show you've ever been to 😭 IETF meetings are singularly bad places to go if you want to find out what will be hot in the Internet industry next year. You can safely assume that going to Working Group meetings will confuse you more than it helps you understand what is happening, or will be happening, in the industry 💀
This is not to say that no one from industry should go to IETF meetings! As an IS manager, you might want to consider sending specific people who are responsible for technologies that are under development in the IETF. As these people read the current Internet Drafts and the traffic on the relevant Working Group lists, they'll get a sense of whether or not their presence would be worthwhile for your company or for the Working Groups 🧚
2.9.2 Network Operators and ISPs
running a network is 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, attending the IETF meeting might be really valuable 👑 The closer you are to the bleeding edge of networking, particularly in routing and switching, the more likely it is that you'll be able to learn and contribute at an IETF meeting 🔥
2.9.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 no one from your company has ever attended an IETF meeting, it behooves you to come to a meeting, if for no other reason than to tell everyone else how relevant the meeting was (or wasn't) to your business 🎀
This is not to say that companies should close up shop during IETF meeting weeks so everyone can go! 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, particularly 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, chosen for their ability to write complete and useful trip reports 📝
2.9.4 Academics
IETF meetings are often excellent places for computer science folk to find out what's happening in the way of 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 fields of interest 🤓 Wandering into different Working Group meetings can have the same effect as going to symposia and seminars in your department ✨
2.9.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 8.2.
2.10 Proceedings 📚
IETF proceedings are compiled in the two months following each meeting, and they're available on the web, on CD, and in print 🖨️ Be sure to look through a copy! The proceedings are packed with information about IETF that you're not likely to find anywhere else 🫶 For example, you'll find snapshots of most WG charters as they stood at the time of the meeting, which gives you a much better understanding of how any given effort evolved 🦋
The proceedings usually start with an informative (and highly entertaining) message from Steve Coya, the Executive Director of the IETF 🥹 Each volume of 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 weren't turned in to the Secretariat in time for publication 😅
An attendee list is also included! It contains names, affiliations, work and fax phone numbers, and e-mail addresses, 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 🌈
2.11 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! Nobody is judging you, I promise 💖
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 an IETF meeting, in places 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 🍪 I'm serious, don't do it.
IETFers are fiercely independent 💅 It's safe to question opinions and offer alternatives, but don't expect an IETFer to follow orders 🙅♀️
The IETF, and the plenary session in particular, are not places for vendors to try to sell their wares. People can certainly answer questions about their company and its products, but bear in mind that the IETF is not a trade show 🛑 This does not preclude people from recouping costs for IETF-related t-shirts, buttons, and pocket protectors 👕 (the pocket protectors are iconic, no notes)
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, etc.). Please check with the Secretariat before placing materials on the desk, because the Secretariat has the right to remove material that they feel is not appropriate 🙏
3.0 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 a very good reason 🙃) [BCP 25], "IETF Working Group Guidelines and Procedures," is an excellent resource for anyone participating in WG discussions 📖 BCP 25, "IETF Working Group Guidelines and Procedures," is an excellent resource for anyone participating in WG discussions, so go read it, periodt 💅
Okay, correction on that last bit, because I don't want to misquote anything! The original text reads: BCP 25, "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 📬 Some IETF WG mailing lists only let subscribers post to the list, while others let anyone post. Each Working Group has one or two chairs 🧑🏫
More importantly, each WG has a charter that the WG is supposed to follow 📜 The charter states the scope of discussion for the Working Group, as well as its goals. The WG's mailing list and face-to-face meetings are supposed to focus on just what is in the charter, and not wander off on other "interesting" topics 🙄 Of course, looking a bit outside the scope of the WG is occasionally useful, but the large majority of the discussion should be on the topics listed in the charter. In fact, some WG charters actually specify what the WG will not do, particularly if there were some attractive but nebulous topics brought up while the charter was being drafted 🚫 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 🍿
3.1 Working Group Chairs 🧭
The role of the WG chairs is described in both BCP 11 and BCP 25. Basically, their job is to keep the discussion moving forward toward the milestones in the WG charter, which are usually the publication of one or more RFCs 🚀 They aren't meant to be taskmasters, but they are responsible for assuring positive forward motion and preventing random wandering 🌷
As you can imagine, 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 keep going after a WG is closed, still discussing the same topics the Working Group did 📨) In the IETF, it's a mark of success when 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 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 called "degenerative Working Group syndrome" 💀
One important role of the chair is to decide which Internet Drafts get published as "official" Working Group drafts, and which don't 📝 In practice, there's actually not much procedural difference between WG drafts and independent drafts. 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 new chairs' training lunch on the first day of the IETF meeting 🥪 If you're curious about what they hear there, take a look at the slides at http://www.ietf.org/wgchair/index.htm 🎀
3.2. Getting Things Done in a Working Group ✨
okay so this one confuses SO many newbies 😭 face-to-face WG meetings are way less important at the IETF than they are at pretty much every other org. Any decision made in a meeting ALSO has to get consensus on the WG mailing list, no exceptions 💅 there are loads of examples of big decisions made in the room that got totally overturned on the list, usually because someone who couldn't make it spotted a serious flaw in the logic 🙈
another thing that trips people up is that there's no formal voting 💀 on disputed topics the WG has to reach "rough consensus," which basically means a very large majority of the people who care have to agree. HOW it gets determined is different from WG to WG 🦋 yes the lack of voting has caused some seriously long delays for some proposals, but most IETF folks who've watched rough consensus come out of acrimonious debates feel the delays usually lead to better protocols 🫶 and honestly? how would you even vote in a group anyone can join, when you can't possibly count everyone? iykyk 💜
3.3. Preparing for Working Group Meetings 🎀
the most important thing everyone should do before a face-to-face meeting, newbies and seasoned experts alike, is read the Internet Drafts and RFCs beforehand 📚 WG meetings are explicitly NOT for education, bestie. they're for developing the group's documents ✨ even if you don't plan on saying a single word in the meeting, read the group's documents first so you can actually follow what's being said 🧚
the WG chair sets the meeting agenda, usually a few weeks ahead 🍓 if you want something discussed, tell the chair!! the agendas for all WG meetings are posted in advance (see http://www.ietf.org/meetings/wg_agenda_xx.html, where xx is the meeting number), but ngl many WG chairs are lax (if not totally negligent) about turning them in 💀
the Secretariat only schedules WG meetings a few weeks out, and the schedule can change by as little as a week before day one 😩 if you're only coming for one WG meeting, booking a flight with that little notice can be a nightmare, especially if the group's meeting time moves. so keep track of the current agenda so you can book flights and hotels 🌸 but real talk? you probably shouldn't come for just one WG meeting 👑 your knowledge could be valuable in a few WGs, as long as you've read the drafts and RFCs for those groups
if you're giving a presentation at a face-to-face meeting, come with a few slides prepared 🎀 projectors for laptop presentations are in every meeting room. and here's a tip for your slides: DON'T put your company's logo on every one 🙅♀️ I know it's common practice outside the IETF, but the IETF frowns on that corporate advertising, and most presenters don't even put a logo on their opening slide. the IETF is about technical content, not company boosterism 💅
3.4. Working Group Mailing Lists 💌
as we mentioned earlier, the IETF announcement and discussion mailing lists are the central lists for IETF activities 📬 but there are SO many other lists related to IETF work too. like, every Working Group has its own discussion list 🦋 and some long-term technical debates got moved off the main IETF list onto lists made just for those topics 🍓 it is highly recommended that everybody follows the discussions on the lists of the WGs they want to attend 🫶 the more work gets done on the lists, the less work needs to happen at the meeting, which leaves time for cross pollination (aka attending WGs outside your main area of interest to broaden your perspective) 🌈
the mailing lists are also a forum for people who want to follow along with, or contribute to, the WGs' efforts but can't make it to the IETF meetings 💜
most IETF discussion lists use Majordomo and have a "-request" address that handles the admin stuff of joining and leaving the list (see Section 1.3 for more information on Majordomo) 📝 it's generally frowned upon when that administrivia shows up on the discussion list itself 🙈
most IETF discussion lists are archived too 🗄️ that means every message sent to the list is automatically stored on a host for anonymous FTP access. lots of these archives are listed online at ftp://ftp.ietf.org/ietf-mail-archive/ 🧚 if you can't find the list you want, send a message to the list's "-request" address (NOT to the list itself, please, bestie 😭).
3.5 Interim Working Group Meetings 🌷
WGs sometimes hold interim meetings between IETFs 📅 but interim meetings are NOT a substitute for IETF meetings, okay?? a group can't just decide to skip a meeting in a place they're not fond of and meet in Cancun three weeks later, for example 💀 interim meetings need AD approval and have to be announced at least one month in advance ⭐ the location and timing also need to allow fair access for all participants 🫶 and just like regular IETF meetings, someone needs to take notes and send them to minutes@ietf.org, and the group needs to take attendance 📋
4. BOFs 🧁
so to form a Working Group you need a charter AND someone who can 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 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. and of course, you don't need to wait for that meeting to get some work done, like setting up a mailing list and starting to discuss a charter 💌
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, while others start totally from scratch 🧚
having a draft before the BOF can really help focus the discussion ✨ but on the other hand, a draft might limit what everyone else in the BOF wants to put 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 💜
plenty of BOFs don't turn into WGs, and there are a bunch of reasons why 💀 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. like, if the document authors don't really want to hand change control over to a WG 😬 (we'll discuss change control later in this document 🫶). and 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 🥀
5. ** New to the IETF? STOP HERE! (Temporarily) ** 🛑
-----------------------------------------
okay bestie, if you're new to the IETF and this is the ONLY reference you plan to read before coming to the meeting, stop here 🛑 at least temporarily. then on your flight home, read the rest of the Tao 🧚 by that time you'll be ready to get actively involved in the WGs that caught your eye at the meeting, and the Tao will get you started on your way 🦋
this is literally the most important tip in this whole section, so don't skip it 🫶
6. RFCs and Internet Drafts 📚
if you're a new IETF participant and looking for a particular RFC or Internet Draft, go to the RFC Editor's Web pages at http://www.rfc-editor.org/rfc.html 🌈 that site also has links to other RFC collections, lots with search features. if you know the number of the RFC you want, go to the IETF RFC pages at http://www.ietf.org/rfc.html ✨ for Internet Drafts, the best resource is the IETF web site at http://www.ietf.org/ID.html, where you can search by title and keyword 🔍
6.1. Getting a Standard 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: the overall process may be arduous, even if the individual steps are pretty straightforward 💀 lots of people get through it unscathed though, and there's plenty 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 (often called an "I-D") 🦋 the basic steps for getting something published as an IETF standard are:
- 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 BCP 9, "The Internet Standards Process." 📖 anyone who writes a draft they hope will become an IETF standard MUST read BCP 9... wait, no caps here, it's "must read" in the original, so bestie, read it 💜 BCP 9 goes into great detail on a topic that's very often misunderstood, even by seasoned IETF participants: 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") ⭐
- Experimental protocols 🧪
- Informational documents 📚
- Historic standards 🕰️
only the first three (proposed, draft, and full) are standards within the IETF 💅 a good summary of this can be found in the aptly titled RFC 1796, "Not All RFCs are Standards." 🙃
there are also three sub-series of RFCs, known as FYIs, BCPs, and STDs 🎀 the For Your Information (FYI) RFC sub-series was created to document overviews and topics that are introductory or appeal to a broad audience 🌈 frequently, FYIs are created by groups within the IETF User Services Area. Best Current Practice (BCP) documents describe the application of various technologies in the Internet 🧚 the STD RFC sub-series was created to identify RFCs that do in fact specify Internet standards. some STDs are actually sets of more than one RFC, and the "standard" designation applies to the whole set of documents 🫶
6.2 Letting Go Gracefully 🦋
okay so the biggest reason people don't want their docs on the IETF standards track is that they have to give up change control 😭. the second you propose your protocol as an IETF standard, you have to fully let go of it. if there's general agreement, parts of the protocol can be totally changed, whole sections can get ripped out, new stuff can get added, and even the name can change 💀.
some authors find it SO hard to let go of their precious pet protocol 🥺. if that's you, don't even think about trying to make your protocol an IETF standard 🙈. but if your goal is the best standard possible with the widest implementation, the IETF process might be your thing ✨.
also, change control on Internet standards doesn't stop once the protocol hits the standards track 👀. the protocol can be changed later for a bunch of reasons, and the most common one is that implementors find a problem while they're implementing the standard. those later changes are also controlled by the IETF, not by the editors of the standards document. no cap, the editors don't get the final say 💅.
IETF standards exist so 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 (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 💀.
6.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 docs. they're meant for readers to comment on, so authors can think about those comments and decide which ones to fold into the draft 🧠. to remind everyone how tentative they are, Internet Drafts get automatically removed from the online directories after six months ⏳. they are most definitely NOT standards or even specifications 🙅♀️. as BCP 9 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) when they brag about having published an Internet Draft 🙃. it takes no real effort at all 💀.
an I-D should have roughly the same format as an RFC 📝. contrary to what lots of people believe, an I-D doesn't 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 🫶. RFC 2223, "Instructions to RFC Authors," describes the nroff formatting the RFC Editor uses 🎀.
an Internet Draft can be either a Working Group draft or an individual submission 🌈. Working Group drafts are usually reviewed by the chair before they get accepted as a WG item 👑.
6.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, RFC 2223 also explains what needs to be in an Internet Draft before it can become an RFC 🔥. this document 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 🙌.
- BCP 22, "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,"
http://www.ietf.org/ietf/1id-guidelines.txt, has up-to-date info about the process for submitting Internet Drafts, plus the most current boilerplate that has to be included in each Internet Draft 📋. - When you think you're finished with the draft process and ready to request that your draft become an RFC, you should DEFINITELY read "Considerations for Internet Drafts,"
http://www.ietf.org/ID-nits.html. it's a list of common "nits" that have been known to stop documents in the IESG 😭. in fact, you should probably read it well before you're finished, so you don't have to make a bunch of last-minute changes 🍓.
6.3.2 Filenames and Other Matters 🗂️
when you're ready to turn in your Internet Draft, send it to the Internet Drafts editor at internet-drafts@ietf.org 💌. there's a real person on the other end of that address, and their job is to make sure you've included the minimum items you need for the Internet Draft to be published 🫶. when you submit the first version of the draft, the draft editor supplies the filename for it 📁. if the draft is an official Working Group product, the name starts with "draft-ietf-", then the designation of the WG, then a descriptive word or two, then "00.txt" 🌷.
for example, a draft in the S/MIME WG about creating keys might be named draft-ietf-smime-keying-00.txt 🔐. if it's NOT the product of a Working Group, the name starts with "draft-" and the last name of one of the authors, then a descriptive word or two, then "00.txt" 🦋. for example, a draft that someone named Smith wrote might be named draft-smith-keying-00.txt ✨. if an individual submission relates to a particular working group, the author sometimes adds the name of that working group after their own name, like draft-smith-smime-keying-00.txt 💜. you're welcome to suggest names 💅, but it's up to the Internet Drafts editor (and, if it's an official WG draft, the WG chair) to come up with the filename 👑.
after the first edition of a draft, the number in the filename gets incremented 🔢. for instance, the second edition of the S/MIME draft named above would be draft-ietf-smime-keying-01.txt 🌈. note that there are cases where the filename changes after the first version, such as when a personal effort gets pulled into a Working Group 🫧.
6.4 Standards-Track RFCs 🚀
the procedure for creating and advancing a standard is described in BCP 9 📖. after an Internet Draft has been sufficiently discussed and there's rough consensus that what it says would be a useful standard, it gets presented to the IESG for consideration 🧐. if the draft is an official WG draft, the WG chair sends it to the appropriate Area Director after it has gone through Working Group last call 📬. if the draft is an individual submission, the draft's author or editor submits it to the appropriate Area Director 💌. BCP 9 also describes the appeals process for people who feel that a Working Group chair, an AD, or the IESG made the wrong decision about creating or advancing a standard ⚖️.
after it's submitted to the IESG, the IESG announces an IETF-wide last call 📣. this helps get the attention of people who weren't following the draft's progress, and it can sometimes cause further changes to the draft 🔄. it's also a time when people in the WG who feel they weren't heard can make their comments to everyone 🗣️. the IETF last call is two weeks for drafts coming 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 appropriate WG chair) can ask for it to become a Draft Standard 🌟. before that happens, though, someone needs to convince the appropriate Area Director that there are at least two independent, interoperable implementations of each part of the standard 🤝. this is a good test of the usefulness of the standard as a whole, and an excellent way to check whether the standard was actually readable 📖✨.
a few things typically happen at this point 👀. first, it's common to find that some specifications in the standard need rewording, because one implementor thought they meant one thing while another implementor thought they meant something else 😵💫. another common thing is that none of the implementations actually tried to implement a few of the features of the standard. those features get removed not just because nobody tested them, but also because they weren't needed 💀.
don't be surprised if a particular standard doesn't progress from Proposed to Draft 🫠. in fact, most of the standards in common use are Proposed Standards and never move forward. this may be because nobody took the time to try to get them to Draft, or because some of the normative references in the standard are still at Proposed Standard, or it may be that everyone found more important things to do 😭.
a few years after a document has been a Draft Standard, it can become an Internet Standard, also known as a "full standard" 👑. this doesn't happen often, and it's usually reserved for protocols that are absolutely required for the Internet to function 🌐. the IESG goes over the document with a fine-tooth comb before making a Draft Standard an Internet Standard 🔍💖.
6.4.1 Telling It Like It Is -- Using MUST and SHOULD and MAY ✨
okay so writing a spec that people implement the way you actually meant is lowkey an art 🎨. if you keep it super short with just a list of requirements, implementors tend to take way too much leeway 🙈. if you make it super wordy with a bunch 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 devs more likely to build implementations that actually work together (interoperable, bestie 🫶) is being crystal clear about what's being mandated in a spec. 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 basically agreed to limit their wording to a few specific words with a few specific meanings 💅.
RFC 1123, "Requirements for Internet Hosts -- Application and Support," way back in 1989 🦖, had a short list of words that had appeared to be useful, namely "must", "should", and "may". BCP 14, "Key words for use in RFCs to Indicate Requirement Levels," updated and refined those definitions, and it's still widely referenced in current Internet standards 🌸. BCP 14 also specifically defines "must not" and "should not", and lists a few synonyms for the words it defines ✨.
in a standard, if you want it clear that you're using the definitions from BCP 14, you should do two things 📚. first, refer to BCP 14 (most people call it RFC 2119 bc that's what BCP 14 tells you to do lol 🙈) so the reader knows how you're defining your words. second, you should point out which instances of the words you're using come from BCP 14. the accepted move is to capitalize them, which is literally why you see "MUST" and "SHOULD" capitalized in IETF standards 💜.
BCP 14 is a short doc and should be read by everyone reading or writing IETF standards 📖🫶. the definitions of "must" and "must not" are pretty clear, but the definitions of "should" and "should not" spark SO much debate in WGs 😭. when someone reviews an Internet Draft, the question pops up all the time: "should that sentence have a MUST or a SHOULD in it?" 🤔 and honestly it's a really good question, bc specs shouldn't have gratuitous MUSTs, but they also should not have SHOULDs where a MUST is needed for interoperability 🔥. this is the crux of over-specifying vs under-specifying requirements in standards, periodt 💅.
6.4.2 Normative References in Standards
one part of writing IETF standards that trips up tons of newbies (and plenty of long-time IETF folks too 💀) is the rule for making "normative references" to non-IETF docs or to other RFCs in a standard 📎. a normative reference points to a document that must be followed in order to implement the standard. a non-normative reference is helpful to an implementor but not needed 🌷. like we said above, a "MUST" specification is definitely normative, so any reference needed to implement the "MUST" is normative too. a "SHOULD" or "MAY" specification isn't necessarily normative, but it could be, depending on what's being required 🤷♀️. there's definitely room for debate here 🫠!
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 Standard or Internet Standard is super stable, even the stuff referenced outside the standard 🔒. the tradeoff? it can delay publication of the Draft or Internet Standard by many months (sometimes even years!) while the other docs 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 though 💸) and that was made by a generally recognized standards group 🏛️. if the external standard changes, you have to reference the particular instantiation of it in your spec, like by putting in the date of the standard 📅. some external standards bodies don't keep old standards around, which is a real problem for IETF standards that need to be used in the future 😬. when in doubt, 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 🫶.
6.4.3 IANA Considerations
more and more IETF standards require the registration of all sorts of protocol parameters, like named options in the protocol 🗂️. as we noted in Section 1.2.4, IANA has long been the main registry for all IETF standards 🏠. because the registries standards need are so large and diverse, IANA needs specific info about how to register parameters, what not to register, who (if anyone) will decide what gets registered, and so on 📋.
anyone writing an Internet standard that may need an IANA registry needs to read BCP 26, "Guidelines for Writing an IANA Considerations Section in RFCs," which describes how RFC authors should properly ask for IANA to start or take over a registry 📖. IANA also maintains registries that were started long before BCP 26 was produced 🕰️.
6.4.4 Security Considerations
okay this one is SERIOUS bestie 🚨🔐. one thing that's required in every RFC is 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 it 💀. specifically, don't write "here's our protocol, if you want security, just use IPSEC" 🙅♀️. that just won't do at all, bc it doesn't answer 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 Working Group chair, no shame 🫶.
6.4.5 Patents in IETF Standards
the problems of intellectual property have cropped up more and more often in the past few years, especially with patents ⚖️. the goal of the IETF is to have its standards widely used and validated in the marketplace 🛒. if creating a product that uses a standard requires getting a license for a patent, people are less likely to implement the standard 😒. not surprisingly, then, the general rule has been "use good non-patented technology where possible." 🌱
of course, this isn't always possible 🙃. sometimes patents appear after a standard has been established. sometimes there's a patent on something so valuable that there isn't a non-patented equivalent. and sometimes the patent holder is generous and promises to give all implementors of a standard a royalty-free license to the patent, which makes it almost as easy to implement as it would have been if no patent existed 🥹.
the IETF's methods for dealing with patents in standards are a subject of much debate 🍿. you can read about the official rules in BCP 9, but you should assume that the application of those rules is flexible, and that it depends on the type of patent, the patent holder, and the availability of alternate technologies that aren't encumbered by patents 🧩.
patent holders who freely let people implement IETF standards with their patents often get a great deal of good will from the folks in the IETF 💜. such generosity is more common than you might think. for example, RFC 1822 is a license from IBM for one of its security patents, and the security community has responded very favorably to IBM for this (whereas a number of other companies have made themselves pariahs for their intractability on their security patents) 👑.
if you're writing an Internet Draft and you know of a patent that applies to the technology you're writing about, don't list the patent in the document 🙅♀️. instead, send a note to the IETF Secretariat (ietf-secretariat@ietf.org) about the patent or other intellectual property rights. the note will be published on the IETF IPR web page (http://www.ietf.org/ipr.html). IPR isn't mentioned in RFCs because RFCs never change after they're published, but knowledge of IPR can change at any time 🔄. therefore, an IPR list in an RFC could be incomplete and mislead the reader. BCP 9 provides specific text that should be added to RFCs where the author knows of IPR issues 📜.
6.5 Informational and Experimental RFCs ✨
as we noted earlier, not all RFCs are standards. in fact, plenty of important RFCs aren't on the standards track at all 🌈. currently, there are two designations for RFCs that aren't meant to be standards: Informational, like the Tao, and Experimental. (there's actually a third designation, Historical, but that one is reserved for documents that were on the standards track and have been removed due to lack of current use, or that more recent thinking indicates the technology is actually harmful to the Internet 🥀.)
the role of Informational RFCs is often debated in the IETF 🗣️. lots of people like having them, especially for specifications that were created outside the IETF but are referenced by IETF documents 📚. they're also useful for specifications that are precursors to work being done by IETF Working Groups 🛠️. on the other hand, some people refer to Informational RFCs as "standards" even though they're not standards, usually to fool the gullible public about something the person is selling or supporting 🙄. when this happens, the debate about Informational RFCs is renewed 🔁.
Experimental RFCs are for specifications that may be interesting, but for which it's unclear whether there will be much interest in implementing them 🧪. that is, a specification might solve a problem, but if it's not clear that many people think the problem is important, or think they'll bother fixing it with the specification, the specification might be labeled an Experimental RFC 🫧. if, later, the specification becomes popular, it can be re-issued as a standards-track RFC 🚀. Experimental RFCs are also used to get people to experiment with a technology that looks like it might be standards track material, but for which there are still unanswered questions 🔬💖.
7. How to Contribute to the IETF ✨ -- What You Can Do
Okay bestie, here's how YOU can help the Internet be its best self 🫶 Three big moves:
- Read -- Review the Internet Drafts in your area of expertise, and comment on them in the Working Groups. Be friendly and helpful when you join the discussion, because the goal is the best Internet standards possible. Listen way more than you talk 👂💖
- Implement -- Write programs that use the current Internet standards. Standards aren't worth much unless Internet users can actually get them, so implement even the "minor" ones, since they get less minor the more software uses them 🔥 If you find any problems with a standard, report them to the right Working Group so the standard can be clarified in later revisions. One of the oft-quoted IETF tenets is "running code wins," so making more running code is how you help the standards you love spread 💅
- Write -- Edit or co-author Internet Drafts in your area of expertise. Do it for the Internet community, NOT to slap your name (or, even worse, your company's name) on a document 🙈 Draft authors get all kinds of technical (and sometimes personal) criticism, so take it with equanimity and use it to make your draft better, aiming for the best and most interoperable standard 🌸
7.1 What Your Company Can Do
Your company can be a main character too 👑
- 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 it 🛍️
- Open Up -- If your company controls a patent used in an IETF standard, convince them to make it available at no cost to everyone implementing the standard. Patents have caused a lot of serious problems for Internet standards in the past few years, because they stop some companies from freely implementing them 😭 Thankfully, 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 better, urge any company that has benefited from the Internet to become a corporate member of ISOC, since that's the greatest financial benefit for the group. It will, of course, benefit the Internet as a whole too 🌈
8. IETF and the Outside World
8.1 IETF and Other Standards Groups
Okay, as much as many IETF folks would love to think otherwise, the IETF does NOT live in a standards vacuum 🙈 There are many (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 😅 Many other bodies have very different structures, and the IETF is mostly run by volunteers who would honestly prefer to write standards rather than sit in meetings with representatives from other bodies. Even so, some other standards bodies make a great effort to interact well with the IETF despite the obvious cultural differences 🫶
At the time of this writing, the IESG has liaisons with large standards bodies, including the ITU (International Telecommunication Union), the W3C, the Unicode Consortium, the ATM Forum, and ISO-IEC/JTC1 (The Joint Technical Committee of the International Organization for Standardization and International Electrotechnical Commission). The list of IETF liaisons, www.ietf.org/ietf/1iesg-liaisons.txt, shows that there are many different liaisons to ISO-IEC/JTC1 subcommittees 🧚
8.2 Press Coverage of the IETF
Since the IETF is one of the best-known bodies helping move the Internet forward, it's totally natural for the computer press (and even the trade press) to want to cover what it's doing 📰 In recent years, a small number of magazines have assigned reporters and editors to cover the IETF in depth over long periods. These reporters have plenty of scars from articles they got wrong: incorrect statements about the status of Internet Drafts, quotes from people who aren't related to the IETF work, and so on 💀
Major press errors fall into two categories. The first is saying the IETF is considering something when really there's just an Internet Draft in a Working Group. The second is saying the IETF approved something when all that happened was an Informational RFC got published 🙃 In both cases, the press isn't fully to blame, since they're usually tipped off by a company trying to get publicity for a protocol it developed or at least supports. Still, a bit of research would probably get a reporter in touch with someone who could straighten them out, like a WG chair or an Area Director. The official press contact for the IETF is the IETF Secretariat 🎀
The fact that reporters who got it wrong once come back to IETF meetings shows it's possible to get it right eventually 🌸 However, IETF meetings are definitely NOT for reporters who are naive about the IETF process. (Although if you're a reporter and you're reading this document, that's a very good sign!) 💖 And if you think you'll get a hot story from attending an IETF meeting, you're likely to be disappointed 😬
So it's not surprising that some IETFers would prefer the press stay as far away from meetings as possible. A bit of press for protocols that are almost complete and will matter to the industry in the next year can be a good thing. But it's the rare reporter who can resist over-hyping a nascent protocol as the next savior of the Internet 🙄 Stories like that do way more harm than good, both for the readers and for the IETF.
The main reason a reporter might want to attend an IETF 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 spot a press badge. Still, IETF meetings are excellent places to meet and speak with document authors and Working Group chairs, which can be super valuable for reporters covering the progress of protocols ✨
Reporters who want to find out "what the IETF is doing" on a particular topic would be well-advised to talk to more than one person active on that topic, and should probably try to 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 by talking to its author 🔍 The good news is that all WGs have archives a reporter can search for recent signs of a draft's progress. The bad news is that few reporters have the time or inclination to do that kind of research 😭 And because the IETF doesn't have a press liaison, a magazine or newspaper that runs a story with errors won't hear directly from the IETF, so it often won't know what it did wrong, and it might easily do it again later 💅
9. References
9.1 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 conceives the universe as a single organism, with human beings as interdependent parts of a cosmic whole 🌌 Tao is sometimes translated "the way," but according to Taoist philosophy, the true meaning of the word cannot be expressed in words 🦋
9.2 Useful E-mail Addresses
Here's your contact cheat sheet 📬
agenda@ietf.org Requests for agenda slots at IETF
meetings
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-secretariat@ietf.org Questions for the Secretariat
ietf-web@ietf.org Web questions/comments
internet-drafts@ietf.org Internet Draft submissions and queries
minutes@ietf.org Where to send Working Group minutes
proceedings@ietf.org IETF Proceedings Coordinator
iana@iana.org Internet Assigned Numbers Authority
rfc-ed@rfc-editor.org RFC Editor9.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 e-mail addresses, and much more 🌐 Click on "Additional Information" to find a variety of helpful links. Internet Drafts and other documents are also available in the "ietf" directory on anonymous FTP sites worldwide. For a listing of those sites, see:
http://www.ietf.org/shadow.htmlCheck the IESG web pages, http://www.ietf.org/iesg.html, to find up-to-date info about drafts processed, RFCs published, and documents in Last Call, as well as the monthly IETF status reports 📊
9.4 Acronyms and Abbreviations Used in the Tao
And finally, your glossary of alphabet soup 🍓
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
IANA Internet Assigned Numbers Authority
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/
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 Group9.5. Documents Cited in the Tao 📚✨
okay so here's every doc the Tao quietly leans on, bestie 🫶
- BCP 9 "The Internet Standards Process"
- BCP 10 "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees"
- BCP 11 "The Organizations Involved in the IETF Standards Process"
- BCP 14 "Key words for use in RFCs to Indicate Requirement Levels"
- BCP 22 "Guide for Internet Standards Writers"
- BCP 25 "IETF Working Group Guidelines and Procedures"
- BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs"
- RFC 1123 "Requirements for Internet Hosts -- Application and Support"
- RFC 1796 "Not All RFCs are Standards"
- RFC 2223 "Instructions to RFC Authors"
- "Considerations for Internet Drafts,"
http://www.ietf.org/ID-nits.html - "Guidelines to Authors of Internet-Drafts,"
ftp://ftp.ietf.org/ietf/1id-guidelines.txt
Security Considerations 🔐
ngl this part is serious, so listen up 👑
Section 6.4.5 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 information, this document does not touch on Internet security.
Editor's Address 💌
Susan Harris
Merit Network, Inc.
4251 Plymouth Road, Suite 2000
Ann Arbor, MI 48105
EMail: srh@merit.eduSusan Harris is the one who edited this doc, so big thank-yous to her 🦋
Full Copyright Statement ⚖️
Okay, this is the legal bit, so I'm keeping it word for word. Read it, bestie 💜
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement 🙌
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, you're literally keeping the lights on 💖🌈
📦 where this page comes from
- ietf: rfc3160 2001-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms