The Internet Engineering Task Force turned 25 yesterday. In that quarter century, 79 meetings were held in 15 countries and 4,500 RFCs (requests for comment) were written, resulting in 70 Internet Standards and 155 current best practices. Many more protocols are proposed standards and are often widely used, but haven't made it to standard status—yet. This includes HTTP, for instance.

The IETF grew out of a group for government contractors working on the ARPANET who got together a few times a year to discuss what needed to be done to improve the network. In the intervening 25 years, it turned into a standards organization that creates standards related to the technical operation of the Internet.

However, the IETF is quite a bit different from traditional standards organizations such as ANSI, ISO, or the IEEE Standards Association. Standards organizations typically have high thresholds for membership—in some cases, you can only join the club if you're a country—and only make their standards available for a (high) fee. Not so with the IETF: "There is no membership in the IETF. Anyone may register for and attend any meeting. The closest thing there is to being an IETF member is being on the IETF or Working Group mailing lists."

This comes directly from The Tao of IETF, which is the best introduction into this strange and wonderful world—short of attending a meeting in person. If you don't have that kind of time, two quotes provide a pretty good feel of how the IETF sees itself: "We reject kings, presidents, and voting. We believe in rough consensus and running code" (David Clark). And: "Be conservative in what you send and liberal in what you accept" (Jon Postel).

The Tao mentions the humble beginnings of the IETF:

The first IETF meeting was held in January 1986 at Linkabit in San Diego, with 21 attendees. The 4th IETF, held at SRI in Menlo Park in October 1986, was the first that nongovernment vendors attended. The concept of Working Groups was introduced at the 5th IETF meeting at the NASA Ames Research Center in California in February 1987. The 7th IETF, held at MITRE in McLean, Virginia, in July 1987, was the first meeting with more than 100 attendees.

These days, about 1,200 people typically attend an IETF meeting. Ten years ago, this was nearly 2,500. New working groups are created regularly, and old ones are killed off almost as often. The real IETF work happens on the working group mailing lists, to which anyone can subscribe.

Meeting in person at an IETF meeting can be very valuable—I remember hammering out the last elusive detail of the REAP protocol in the hallways of the Palais des Congrès in Montréal—but it's not a requirement. Successful participation is possible through e-mail only—which is free. The IETF is financed through donations by the Internet Society and through the meeting registration fee.

The first IETF meeting that I attended was number 55 in Atlanta, in 2002. (I remember that in the security line when changing planes at Dulles, as we were taking our shoes off, I joked that "next year we'll be standing here in our underwear" to my fellow travelers. That doesn't seem so funny now.) In those days, the meetings started with a simple breakfast at eight, and then the first working group session at nine. The last session finished at ten in the evening, with 1.5-hour breaks for lunch and dinner—not ideal if you're jetlagged. These days, we stop at 7:30 and then go for dinner.

At all times, people are sitting wherever they can find a flat surface—and a power outlet—to work on their laptops or have a discussion. The story goes that at the Minneapolis Hilton, where the IETF has had six of its meetings, someone asked a hotel employee "where's the IETF?" The bewildered employee answered: "they're everywhere!"

About those RFCs

RFC 1 was published in 1969; some 1,500 RFCs predate the formation of the IETF. Although requested comments are always welcome, the letters RFC shouldn't be taken too literally. The RFC series is simply a series of publications, which are—of course—freely (both meanings of the word) available online. Interestingly, in four decades, the format of RFCs hasn't changed: it's still plain ASCII made up for 80-column teletype output. (Whether this is still a good format these days is a topic of heated discussion on the main IETF discussion list every two years or so.)

All RFCs start their life as Internet-Drafts. IDs are generally updated a few times (to more than dozen times) before they're handed over to the RFC Editor for publication. But many more drafts circulate for a while and are then abandoned.

There are four types of RFCs: informational, experimental, standards track, and historic. Informational RFCs can be any text deemed useful for the community. This can be opinions, results of experiments, or even jokes. Experimental RFCs describe a protocol that isn't considered ready for prime time. Often, some IETF participants feel there is a serious problem with the protocol. Experimental RFCs do not have the IETF's seal of approval.

Standards-track RFCs, on the other hand, do. Protocols are first published as Proposed Standards. If there are multiple implementations and they work well together, the status of the RFC can be upgraded to Draft Standard. In practice, however, many protocols (or at least their specifications) are slightly updated, so a new RFC, replacing the old one, is published. Finally, when there is a good deal of (successful) experience with the protocol, it can be elevated to Internet Standard.

At any point, even when it's an official standard, a protocol can be relegated to "historic" status because it's no longer relevant.

The IETF inherited IPv4 and many other core specifications from what came before it (mainly the ARPANET), but IPv6 was created entirely through the IETF process, which is often laborious. But if there is industry consensus, the IETF is capable of doing great things. Because there is no official membership, there's not much point in voting, so IETF decisions are reached through "rough consensus." That means that a very large majority has to agree on the proposed way forward. This is a high bar to clear, but requiring close to a consensus does have the advantage that if something can pass through the IETF process, there is a very good chance that it will also be viable in the outside world.

The downside is that a vocal minority can make progress grind to a halt. Like all other participants, the leaders of the IETF, collectively known as the Internet Engineering Steering Group (IESG), are all volunteers. The only staff is the secretariat, which provides support.

We'll leave you with an observation from Brian Carpenter, formerly of IBM and now a computer science professor. He's been attending IETF meetings since number 25 in 1992, and has served as working group chair, IAB chair, and IETF chair, and says that he still learns a lot of new stuff at every meeting.

"Vendors and operators look to the IETF to reach a clear decision," he said during a 1993 meeting in Amsterdam. "The market will resist any IPng that does not just look like a new release of IP."

And they are still resisting. As I visited his homepage at the University of Auckland, a JavaScript popup informed me that I have dual stack IPv4 and IPv6 Internet connectivity, and no action is required.