Conference Report: 2002 USENIX: The IETF, or, Where Do All Those RFCs Come From, Anyway?

Steve Bellovin spoke about the Internet Engineering Task Force (IETF). Bellovin is an entertaining speaker and while dry, the material he covered is interesting. This talk is a great introduction to the IETF, what they do, and how they do it.

The IETF is a standards body but not a legal entity, consisting of individuals (not organizations) and driven by a concensus-based decision model. Anyone who "shows up" — be it at the thrice-annual in-person meetings or on the email lists for the various groups — can join and be a member. The IETF is concerned with Internet protocols and open standards, not LAN-specific (such as Appletalk) or layer-1 or -2 (like copper versus fiber).

The organizational structure is loose. There are many Working Groups, each with a specific focus, within several Areas. Each Area has an Area Director, who collectively form the Internet Engineering Steering Group (IESG). The six permanent areas are Internet (with Working Groups for IPv6, DNS, and ICMP), Transport (TCP, QoS, VoIP, and SCTP), Applications (mail, some web, LDAP), Routing (OSPF, BGP), Operations and Management (SNMP), and Security (IPSec, TLS, S/MIME). There are also two other areas; SubIP is a temporary area for things underneath the IP protocol stack (such as MPLS, IP over wireless, and traffic engineering), and there's a General area for miscellaneous and process-based working groups.

Internet Requests for Comments (RFCs) fall into three tracks: Standard, Informational, and Experimental. Note that this means that not all RFCs are standards. The RFCs in the Informational track are generally for proprietary protocols or April first jokes; those in the Experimental track are results, ideas, or theories.

The RFCs in the Standard track come from the Working Groups in the Areas through a time-consuming complex process. Working Groups are created with an agenda, a problem statement, an email list, some Draft RFCs, and a chair. They typically start out as a BOF session. The Working Group and the IESG make a charter to define the scope, milestones, and deadlines; the Internet Advisory Board (IAB) ensures that the Working Group proposals are architecturally sound. Working Groups are narrowly focused and supposed to die off eventually, once the problem is solved and all milestones achieved. Working Groups meet and work mainly through the email list, though there are three in-person high-bandwidth meetings per year. However, decisions reached in person must be ratified by the mailing list, since not everybody can get to 3 meetings per year. They produce RFCs which go through the Standard track; these need to go through the entire Working Group before being submitted for comment to the entire IETF and then to the IESG. Most RFCs wind up going back to the Working Group at least once from the Area Director or IESG level.

The format of an RFC is well-defined and requires it be published in plain 7-bit ASCII. They're freely redistributable and the IETF reserves the right of change control on all Standard track RFCs.

The big problems the IETF is currently facing are security, internationalization, and congestion control. Security has to be designed into protocols from the start. Internationalization has shown us that 7-bit-only ASCII is bad and doesn't work, especially for those character sets that require more than 7 bits (like Kanji), and UTF-8 is a reasonable compromise. But what about domain names? While not specified as requiring 7-bit ASCII in the specifications, most DNS applications assume a 7-bit character set in the name space. This is a hard problem. Finally, congestion control is a hard problem since the Internet is not the same as a really big LAN.

Back to my conference reports page

Back to my professional organizations page

Back to my work page

Back to my home page