Previous Table of Contents Next


The IAB is a technical advisory group of the Internet Society. Its responsibilities include:


Exhibit 1.  Internet Engineering Task Force Organization.

  IESG Selection: The IAB appoints a new IETF Chair and all other IESG candidates, from a list provided by the IETF Nominating Committee.
  Architectural Oversight: The IAB provides oversight of the architecture for the protocols and procedures used by the Internet.
  Standards Process Oversight and Appeal: The IAB provides oversight of the process used to create Internet Standards. It also serves as an appeal board for complaints of improper execution of the standards process.
  RFC Series and IANA: The IAB is responsible for editorial management and publication of the Request for Comments (RFC) document series and for administration of the various Internet assigned numbers.
  External Liaison: The IAB acts as a representative of the interests of the Internet Society in liaison relationships with other organizations concerned with standards and other technical and organizational issues relevant to the worldwide Internet.
  Advice to ISOC: The IAB acts as a source of advice and guidance to the Board of Trustees and Officers of the Internet Society concerning technical, architectural, procedural, and, where appropriate, policy matters pertaining to the Internet and its enabling technologies.

INTERNET ENGINEERING TASK FORCE STRUCTURE AND INTERNET STANDARDS PROCESS

The IETF provides a central focus for technical aspects of the Internet. The work is undertaken by a number of functional areas, as seen in Exhibit 2, within the IETF that have general responsibilities and the areas are comprised of individual working groups (WGs) with specific tasks.


Exhibit 2.  Internet Engineering Steering Group, IETF Areas, and Security Area Working Groups.

The WGs form the backbone of the IETF. Each WG is formed with a relatively narrow focus, rather than looking at large problems. In addition, the WGs usually start with or quickly define a limited number of options by which to achieve their goals. When formed, each WG defines a charter with a specific set of goals and milestones. Each WG also maintains an Internet electronic mail discussion list and an online archive.

The working groups conduct business during IETF plenary meetings, meetings outside of the IETF, and through electronic mail. The IETF holds week-long plenary sessions three times a year. These meetings include working group sessions, technical presentations, network status reports, working group reports, and an open IESG meeting. Proceedings of each IETF plenary are published, which include reports from each area, each working group, and each technical presentation as well as a summary of all current standardization activities. Meeting reports, working group charters and mailing list information, and general information on current IETF activities are available online through anonymous file transfer protocol (FTP) and the World Wide Web (WWW).

Unlike most other “standards” groups, the plenary sessions and proceedings are not the only place where important work is accomplished and documented. Most final decisions are made through E-mail or, at the very least, are circulated by E-mail. One reason for this apparent looseness is that WG meetings and discussions are open to anyone within the Internet community (which includes just about everyone) with something to contribute.

In another departure from other standards groups, the IETF WGs do not require unanimity before progressing with work. Furthermore, only proven and working protocols become standards. One of the guiding forces of the Working Groups is the IETF Credo, attributed to David Clark:

We reject kings, presidents, and voting.
We believe in rough consensus and running code.

The effect of this principle is that there is no formal voting within the WGs. Instead, disputes are resolved by discussion and demonstrations of working models. These discussions take place at the plenaries and on the discussion lists.

The result of the WG activities is the publication of various Internet documents. The IETF publishes two types of documentation:

  Internet-Drafts. An Internet-Draft (ID) is a working document, and is referred to as a “work in progress.” IDs have no official status and expire after six months; they are not archived beyond their expiration date. The IETF Secretariat distributes the announcement for new Internet-Drafts.
  Request for Comments. Requests for Comments (RFCs) are the literature of the Internet. In particular, they are the series of documents that provide an historical record of the IAB. RFCs are edited, assigned a number, and announced by the RFC Editor. The four categories of RFC are:
Historic, which refers to an RFC that is important for historic purposes, but is unlikely to become (or remain) an Internet standard either due to lack of interest or because it has been superseded by later work. Examples include the Common Management Information Services over TCP/IP (CMOT) specification (RFC 1189) and the Border Gateway Protocol version 3 (BGP-3; RFCs 1267 and 1268).
Experimental, referring to an RFC that describes experimental work related to the Internet that is not a part of an operational service offering. Examples are the Stream Protocol Version 2 (ST2; RFC 1819)and Unsolicited Address Resolution Protocol (UNARP) (RFC 1868).
Informational, which refers to RFCs that provide general, historical, and tutorial information for the Internet community; these are usually produced by a standards organization or other group or individual outside of the IESG. Examples are the Novell IPX Over Various WAN Media (IPXWAN) specification (RFC 1634) and A Primer on Internet and TCP/IP Tools (RFC 1739).
Standards Track, referring to RFCs that are intended to become Internet standards.

The Standards Track RFCs contains three classes:

1.  A Proposed Standard is a complete, credible specification that has a demonstrated utility for use on the Internet. A Proposed Standard has an expiration date from between six months and two years of the publication date, by which time it must be elevated to a higher status, updated, or withdrawn.
2.  A Draft Standard is written only after there have been several independent, interoperable implementations of a specification. Draft Standards usually reflect some limited operational experience, but indicate enough knowledge that the specification seems to work well. A Draft Standard has an expiration date from between four months and two years of the publication date, by which time it must be moved to a different status, updated, or withdrawn. Examples are the HyperText Markup Language (HTML) version 2 (RFC 1866) and Relative Uniform Resource Locators (URLs; RFC 1808).
3.  An Internet Standard is “the real thing” and refers to specifications with demonstrated operational stability; examples are IP (RFC 791; also known as STD 5) and TCP (RFC 793; also known as STD 7). An RFC can stay as a Standard forever or may be reclassified as Historic.


Previous Table of Contents Next

Copyright © CRC Press LLC