The Internet Standardization process

Harald Tveit Alvestrand

Harald.T.Alvestrand@uninett.no

Presentation given at the COST A3 workshop in Trondheim, Nov 22-24 1995

Its WWW home is http://domen.uninett.no/~hta/speeches/costa3/tale.html.

Introduction

This talk will give some details about how the standardization functions on the Internet work. It will focus mostly on the formal standardization process represented by the Internet Engineering Task Force - IETF - and its governing bodies.

The Internet Engineering Task Force

Internet standards are created through the Internet Engineering Task Force, IETF.

This is an open forum; membership in the IETF is defined by the fact that you have joined one or more of its electronic mailing lists, which are, by law and strong custom, open to all comers.
Therefore, the actual number of IETF members is an uncountable entity; there can be up to 1000 people at an IETF meeting (which is held 3 times a year), but the total membership is probably in the single thousands.

The target for the IETF process is to make standards that are:

Useful for Internet users
Openly available to all who need them
Tested in software and hardware BEFORE being standardized (and if we don't get it right the first time, we change it).

The result of this activity has been a set of widespread, effective standards that are the basis for the current explosive growth of the Internet.

What is being standardized?

IETF standardizes what is needed for the Internet.

Traditionally, this has included:

transfer of bits on the wire (if we couldn't find an existing one to include by reference)
transfer of the Internet protocols over other protocols
transfer of useful things (like E-mail) over the Internet.

Traditionally, the IETF has had strong abhorrence for standardizing application program interfaces, programming languages and anything where correct operation could not be verified in practice.
The reason for Internet standardization is that the participants want the Internet to work. There's a reasonably strong underlying faith: If a standard is needed to make the Internet work, the Internet community should describe that standard, and make it freely available on the Internet.

The standardization process

The rough outline of the Internet standardization process is:

Someone has a bright idea (or sees a REAL big problem coming up)
A group of people gather (either at an IETF meeting, which makes it a "BOF", elsewhere, or just "on the Net) to refine the problem description, solicit document editors and group chairs, and collect useful input.
The group proposes to the Internet Engineering Steering Group (IESG) and the Internet Architecture Board (IAB) that a formal WG be formed.
Within a few months, the WG is supposed to produce one or more documents describing the object they want to standardize. These are published as "Internet Drafts". It may also produce working code to prove the concept.
The IESG may then approve the documents as "proposed standard", after which they are published as RFCs.

Once this is done, there follows a process of implementation, testing and standard revision; if no really hard problems are found, and several independent implementations are developed, the standard may be promoted to "Draft Standard" and "Full Standard" after a certain period.

Lots of suggestions never make it that far; examples of other outcomes of this process are:

Experimental standards; we tried, but didn't agree, so we're trying it out first.
Informational documents: These are "good to know", but not really standards. These include the "Tao of the IETF", which is the most useful introductory document, and the traditional "April 1" RFCs.
Documents stuck at Proposed or Draft; these indicate either a loss of interest in the standardization work or problems being encountered for which no solution is found yet.
Historical documents: These documents are no longer useful, because a better standard has been developed, or the experiment failed.

Differences with traditional standardization

The membership forms the real basis for the differences. People in the IETF are just that: people. In theory, a student voicing a technically valid concern about a protocol will deserve the same careful consideration, or more, as a man from a multibillion-dollar company worrying about the impact on his installed base.

Other differences are also important, but I believe they flow from this core fact. Examples are:

The standards makers expect to use what they standardize in their own environment, or in their own products.
The standards, drafts and discussion lists are openly available. How could they not be, when everyone can join?
There is a strong tradition of balance between implementation and specification. That's not unnatural, when one considers that the standards writers expect to use their own stuff.
There is NO voting in a working group. How else could we defend the IETF against "ballot stuffing" by powerful parties?

The big lack of the IETF is that it always lacks manpower. Since all effort is voluntary (apart from the IETF secretariat and the IANA, who form a core of stability), and IETF work is demanding, the turnover rate is high, and lots of things are delayed because people have to do their "day work".

Other standards efforts

Other traditional sources for standards are:

National and international standards organizations (ISO, ITU, ANSI, DIN, ECMA)
Industry consortia (SGML Open, ATM Forum, OSF, WWW Consortium, X Consortium)
Industrial companies (Microsoft, IBM, DEC...)

In the Internet arena, the international organizations have seemed to be turned into irrelevance by the speed of the Internet's evolution.

Some industry consortia succeed very well; some isolate themselves by being only populated by a certain sector (the Open Software Foundation is totally dominated by hardware vendors, I believe); some are hammers looking for things that look like nails.

Most of them have a hard time dealing with the IETF, because it is so different from the way they are used to working; none of them has significant name recognition as a standards setting body on the Internet.

Single companies have failed to set standards in networking; it seems that people don't trust them to have fair and open standards.

Who governs the IETF?

The governing bodies of the IETF, the IESG and the IAB, are unpaid volunteers who are selected by a nominations comitte and approved by the "higher organization" (IAB for the IESG, Internet Society board of trustees for the IAB).
The members are chosen for a 2-year term, with the usual overlap of membership; half get replaced every year.

The nomination comittee is chosen by lot among volunteers; the only requirement on volunteers is that they should have been attendees at at least 2 IETF meetings.

So far (twice!), the governing bodies have never failed to follow the advice of the nomination comittee.

There have been examples in recent years (the most famous one being the "Kobe declaration") where the "governing" bodies actually tried to decide something on which the IETF community did not think that there was appropriate consensus; the result of Kobe was a total rearrangement of the procedures for picking leaders, the replacement of a lot of the leaders, and the overturning of the decision.
The "rank and file" are still there.

Now, what does that tell you about who governs the IETF?

Who governs the Net?

Longtime IETF adherents will insist that the question isn't only hard to answer, it is inherently meaningless.

The only reason the Net appears governed is because most people recognize that there has to be agreement in order to achieve communication, and at the moment, we don't have any better way to do it than the IETF.

Examples of the IETF process

The NOTARY group

Problem:

Email error reports look messy. Programs can't make sense of them.
Some people want to know that a message has arrived, not just that it got lost.

Group formation:

Discussion on other lists (ietf-822ext, which was the original MIME list, and others)
Discussion at IETF meetings
Selection: Greg Vaurdeuil and Keith Moore entered separate proposals and were chosen editors; Ned Freed and Harald Alvestrand were selected chairs
Approval: Did not have a problem "as long as you stay out of the emotionally laden "receipt notification" mess"

Group work:

Planned for 1/2 year (jan 94 to july 94)
Took longer (finished real work in April 1995)
6 months extra to get a few fixes into the text

Implementation:

MTA functionality in sendmail 8.7.1 and other products
UA functionality will be released during 1996

Lessons to be learned:

Everything takes longer and costs more
Fixing the last remaining mistakes take MUCH longer than it should
Implementations don't wait for the last nits, but VERY much prefer the documents to be published (=stable)

The last days of the MIME-MHS group

The MIME-MHS group specified the first proposed standards for how to map between Internet mail with MIME and X.400, trying to move the gateway standards out of the "text only" environment.

At the last meeting, a great debate ensued about how to carry information that did not fit within the message format in X.400.
One party held that it should be formatted into a special "directory" body part, while the other party held that it should, as far as possible, be carried with the body part.

In the end, the second solution won. I believe that the critical reason for that was not its technical merits, but the fact that this solution had been written up in advance, and the proponent of the other solution had not had time to do this. This would also mean that adopting the other solution would delay the process, something that was distasteful for many of the actors present.

In the marketplace, the second solution has not received an enthusiastic reception; several gateway vendors offer it as an option on their systems, but the users seem to turn it OFF by default.

Summary

The IETF process works.

Its chief characteristic is its extreme openness.

Its output is not distinguished by its innovative design or elegant solution, but by the fact that it works.