Internet Engineering Task Force

Technical recommendations and standards for the Internet, as well as knowledge exchange among developers, takes place in the Internet Engineering Task Force. For historical reasons, the major technical publications are called Requests for Comment (RFC); the working documents that go into RFCs are called Internet Drafts.

As opposed to other standards bodies, the IETF is consensus based and does not use a rigid computer networking reference model such as the Open Systems Interconnection Reference Model (OSIRM). The decision process is based on consensus and demonstrated implementations, rather than a formal voting process and rigid adherence to architectural rules.

We don't believe in kings, presidents or voting. We believe in rough consensus and running code — Dave Clark

The participants are considered as individuals, although most are employees of interested organizations. Technical work is principally done through electronic mail and freely downloadable documents.

Organization

IETF, whose mission is described in RFC 3935, is supported by the Internet Society, and has a policy-level Internet Architecture Board. In practice, the work is done by individuals, primarily in Working Groups, which are organized into technical Areas. As of June 2008, the Areas are:

1. Applications Area
2. General Area
3. Internet Area
4. Operations and Management Area
5. Real-time Applications and Infrastructure Area
6. Routing Area
7. Security Area
8. Transport Area

There is no charge for individual or Working Group participation, and all relevant documents and drafts can be downloaded without any fee.

Publications can come from individuals, but anything intended for standardization goes from the Working Group to a group of recognized experts called the Internet Engineering Steering Group. See publication process for further details.

Most of the work is done on mailing lists, although there are three in-person meetings per year. In contrast with some other standards organizations, one can be a full participant without ever attending a meeting. The meetings, one of which must be outside North America, are probably more important for getting a sense of one's peers in Working Groups, and sensing broad trends. The meetings are partially self-supporting through registration fees, and there obviously is travel expense to attend.

The "standards" process

"Standards" are in quotes, as there is no body that enforces their use. Compliance comes as a result of technical consensus and market acceptance. One of the reasons that the IETF and its technical specifications has been successful, in comparison to the Open Systems Interconnection Reference Model (OSIRM) work, is that the process is as informal as experience shows that it can be. While individuals are usually sponsored by their employers, consensus is among the IETF membership; there are no "company votes". In fact, there are no votes.

Just as there is no hard requirement to implement particular technical methods, there is no single required architectural reference model. Again, a reason why OSI failed was an insistence on conformity to a model, as well as extensive voting processes, rather than starting with a consensus specification in a technical community, doing initial implementations, sharing the experience with them, and improving the specifications based on experience. Other problem of OSI included that participation was by organization, and there was a significant cost to get the technical specifications, a cost often prohibitive for indivduals and academic institutions.

Proposals

Ideas that are expected to lead to standards still often start as drafts submitted by individuals, usually to a Working Group. The draft refines -- and sometimes is found infeasible -- through discussions and collaborative editing on the Working Group mailing list.

If the Working Group believes the idea is worthy of general use, it creates a proposal for a project to produce a specification or set of specifications, which are approved by the IESG. At that point, a "WG draft" is created, starting from the individual contribution and collaborating on drafts. There usually will be several rounds of incrementally improved drafts in the WG. When the WG reaches consensus, the chair asks for a "Last Call", which is announced on a general IETF mailing list. The WG consensus draft then goes to the IESG for approval, guidance, or rejection.

The publication process

Once the IESG approves a document, there is more to do than pure text editing and putting it in a library. While the documents themselves are in simple text, not HTML, one technical check remains to be made: the Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols. As part of the activity of the RFC Editor, once parameter is assigned for one purpose with a protocol (e.g., "Port 25" is always used to identify the Simple Mail Transfer Protocol (SMTP) running over the Transmission Control Protocol (TCP), no other application layer protocol will be associated with Port 25.

This seemingly minor point is one of the reasons the IETF, and the Internet in general, are successful: rules are set and enforced only when not doing so would cause things to break.