What you should know about the Internet Standards process. - Page 4
Turning I-Ds into Standards
You can't tell the players without a scorecard, and there are a number of different players in the Internet standards game. Before you can truly understand how the process works, it helps to know who is involved.
It might be nice if there were a nice, orderly org chart that laid out the different entities involved in the standards process. On the other hand, the standards process is an organic, human one that sometimes, over the years, adapts to market or political forces. The figure gives an idea of the entities involved.
- Internet Society (ISOC)
- ISOC is the umbrella organization to all Internet standard activity. Positioned as the professional organization for the Internet and TCP/IP networking, ISOC sponsors conferences, newsletters, and other activities pertaining to the Internet.
- Internet Architecture Board (IAB)
- The IAB was first formed in 1983, when it was known as the Internet Activities Board, and then reconstituted as a component of ISOC, the Internet Architecture Board, in 1992. Its early history is documented in RFC 1160 and its current charter in RFC 1601. The IAB chooses the steering groups' members and provides oversight to the Internet standards process, publishes RFCs and assigns Internet-related numbers.
- Internet Engineering Task Force (IETF)
- Though often portrayed as a very formal entity, the IETF consists of anyone who shows up (either in person or by mailing list) and participates in IETF activities. IETF activities are organized by areas (active IETF areas are listed at the IETF website), and within each area are more focused working groups. Each area has one or two area directors, and each working group has one or two chairs as well as an area advisor; these individuals guide the work of the groups.
- Internet Engineering Steering Group (IESG)
- The IESG consists of the IETF area directors and the IETF chair, and this is the body that has final say over whether a specification or protocol becomes a standard or not.
- Internet Corporation for Assigned Names and Numbers (ICANN)
- ICANN is the controversial new entity with shaky finances that was formed last year to take over the functions of the RFC Editor and the Internet Assigned Numbers Authority (IANA). Both those functions had previously been carried out by the late Jon Postel, whose untimely death highlighted the need for a new structure to handle the publication of RFCs as well as maintaining lists of protocol and address numbers that have been assigned or reserved for all the different mechanisms, specifications, and protocols defined by the IETF.
The Internet Research Task Force (IRTF) and Internet Research Steering Group (IRSG) fulfill similar functions for long-term planning and research, but the IRTF is not generally an open organization as the IETF is, and these two entities have less immediate impact on Internet issues, so they generally perform their functions in the background.
RFC 2026, "The Internet Standards Process - Revision 3," documents the process by which the Internet community standardizes processes and protocols. On its face, the process is simple: a group or individual submits their draft for publication as an Internet-Draft. This is the first step. At this point, the document is publicly posted on the Internet and a notification of its publication is posted to the IETF-announce mailing list (IETF mailing lists are archived at the IETF website). Most I-Ds don't progress beyond this point.
Assuming that there is enough interest in the draft to generate discussion, the authors may be called upon to incorporate edits. Once there is consensus among those who are working on the draft (usually work is done in working groups, much of the work taking place in the context of the working group mailing list), a "Last Call" will be issued for further comments on the draft. Any further comments may be incorporated into the draft after the Last Call period (usually some number of weeks), at which point the draft can be submitted to the IESG for approval and publication as an RFC.
Of course, the draft may be published as an experimental or informational RFC; but if it makes it onto the standards track, it starts out as Proposed Standard. Over time, the specification may advance along the standards track (depending on whether it is accepted by the community and implemented, how well it works, and whether or not something better comes along).
A standards track specification may need to go through a revision process as it progresses. Thus, the same specification may be rewritten several times over a period of years before it becomes an Internet standard. There are only about 50 full Internet standards; most of the protocols that we take for granted as being "standards," including HTTP, DHCP, MIME, and many others, are actually either Proposed Standards or Draft Standards. Lynn Wheeler maintains a web page that lists all current RFCs along with their status. It is an interesting and instructive list.
Few people really understand the distinctions between different types of Internet standard (and non-standard) documents-not so much because the concepts are so complicated but rather because they are relatively obscure. And networking vendors often misrepresent standards activities when they announce them. Armed with the information in this article, you can easily determine whether the latest and greatest protocol just released by Novell, Microsoft, or Cisco is actually a new Internet standard or just documented in yet another Internet-Draft.