The term ‘standard’ is often used  in relation to Internet technologies but an RFC number doesn’t necessarily equal a standard. Stuart Mark explains why.

The use of standardised technologies is a preference of many network managers and has been a published aim of the Internet community almost since its inception. But this desire for a common approach can often come into direct conflict with a specific functional requirement that may be only available as a proprietary offering.

Vendors realise the importance of standards adoption and conformance and regularly use the names of standards organisations and specifications, especially the ubiquitous RFC, in their literature or marketing presentations. In fact, RFC numbers are banded around like betting odds by everyone in the IT industry from networking technicians to executive consultants; even journalists sometimes mention them!

When, though, can a technology be officially called a standard, what are RFCs and where do they fit into the standards process?

Standards Bodies

There are many standards organisations in existence. Participation in many is voluntary and most consist of members of the Internet, engineering or IT community. The most well known of these are the International Standards Organisation (ISO), responsible for the Open Standards Interconnection (OSI) seven layer model, the IT equivalent of the ten commandments. The Institute of Electrical and Electronics Engineers (IEEE), is an organisation consisting of thirty six technical societies that issue specifications in engineering disciplines as wide ranging as Aerospace and Cybernetics; the Computer society defines the 802 specifications used in LAN implementations such as Ethernet, Spanning Tree and VLANs. The American National Standards Institute (ANSI) works closely with the IEEE in developing WAN and Voice specifications.

The Internet Engineering Task Force (IETF) is one of the most importance organisations for network managers because it is the body responsible for maintaining a standards process for all protocols and technologies used in the Internet today. A vast number of  the functional standards defined by the IETF are also used in many enterprise networks, IP probably being one of the most widely adopted.

The mechanism used by the IETF to publish information on technologies is called the Request For Comments (RFC). This is almost always an ASCII (American Standards Code for Information Interchange) text document, numbered in order of release. The first RFC was published in 1969 and thousands are now available from various sources on the Internet. A separate RFC exists for every technology ever developed, reviewed or standardised by the IETF and many complex topics are covered by multiple RFCs.

It is a common misconception among IT professionals that every RFC describes a standard that has been ratified by the Internetworking community as fully functional and operationally safe. This is far from true.

The RFC plays a key role in the IETF standardisation process, not only as a descriptive vehicle for new and existing standards but also as a tool for tracking the progress of candidate specifications and as a means to define Best Common Practice or to simply provide information on a facet of networking function.

RFCs are defined by Categories. If you have an understanding of the IETF organisation and its standards process, you can use these categories to discover the maturity of any technology, especially useful to prevent yourself becoming an IT guinea-pig.

The Main Players    

Although the IETF is generally associated with the Internet standards process, it really only deals with the technical aspects of Internet technologies. A number of other, closely related organisations are involved in the actual standardisation process or ‘Standards Track’.

The Internet Society (ISOC) is a global body made up of individual and organisational members. The ISOC is ultimately responsible for Internet standards. It is managed by a board of trustees, elected by the organisation’s membership.

The Internet Engineering Steering Group (IESG) is part of the ISOC. It manages the mechanics of the standards track by approving submissions for entry to the track, progressing specifications along the track, defining the rules for advancements and giving final approval for a specification to pass into ‘standard’ status. The IETF is organised into eight technical ‘areas’, Applications, General, Internet, Operations and management, Routing, Security, Transport and User services. Each area contains Working Groups that investigate emerging technologies and is managed by an Area Director. These directors make up the core of the IESG. The overall chair of the IETF is also the chair of the IESG and is selected by yet another organisation, the Internet Architecture Board (IAB), which acts as an overseer to the activities of the IESG and the IETF by also approving members of the IESG and approving new IETF Working Group charters. The IAB also handles complaints concerning misuse of the standards process.

The Standards Process

Membership of the IETF is open to anyone with enough time to devote to its activities. Similarly anyone can propose a new technology for standard consideration. In practice, new candidate technologies generally come to the IETF from commercial developments where a vendor wants to standardise a proprietary solution to gain wider networking community acceptance. Alternatively, a requirement may arise from a technical shortcoming identified by either an organisation or an individual.

In both cases a 'standards action' is initiated by the submission of an Internet Draft RFC. The IESG is responsible for the administrative and editorial control and issue of RFC documents and will ensure that the submission conforms to specific RFC format guidelines. Thus, at the very beginning of the standards track, the RFC is used but it does not document a standard. The 'Internet-Draft' categorisation on the RFC header page confirms this.

The IESG will invite comments on the proposal from the Internet community and make a decision on whether to enter it into the standards track. Acceptance results in the formation of an IETF working group under the most relevant area or transfer of the technology into a suitable, existing working group. The RFC moves to ‘Proposed Standard’ status and will remain there for at least six months. The IETF states that “implementors should treat Proposed Standards as immature specifications” and “deploying implementations of such standards into a disruptive-sensitive environment is not recommended.”

When the specification achieves a level of successful operational experience, to be decided by the IESG, and has been developed on at least two different code bases, the IESG may move it to ‘Draft Standard’ status where it will remain for at least four months. At this point the IETF states that “a Draft Standard is normally considered to be a final specification and changes are likely to be made only to solve specific problems encountered. In most circumstances, it is reasonable for vendors to deploy implementations of Draft Standards into a disruption-sensitive environment.”

When the specification is widely accepted as a mature technology with a wide implementation base, the IESG can move it to ‘Standard’ status. If this happens, it will be assigned an STD number as well as its RFC allocation.

Other RFCs

Some technical specifications are never intended to become standards or are considered to young for entry into the standards track. In these cases, three ‘off-track’ RFCcategories are available.

‘Experimental’ is typically used to document a technology that is part of a research or development program. ‘Informational’ is a general information RFC. It can be published without any consensus from the Internet community. ‘Historic’ is assigned to RFCs that are obsoleted by later revisions of the same technologies.

One further RFC category is ‘Best Common Practice’ (BCP) which is used to define procedures or practices used by the Internet community and standards bodies. For example, the RFC categories and standards track process are described in a BCP RFC2026 and the organisations involved in the process are listed in BCP RFC2028.

RFCs play an invaluable role in networking. They provide a detailed, definitive reference for every standard Internet technology in existence and allow anyone free access to the status of emerging specifications. There are eight categories of RFC of which only four are part of the standards track process and only two, ‘Draft Standard’ and ‘Standard’ can be considered safe technologies. If a particular RFC is ever discussed or used as a reference source, always confirm its status. Beware of ‘Informational’ RFCs; these are numerous and often wrongly cited as standards.

www.ietf.org

www.isoc.org

www.iab.org/iab/

• The Internet is controlled by the IAB

• The IETF and associated bodies define standards specifically for the Internet. Other standards organisations exist for other areas of IT.

• An RFC always belongs to one of eight categories. Only ‘Draft Standard’ and ‘Standard’ are safe.

• An RFC is the definitive reference of how a technology operates.

• Beware ‘Informational’ RFC. Although sometimes very useful, these are NOT standards. 

.