In our deeper investigations of the IETF as a “sample standards body” in this (apparently forever running) series on how the Internet really works, let’s take a look at the IETF standards process. This is a rather sanitized, informal review — I may leave out some steps, or describe things in a way that doesn’t match precisely with the official documents, which can be found here. I’m working more from experience than from the formal process documents.
The entire draft process begins with a new idea — this can be for a new protocol, a change to an existing protocol, some new data structure used for network management, or whatever else is needed to support some area of IETF protocols, security, or other work. One of the more interesting problems is determining what the scope of work is for the IETF — or any other standards body. So let’s work through an example to see how this really works, rather than talking in abstract terms. We’ll use something pretty simple — RFC3021.
Individual Submission: The first step is the initial publication of the draft. Normally a lot of back end work is put into “socializing” a draft before the first publication, including determing who should be on the list of authors, who should be considered contributors, which vendors will support implementation, which working group is going to be the target, adjacent areas that need to be considered, etc. Sometimes an actual implementation is pushed out before this first draft, just in order to make certain it works, to refine the idea, etc.
In the case of RFC3021, the IPv4 address space crunch was on, and a lot of customers with large hub and spoke deployments supporting retail, medical, and other office types were running up against their IP address space allocation. At the same time, unnumbered links often weren’t an option for various network management reasons, and translation out of private address faced other issues — or even, in some cases, large networks (both enterprise and service provider) were running out of private address space to use, and didn’t want to deploy public address space within their networks.
At the point of original submission, the draft authors often have some idea of whether they intend for this draft to finally be a standard, an experimental idea (for further development into potential standards in the future), or an informational (just a note to the community about how something can/should be implemented, deployed, used, etc.).
Presentation: Normally, once a draft is submitted by a group of individuals, it is then presented to one or more “target” or “adjacent” working groups. This is mostly a matter of just explaining the draft and advertising its existence. What’s wanted here is to get as many eyes on the draft as possible.
Discussion: The draft is normally discussed on public mailing lists for some period of time, to give folks the chance to offer changes or suggestions, or just to flat out shoot it down.
Working Group Adoption: After some period of time, if there is some perceived consensus within the working group that has been determined to “own” the draft, the working group chairs will call for working group adoption. If there is apparent consensus (often denoted within the physical meeting by a hum, but always backed up with a poll on the public working group mailing list), the draft is accepted as a working group document. This always means re-issuing the draft as a working group item with a new name. Where the original draft would contain the author’s name(s) in the draft name (draft-retana-31bit, for instance), the new draft will contain the working group name (draft-rtgwg-31bit, for instance). This point often confuses people, because the name not only changes, but the version number restarts at -00.
Continued Discussion: The document may be presented several more times, and discussed over a period of years on the working group list. The length of time required depends on the number of objections offered, the nature of the objections offered, any alternate drafts proposed, and any merging between drafts that must take place. This is a common place for drafts to die. During this time, the “draft target” — whether the draft is to be a standard, experimental, or informational — may change.
Last Call: After some period of time, the working group chair(s) will call for a “last call” for any comments on the draft. This is normally after the document has undergone a long period of discussion, and several implementations are either in existence, or are under development, so that there is some experience with the protocol or changes. This last call is the last step the working group takes before putting the draft forward as a published RFC.
IESG/IAB Consideration: Once the working group has put the draft forward for publication, a “shepherding AD” (area director), who makes certain the draft passes through the correct process to make it from draft to published RFC status. Included here is the draft passing through a telechat, where it is discussed by the entire IESG (simply the collection of all the currently serving ADs), and each IESG member entering either a “no objection,” “approve,” “object,” or “discuss” on the document. The discuss is the most interesting — this allows an AD to ask for specific changes or to enter specific objections to the draft before it moves into RFC state.
Auth48: Once the draft has passed through the IESG and been approved, it moves into auth48, which means it is now (in theory) 48 hours before being published as an RFC. A notification is posted to the IETF mailing list and all the relevant working group mailing lists, to collect any last minute editorial concepts, minor technical changes, etc. It’s generally assumed (sometimes wrongly) that the draft has been completely vetted before reaching this point, so major technical changes must be thoroughly supported and backed up with strong arguments to be considered at this point.
Publication: Finally, the draft is assigned an RFC number and placed in the public repository.
Starting in my next post, I’ll spend some time going “behind” the formal process, and looking at where things get hung up in the real world — or where they can go wrong.