The Internet Standards Process

The way that technical standards are developed for the Internet might seem arcane from the outside looking in, but this process is eminently logical, and it has served the Internet well for years. This process is documented in the IETF's RFC 2026, which is also currently the Internet's BCP #9. This document can be accessed at www.ietf.org/rfc/rfc2026.txt.

If the terms RFC and BCP are alien to you, read on. The remainder of this chapter is devoted to helping you understand the inner workings of this vital function. The roles of Internet drafts, RFCs, STDs (standards), and BCPs are all explored and explained.

Internet Draft

Virtually every standard published by the IETF starts out as an Internet draft or I-D or just plain draft in IETF parlance. A draft can be submitted by an individual or can be the product of a working group.

The draft itself conforms to the template used for all RFCs, which only adds to the terminology confusion. Because the RFCs are public documents, virtually anyone in the world can review them and make comments to the author(s) for consideration. If appropriate, the document might be superseded by a modified version, or it might die a quiet death if it fails to resonate within the Internet community. If it does find some support, the document can either become embraced as a de facto standard or undergo the more rigorous standardization process. The remainder of this chapter examines all the document types that the IETF recognizes. Then we'll look at the inner workings of that organization's consensus-based standards adoption mechanisms.

RFCs

The most commonly encountered IETF-produced document is the RFCs. These documents aren't necessarily just requests for comments. In fact, many of them contain the specifications for protocols and technologies that are embraced as standards or built as products. In other words, many RFCs have progressed well beyond the development stage where comments are being solicited. Thus, the full name is actually a misnomer. For this reason, RFCs of all types are almost always referred to as simply RFCs.

NOTE

Although the arcane nature and nomenclature of RFCs might be discouraging, rest assured that some of these documents are quite useful. E-mail, as ubiquitous an application as you could hope to find, was first described in RFC 821. Similarly, DNS originated in a pair of RFCs numbered 1034 and 1035. So, you see, they can be quite useful.

There are six different types of RFCs. Each goes through a slightly different process during its journey toward ratification:

• Proposed standards

• Draft standards

• Internet standards

• Experimental protocols

• Informational documents

• Historic standards

Of these six, only the first three qualify as standards within the IETF. Thus, it is imperative to understand that RFCs are not created equal. Some are solid enough to have products designed around them, and others are not intended for use other than to solicit comments or test for interest in an emerging technology. For a much more complete summary of the differences between the various types of RFCs, refer to RFC 1796, "Not all RFCs are Standards." You can find it at www.ietf.org/rfc/rfc1796.txt

Just to prove that things can get even more complicated, there are also three subseries of documents within the RFC architecturestandards (STDs), Best Current Practices (BCPs), and For Your Information (FYI) documents. Each is described in the following sections.

Internet Standards

There are three types standardsthe Proposed Standard, the Draft Standard, and the Internet Standard. RFCs that are placed on the standards track first become Proposed Standards. After six months in this status, such RFCs might undergo additional scrutiny and be sanctioned as Draft Standards. Even more scrutiny is required for a Draft Standard to be ratified as an Internet Standard. Internet Standards are often known as Full Standards, but there aren't very many of them. In fact, most standards-track documents never move beyond Proposed Standard. That doesn't mean they aren't useful. In fact, many protocols and products are built around Proposed Standards. The explanation for a standard's inability to move to Draft and then Full Standard might simply be a resource issue: Only so many people can make meaningful contributions. Engineers who develop a Proposed Standard might simply find themselves drawn into other initiatives before they can advance a Proposed Standard any further. Please don't misconstrue that as laziness or anything of the sort. Advancing Proposed Standards is complex, time-consuming work. In fact, it can take several years of work before a Draft Standard can become a Full Standard. The amount of effort required to make this happen limits the number of RFCs that become Full Standards to just those few protocols that are absolutely essential for the Internet to function.

We will examine the IETF's approval process for moving an RFC on the standards track through the various standard stages in a moment.

BCPs

A subset of the RFC series is known as the Internet's Best Current Practices (BCPs). This subset differs from the technical specifications often found in RFCs. BCPs specify operating procedures that are consensually agreed to be the best for the Internet. Alternatively, a BCP can be used to describe how to apply the various technologies described in other IETF documents. Some of the examples of BCPs presented in this chapter should give you a good idea of the type of content that can be found in a BCP.

FYIs

The FYI subseries of documents was created to present information such as big-picture overviews of highly technical topics. Such overviews provide a context within which much more specific RFCs add detail. Other uses of the FYI documents are to introduce a topic or otherwise present information that is perceived to have broad appeal. Working groups within the IETF's User Services Area usually produce this type of document.

Approval Process

The process by which a proposal progresses through the IETF on its way to ratification can be time-consuming and arduous, but it follows a fairly distinct pattern. A proposal is first floated as an Internet draft. Comments are received, and the draft is edited accordingly. This can be an iterative process, as opposed to achieving completion in a single pass. If an individual created the draft, that person might request that an area director take the document to the IESG for review and consideration. If a working group created the document, the chairperson of that group takes it (after achieving consensus in the group, of course) to the area director for forwarding to the IESG. Either way, the IESG must review it in the larger context of existing standards and future desired technology directions. If any changes are deemed necessary by the IESG, the draft goes back to its creator(s) for further work. When there is consensus among the document's creators, area director, and IESG, the draft can be published as an RFC.

It is important to note that additional layers of checks and balances exist in the approval process. For example, if two or more area directors object to an Internet draft, it is blocked from becoming an RFC, and it can't become a standard. This veto power ensures that a technology doesn't get ratified that will have unacceptable impacts on other technologies. This is critical to ensure the ongoing stability of the Internet's open protocols and technologies.

Another check-and-balance mechanism is the "last call." After a draft is submitted to the IESG, an IETF-wide announcement is made to ensure that nothing can escape anyone's notice. In this manner, comments may be solicited from people and/or groups who weren't following a particular draft's development. Such groups include the ISOC, IRTF, IAB, and even other area directors or working groups. Any and all of these parties have the opportunity to submit comments, concerns, and questions to the working group responsible for the document.

After all parties have had a chance to examine the draft (and its implications), the IESG might decide to sanction the draft as an Internet Standard. If that is the case, the draft still has some hurdles to overcome. The IESG requests that the editor of the RFCs (a formal position within the IETF) publish the draft as a Proposed Standard. It has status as a numbered RFC, but it is also explicitly identified as a Proposed Standard. After six months, the author(s) of that RFC can ask their area director to approve it as a draft standard. This is a high hurdle to overcome. The technology must be proven by at least two independent implementations that demonstrate not only interoperability but also validation of the concept's benefits.

As mentioned earlier, it is highly likely that a proposed standard will never make it to full Internet Standard status and yet will still achieve broad acceptance in the market. This can be one of the more confusing aspects of the IETF's standards-setting process. But if an RFC makes it all the way to Full Standard, you can rest assured it has been thoroughly examined and tested. Of course, this is not a guarantee that all products will work perfectly. It just means that the various companies that implement the RFC start with a stable base but are free to interpret it according to their needs. The next section explains this phenomenon and some of its unintended consequences.

NOTE

There is a persistent and pervasive misperception among Internet users that RFCs are the laws of the Internet. In some cases, such as RFCs that are BCPs or STDs, that might be a good analogy. But in the vast majority of cases, RFCs are little more than ideas floated publicly to solicit comments. No one is obligated to comply with an RFC, nor is there any penalty for noncompliance.