Standards continued

By: Scott Bradner

In the last column I lamented the fact that Internet RFCs and the process that produces them were not seen as capable of producing "real" standards. I also threatened to continue at a later time with a discussion of the RRC process. The time is now, the threat fulfilled..

Last time I claimed that the RFC standards process has the kind of structure that standards lovers seem to want. This was not always the case. The first RFCs were written by the "good old boys" that were implementing TCP/IP at the time. (They weren't quite so old then, but they claimed that they were good none the less.) The RFCs were the way that someone could propagate an idea for a protocol or an application. There was no real review process except for trial by semi-public fire.

(Semi-public since the community was quite small at the time.)

Things are rather different now. The whole Internet standards process is under the auspices of the Internet Society (ISOC). The ISOC was formed within the last two years as a professional society focused on the Internet and its evolution. The Internet Architecture Board (IAB) is an outgrowth of the old Internet Activities Board (also known as the IAB - they did not want to reprint the stationary) and is chartered by the ISOC to provide the oversight for the standards process. In addition the IAB approves of the appointment of the members of the Internet Engineering Steering Group (IESG). The IESG consists of the Area Directors of the Internet Engineering Task Force (IETF), some at-large members and a chair shared with the IETF. (Enough layers for you structure lovers?)

Individual standards are normally produced through the actions of a working group within an IETF Area. (An Area merely being a convenient way to divide up the topics.) After the working group is finished with a draft of the standard it is made available for anonymous ftp at a number of sites around the world for review. After a specified period of review the standard can be proposed to the IESG as a standard. The IESG reviews the draft and any comments and can recommend that the document be processed as a proposed standard. At this point it would get an RFC number. After an additional review period and after at least two inter-operating implementations of the standard have been produced, the document can be considered for elevation to become a full standard. At any of the consideration stages a public call is made for comments on the proposed document. The result of this call is considered when the IESG debates advancing the document along the standards track.

As you might expect, there is also an appeals process if there is someone unhappy with the results of one or another level of consideration.

These standards concern themselves with more than just TCP/IP protocols. Standards exist or are underway for a number of other protocols and even operating procedures. One example of the breadth of topics is IBM's proposal for a standard way to encapsulate SNA in TCP/IP. The very standards process itself is the subject of an RFC. To me, there is easily structure and review enough to preclude wayward drifts in the process and to ensure full review of any proposed standard.

Now, I may be a bit biased in my view. I've been attending IETF meetings for a while. I chaired a working group, am an Area Director in the IESG and a ISOC trustee. (But, sure, I'd air the dirty laundry if there were some. )

As I said last time, there are many standards. RFCs reside among the legitimate standards.

sob@harvard.edu

ps: some of the words in this column are taken from various ISOC, IAB and IETF documents since they write better than I do.

pps: Exercise for the reader: Do you think that, given sufficient resources, that you could design an airport as inefficient as Dullis?