Standards Organizations
- Internet Standards and the IETF
- The International Telecommunications Union (ITU)
- The IEEE 802 Standards
From the author of
From the author of
From the author of
This is the first in a monthly series of columns on networking standards. I plan to cover a wide range of topics from physical-layer specifications to distributed applications. To start, it would be good to review some of the key players in the making of networking standards. This month, we look at perhaps the three most important: the IETF, ITU-T, and IEEE 802.
Internet Standards and the IETF
Many of the protocols that make up the TCP/IP protocol suite have been standardized or are in the process of standardization. By universal agreement, an organization known as the Internet Society is responsible for the development and publication of these standards. The Internet Society is a professional membership organization that oversees a number of boards and task forces involved in Internet development and standardization. Three organizations under the Internet Society are responsible for the actual work of standards development and publication:
-
Internet Architecture Board (IAB): Responsible for defining the overall architecture of the Internet, providing guidance and broad direction to the IETF.
-
Internet Engineering Task Force (IETF): The protocol engineering and development arm of the Internet.
-
Internet Engineering Steering Group (IESG): Responsible for technical management of IETF activities and the Internet standards process.
The actual development of new standards and protocols for the Internet is carried out by working groups chartered by the IETF. Membership in a working group is voluntary; any interested party can participate. During the development of a specification, a working group will make a draft version of the document available as an Internet Draft, which is placed in the IETF's "Internet-Drafts" online directory. The document may remain as an Internet Draft for up to six months, and interested parties can review and comment on the draft. During that time, the IESG may approve publication of the draft as an RFC (Request for Comment). If the draft has not progressed to the status of an RFC during the six-month period, it is withdrawn from the directory. The working group may subsequently publish a revised version of the draft.
The IETF is responsible for publishing the RFCs, with approval of the IESG. The RFCs are the working notes of the Internet research and development community. A document in this series may cover essentially any topic related to computer communications and may be anything from a meeting report to the specification of a standard.
The work of the IETF is divided into eight areas, each with an area director and composed of numerous working groups:
-
General: IETF processes and procedures. An example is the process for development of Internet standards.
-
Applications: Internet applications. Examples include Web-related protocols, EDI-Internet integration, LDAP.
-
Internet: Internet infrastructure. Examples include IPv6, PPP extensions.
-
Operations and management: Standards and definitions for network operations. Examples include SNMPv3, remote network monitoring.
-
Routing: Protocols and management for routing information. Examples include multicast routing, OSPF.
-
Security: Security protocols and technologies. Examples include Kerberos, IPSec, X.509, S/MIME, TLS.
-
Transport: Transport layer protocols. Examples include differentiated services, IP telephony, NFS, RSVP.
-
User services: Methods to improve the quality of information available to users of the Internet,. Examples include responsible use of the Internet, user services, FYI documents.
The decision of which RFCs become Internet standards is made by the IESG, on the recommendation of the IETF. To become a standard, a specification must meet the following criteria:
-
Be stable and well understood
-
Be technically competent
-
Have multiple, independent, and interoperable implementations with substantial operational experience
-
Enjoy significant public support
-
Be recognizably useful in some or all parts of the Internet
The key difference between these criteria and those used for international standards from ITU is the emphasis here on operational experience.
The left side of Figure 1 shows the series of steps, called the standards track, that a specification goes through to become a standard; this process is defined in RFC 2026. The steps involve increasing amounts of scrutiny and testing. At each step, the IETF must make a recommendation for advancement of the protocol, and the IESG must ratify it. The process begins when the IESG approves the publication of an Internet Draft document as an RFC with the status of Proposed Standard.
){kind=link}
Internet RFC publication process.
The white boxes in the diagram represent temporary states, which should be occupied for the minimum practical time. However, a document must remain a Proposed Standard for at least six months and a Draft Standard for at least four months to allow time for review and comment. The shaded boxes represent long-term states that may be occupied for years.
For a specification to be advanced to Draft Standard status, there must be at least two independent and interoperable implementations from which adequate operational experience has been obtained.
After significant implementation and operational experience has been obtained, a specification may be elevated to Internet Standard. At this point, the specification is assigned an STD number as well as an RFC number.
Finally, when a protocol becomes obsolete, it's assigned to the Historic state.
All Internet standards fall into one of two categories:
-
Technical specification (TS): A TS defines a protocol, service, procedure, convention, or format. The bulk of the Internet standards are TSs.
-
Applicability statement (AS): An AS specifies how and under what circumstances one or more TSs may be applied to support a particular Internet capability. An AS identifies one or more TSs that are relevant to the capability, and may specify values or ranges for particular parameters associated with a TS or functional subsets of a TS that are relevant for the capability.
There are numerous RFCs that are not destined to become Internet standards. Some RFCs standardize the results of community deliberations about statements of principle or conclusions about what is the best way to perform some operations or IETF process functions. Such RFCs are designated as Best Current Practice (BCP). Approval of BCPs follows essentially the same process as approval of Proposed Standards. Unlike standards-track documents, there is no three-stage process for BCPs; a BCP goes from Internet draft statute to approved BCP in one step.
A protocol or other specification that's not considered ready for standardization may be published as an Experimental RFC. After further work, the specification may be resubmitted. If the specification is generally stable, has resolved known design choices, is believed to be well understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable, the RFC will be designated a Proposed Standard.
Finally, an Informational Specification is published for the general information of the Internet community.