Dec 5 2024
The “simple” 38 step journey to getting an RFC
The Internet is built on the mutual understanding of network protocols and practices, and most of those protocols are defined using Request For Comments (RFC) or Best Common Practices (BCP) documents.
The generally accepted source for modern day RFCs is the Internet Engineering Task Force (IETF), the term RFC has been hijacked by several different companies for their own uses. So, for the case of this blog post going forward I will operate under the assumption that if it does not appear in the IETF datatracker, then it’s not a RFC.
For the last 3.5 years myself and 2 others have been slowly working away at a document that has recently been christened RFC9687, the actual contents of the RFC9687 are up for the next blog post, however I figure that it would be interesting to go over the process that got a bunch of words through the IETF process and a RFC number and status being granted and what happened in those 3.5 years.
In a “simple” diagram
For those looking for the quick and simple graph/steps of what we as co-authors were up to during that time, here is the best graph I can draw
Now obviously probably looks convoluted to you, and that is because it somewhat is.
Introducing…
You want a RFC: The longer story
Welcome to the last 3.5 years of my life, all be it not a huge amount of my last 3.5 years, but a slow burner that tested a lot of my will, patience and sometimes sanity! Here is step by step what I would have wanted to read 3.5 years ago to have a deeper idea on what the process is, so let’s get started!
Preamble
It should go without saying that you should probably have a very good reason to pursue the IETF process, in the case of RFC9687 we had identified a shortcoming in the existing BGP4 protocol that appears to be causing real world harm to the internet routing system, and given that BGP4 is already heavily documented and tweaked/patched by other IETF documents, it made sense for us to address this desired change through the same system.
If you’re looking to invent a new protocol, or trying to do a change that seemingly only impacts your operations, the IETF is probably not the best place to pursue this until you have multiple vendors/implementers that are willing to go along with your proposal.
This doesn’t mean you can’t obtain some level of standardisation for things like TCP/IP port numbers and other protocol numbers, as those are handled by Internet Assigned Numbers Authority (IANA), for example: in a previous blog post I got TCP and UDP port 6924 “assigned” to a project of mine.
The IETF process is not a fast moving one. While our efforts took ~3.5 years, that was likely not helped by the coronavirus pandemic as people were operating outside of the normal environment (working from home, entirely virtual meetups, people just flat out dying, etc), so you should price in that whatever you are working on is going to remain relevant if it had to wait 2 years to get there. Keep in mind if you will even be working on the same subjects if you were to change employment.
Everything starts with a I-D
Much like any painting starts with the first few Strokes, an IETF document proposal starts with a draft, or in IETF lingo, a Internet-Draft (I-D)
The IETF has a standardized format for writing documents in, it’s a slightly odd XML markup language that can get compiled into various forms including the famous (at least to my own eyeballs) fixed width text document style, but PDF and HTML are also valid options too.
The tool that compiles these documents is “xml2rfc”, and you can install it on most systems via a Python package manager, feed it the markup document and it will produce that iconic output:
root@ietf-containment-zone:~# pip3 install xml2rfc
[...]
root@ietf-containment-zone:~# xml2rfc draft.xml --html --text
Created file draft.txt
Created file draft.html
root@ietf-containment-zone:~#
The format for this stuff is kind of cryptic, however you are more than welcome to go and look at the markup that eventually led to the document that I worked on here on GitHub.
Of course for some humor you may also just want to go and repackage some other piece of content in that iconic IETF-eqsue official look. There’s nothing stopping you from say, putting meme subjects and formatting them this way:
Co-authors
Very few documents are produced by a single person, you typically will want to have co-authors on your document. Sometimes it is to indicate cross-platform support and sometimes there are people working on the document who will have expertise in different areas. By the end, there were 3 co-authors on our document, Job Snijders (who was the 1st author), Me, and Yingzhen Qu (who came in later in the process, but helped enormously with understanding in how to “patch” parts of the complicated language around the area we were working on)
Because standards are typically a consensus based affair, if you are looking to standardise something new you might want to have your other implementors play an active role in co-authoring the I-D.
So. Many. Working Groups
Now that you hopefully have assembled a basic draft with (ideally) a co-author you are nearly ready to put the draft into the IETF system. However, you also need to figure out what Working Group (WG) is applicable for your submission.
The IETF mailing lists and peoples time are divided into around 100~ different core subject areas, all united under a set of broad groups. For example, the document we did was done through the idr (Inter-Domain Routing) WG, that is under the broader “Routing” area of the IETF
This is where similar documents to ours had been discussed in the past, making it the obvious place to submit to. You can find a full list of IETF working groups here: https://datatracker.ietf.org/wg/
You technically do not need to know what working group you are dealing with just yet in the process, however it helps to have the right mailing list for upcoming discussions.
Once you have the general plan figured out, you can submit the XML (make sure it actually is error-free on xml2rfc) to the IETF DataTracker here: https://datatracker.ietf.org/submit/
You will want to name your draft something like:
draft-foo-wg-ThingYouAreWorkingOn
foo in this case can be your pick (in our case Job Snijders picked spaghetti), If the document progresses though the system then this foo will change to ietf.
After you upload your draft. You should have a data tracker link.
Now here comes the true fun.
Discussion
One of the core functions of the IETF is basically just a very large mailing list server. Inside of your working group are a bunch of people who are volunteering their time to read and respond to the mailing list posts. Because the IETF is a consensus based system you need to ensure that people do not have active objections to your proposal, and that people generally agree that it is something that time should be spent on.
In theory you don’t have to convince everybody on the mailing list, but it would certainly help if you could.
After you submit your draft to the datatracker, ideally you should then post to the working group mailing list to introduce yourself and draft. Once again, in my case you can see what I did here: https://mailarchive.ietf.org/arch/msg/idr/r6N2LEGzukQLsnaEUCsYh9TNb-k/
In total around 600 emails~ were sent around RFC9687/sendholdtimer on public mailing lists. A lot of them were sent in the initial stages to figure out the kinks in the initial draft.
One thing to consider is that the IETF is an interesting standards body (I’m not actually sure if “standards body” is the right term, but that is what comes to my mind) in that it’s very different to the other large bodies like IEEE/3GPP/GSM/ETSI in that it does not require monterey means to participate. This is a good thing in that all types of people can participate and read the mailing lists (and they can be cited), However this can also be a bad thing, in that the bar to entry in theory is quite low, meaning you might have to deal with people arguing in questionably bad faith, or who don’t have first hand real world experience of the subject.
Overall, I think the risk of the latter is outweighed by the volume of people who can help, but it is something you should be mindful of, I believe in our case almost everyone (even those who I disagreed with) were arguing in good faith.
Working Group adoption
Assuming there is wider consensus on the working group mailing list, you can ask the Working Group to “adopt” the draft. This will go to an informal poll to the wider mailing list and you should expect more email discussion from this point on.
You will also have to confirm if you are aware of any patent filings in progress related to things discussed within the document (The “IPR statement”).
Assuming the wider mailing list approves the adoption call, your draft will become a draft-ieft-... document, and the version counter will reset to 00
During all of this, it may be helpful to talk to people in person (or virtually) at the IETF meetings, they happen relatively often around the world. It’s worth calling out that the in-person IETF meeting tickets are quite pricey and are likely out of reach to hobbyists, but remote/virtual attendance is cheap.
At this point as well you will probably want to have at least one working code implementation of your proposal. Having at least one implementation demonstrates that the proposal is real and not just an idea that may or may not be implemented. Real world code 3rd party implementations also help with checking if the document is understandable by implementers, and help identify problems of vague areas of the draft.
Leaving the Working Group
Assuming everything progresses in a positive direction, eventually a “Last Call” survey will be held. Assuming it passes the document then leaves the general debate on the mailing list (though that does not stop you from involving the wider community still), and the document becomes the concern of the chairs of the working group you are dealing with.
At this point you may also need to formally get the Internet Assigned Numbers Authority (IANA) to assign any magic numbers/constants that the document needs.
Eventually, the chairs will get the appropriate Internet Engineering Steering Group members involved to review your document, ideally all of the members need to respond in some way.
There is no “reject” option in this process, instead there is “Discuss”, typically bundled with genuinely useful feedback. Other options for IESG members is “Yes” (Showing support, I view this as a text version of showing two thumbs up), “No Objection” (Still positive), and “Recurse” (For when weighing in could be inappropriate for some reason)
IETF document end game
Assuming IESG gives it a thumbs up, the document transitions into the RFC Editor Queue, this is the final couple of steps. The document is put into a queue of various other documents awaiting a check over for various parts, The point of this step is to have someone review the documents for the last time for logic/grammar/spelling/formatting errors. After some back and forth (hopefully very little) with these editors, they will put you into AUTH48 status (and you will learn the RFC number it has been assigned). This is it. This is the last chance to stop the process if need be, and you will be asked to approve the document for the last time.
Assuming all approvals happen, the gears inside the IETF will turn and an email will go out on ietf-announce@ietf.org to announce a new RFC being published, bots will post things, archives will be updated, and the planet will continue orbiting the sun.
After thoughts
I wondered at the beginning of this that this was not going to be a very fast process and 3.5 years later, that person was absolutely spot on.
I also find it interesting that the final document turned out to be not that readable to the casual user, this is mostly a side effect of how the document works (being a direct patch on top of the BGP4 RFC of sorts), but it is interesting to know that RFC’s kind of have this distinct and strange language that no one really speaks in, and can hide a whole lot of nuance while also somehow extending really basic concepts into hundreds of words!
I don’t really know how I would fix this, as language and communication is a hard thing and as a native English speaker, I don’t necessarily have the full context that other people do when implementing documents like this. But having also been on the implementing side of RFCs I don’t necessarily find them the easiest documents to grasp, I will more often reach for a Wireshark dissector if available before I go and read the RFC for the protocol I am looking at.
I think it’s been super interesting understanding the system that drives most of the internet standards and I’m not necessarily sure that it’s in its optimal state, however I can look at the alternatives (that being closed standard bodies like the 3GPP/ETSI/etc) and conclude that while the IETF is not flawless it is an actually pretty impressive system that works, it just requires a larger amount of time from everybody involved. The fact that people are willing to put in the time is a testament to how fascinating the internet is, and how important keeping standards between various systems is.
Would I do this again? Maybe. There is at least one other document in the works, but it is currently blocked on other documents needing to exist before progressing. Let’s hope that this one is less chaotic than my first attempt at this!
If you want to stay up to date with the blog you can use the RSS feed or you can follow me on Fediverse @benjojo@benjojo.co.uk
Until next time!