So far in this series we’ve discussed the history of the IETF, some of the tools you might want to use when building an IETF submission, and document formatting. There are other seemingly mystical concepts in the IETF process as well—for instance, what is a “document stream,” and what is a document’s “status?”
Let’s look at these two aspects of IETF drafts.
Stream
While the contents of a document are the “most important thing,” who proposes a document, and what they are trying to get done, make a big difference in how a document is treated in the IETF process. The first of these things—who is proposing the document—is the stream.
There are four places the IETF will accept a draft form, or four possible streams—
- By the Internet Architecture Board (IAB)
- By an individual, and sponsored by an Area Director (AD Sponsored)
- By or through an IETF working group
- By or through an IRTF working group
If you want to get your draft before the IETF, you will need to use one of these four entry points. We will assume you are not part of the IAB, or have not presented something the IAB would like to turn into a document, so we’ll skip the first option.
If you think your document has IETF-wide value, but it does not seem to fit into any existing working group, then you can approach an AD directly. If the AD agrees with you, they can sponsor the document as an individual contribution. While individual submissions were once a common way to get a document in front of the IETF community, they are not common any longer.
Many documents that would have been individual submissions are now routed through area working groups. For instance, if you have a document you would like to present to the IETF routing community, but it does not seem to fit into any of the existing routing working groups, you can normally get a slot to present the document in the Routing Working Group (RTWG). The RTWG is a space for anyone to present just about any routing-related document.
The normal process, then, to present something to the IETF community is through an IETF or IRTF working group.
Status
You’ll also need to select an intended status for your document. While this might seem complex, there are really only three choices: Standards Track, Experimental Track, and Best Common Practices.
Standards track means the document makes changes to the operation of a protocol intended for all implementations. These changes will normally impact the interoperability of two implementations of the protocol, which means they will be visible on-the-wire or basic protocol operation. For instance, a change in the way a routing protocol calculates loop-free paths would be considered standards track in most instances.
One confusing thing about standards track documents is the scope or domain of the intended change. The IETF community is currently engaged in a discussion around protocol changes intended to be used within a limited domain, and those intended to be used on the global (big I) Internet. So long as a single provider, or a small regional set of providers, expect to deploy a given change to a protocol, the change can be declared for use only within a limited domain.
Changes designed to be used in a limited domain will need to meet a lower bar than changes designed to be deployed in the wider Internet in two specific areas—security and state.
For instance, suppose a new kind of tunneling protocol is proposed, allowing the tunnel header to change the way routers process the packet. While this kind of change might be considered dangerous to the global Internet, the community might support its use within a single network. The community might well support the changes, given some simple filter can be applied to prevent these kinds of tunneled packets sourced from one network impacting neighboring networks.
Experimental track means this idea needs to be tested in the real world for a while, and potentially adjusted based on experience, before the community is willing to recommend the change to all protocol implementations. Experimental RFCs are usually designed to be used in a limited domain, and generally make changes in the protocol that impact interoperability between implementations.
Informational RFCs are designed to inform the community about some optimization or change to a protocol that does not impact interoperability. For instance, an optimization in the way the way an IS-IS implementation determines its flooding domain, such as draft-white-distoptflood, could be considered informational. Informational RFCs are also often used to describe common operational procedures.
No one ever submits a draft with the intended state of historical. These are RFCs that were once informational, experimental, or standards, but are no longer recommended for use by the community. RFCs are only moved to historical state when the community believes implementing and deploying the technologies described would be harmful to the Internet.
Finally, Best Common Practices (BCPs), are community recommended guidelines for operating a network or a community defined guideline for interacting with the community. BCPs cover a wide range of topics such as acceptable language on mailing lists to correct ingress packet filtering for service providers.
Some documents might fit into several different tracks. If you’re unsure, you can just choose the intended status you think fits and submit the document—someone in the community will likely send you an email explaining why they think the intended state should be different soon enough. You can also ask someone already in the community for help in figuring out which track is right.
In the next section of this series, we will talk about some mandatory document parts, and some notes on required language.