So … you have an idea you think would fit perfectly into the realm of the Internet Engineering Task Force (IETF)—but where do you start? In this blog series, I demystify the process of moving from your idea to some sort of Request for Comment (RFC). Throughout the series I’ll discuss the IETF itself, and look at each step of the process, including:
- Submission
- Getting the Draft Accepted
- Working Group Last Call
- Area Review
- IETF Last Call
- Final Reviews
- Editing
- Publishing
Throughout this series, I’ll intermix the “official process” with thoughts on how things work in practice.
In this post, I provide background on the IETF, some comments on its culture, and some guidance on the Submission process.
IETF Background
The IETF was formed in 1986 from an informal group of collaborators to manage and maintain the standards around the Internet Protocol. Since then the IETF has become one of the major standards bodies in the technology industry. Despite its prominence, the IETF maintains the informal structure of its founding. There is no official membership. You simply join a mailing list (or more than one mailing list), read drafts, propose drafts, attend meetings, and so on. You—yes you—can join right now!
It’s interesting to watch folks who come to their first IETF meeting and realize there’s no formal hierarchy. You can walk up to anyone, talk to anyone, and go to the mic during a presentation and speak your mind. Representatives of various governments who attend IETF meetings at the invitation of the Internet Society are often surprised by the free exchange of ideas (and sarcastic barbs, in many cases) at the microphone. There are few other places where you can see the folks who invented many of the technologies holding the Internet together wandering around the halls and discussing what to do for dinner.
This open atmosphere often leads folks to argue the IETF is, or should be, a “meritocracy.” The best ideas should gain traction, be adopted, and eventually be deployed. However, the IETF is still made up of people, all of whom have egos, goals, and families to support. Like all other humans, the humans in the IETF tend to form “tribes” with unclear, often unspoken, and constantly changing lines of trust.
The “best people” don’t always “rise to the top” (even if you could figure out what “best” and “top” mean). Good ideas don’t (or the best idea doesn’t) always win.
In an organization that prides itself on the concepts of “running code” and “rough consensus,” this means a lot of time is spent building coalitions and leveraging relationships. This often translates to long periods elapsing between an idea and its corresponding solution.
With the culture and nature of the IETF in mind, let’s start with the first phase—submission.
Submission
The process of submitting a new document to the IETF is—in theory—quite simple. Head over to the IETF Datatracker and find the draft submission tool (here). Upload your file, fill in all the fields, and hit the submit button.
Just because it’s simple in theory doesn’t mean it’s simple in practice.
Tools
First, there are those pesky file formats. There are four options: plain text, markdown, Adobe’s Portable Document Format (PDF), and eXtensible Markup Language (XML).
Which one should you use?
The IETF accepts plain-text documents, provided they are formatted correctly. Most IETF document authors have found maintaining plain-text documents to the IETF’s expectations can be quite difficult—so most plain-text submissions are conversions from either XML or markup.
The IETF also accepts documents in two dialects of markdown, which many people prefer because they believe they can write more quickly in markdown. I have consistently refused to learn markup; the return-on-investment (especially because there are so many dialects) doesn’t seem to be high enough for me to spend precious time learning yet another way to build documents.
The IETF accepts PDF documents, which can sometimes be preferred when there are large, complex diagrams in the draft.
Any documents submitted in plain text, markup, or PDF will ultimately be converted to the broadly preferred XML for indexing and publication.
If you’re familiar with HTML, you’ll find XML easy to work with because XML is essentially a superset of HTML. XML is a markup language, where explicit, inline tags are used to indicate the way a piece of text should be formatted, what the text is, and so on.
Markup is similar in concept, but completely different in implementation. While markup is designed to increase the speed of writing, XML is designed to increase the precision of formatting, and include metadata to improve indexing and searching. Hence building documents in XML might require more time than other methods, but the result will be more uniform, more easily rendered in different formats, and easier to index.
For those who don’t understand markup languages, or prefer to work in a WYSIWYG editor, there are editors that can make your life easier. You can build IETF-compliant documents in Microsoft Word, or in an XML editor like Visual Studio Code (VSC), Notepad++, or even Adobe Dreamweaver. XML editors will auto-close tags, suggest tags, help you find mismatched tags, and help keep indenting and other formatting nits correct.
I tend to use a combination of Visual Studio Code and Notepad++, depending on the level of editing I’m going to be doing. I learned HTML, then XML, many years ago to the level that I can build documents in these two markups in “plain text,” which makes things much easier for IETF requirements.
In my next post on this topic, I’ll start by looking the way IETF drafts need to be formatted—at least those parts that aren’t as obvious as they seem.