The Evolution of an Internet Standard

The IETF is, in effect, a standards making organization, and, like many other standards making organizations, it has a principle focus on the generation of “standard” specifications of technologies and their intended use. Obviously in the IETF’s case this focus lies with the Internet, and within that increasingly broad scope of activity, the IETF appears to specialize on aspects of the technical infrastructure of the network and the associated aspects of operational management. Of course this brief hand-waving summary of the IETF probably raises more questions than it answers – How are standards produced? How does the IETF decide that a topic is a suitable area for standards-related study? How does the process used by the IETF work? When is the process complete?

One way of answering such questions is to go through a description of the IETF’s Internet Standards Process (RFC 2026)¹. However that’s probably pretty dry material to all but the most dedicated of standards aficionados. The IETF ethos is one that espouses practical sense: “rough consensus and running code” offers a very pragmatic perspective on the standards process. So in the same spirit of taking a practical perspective here, perhaps the best way to describe this process is to follow the path of an individual document as it progresses through the IETF process. I’ll use the document describing the 4-Byte AS number specification, for no other reason than it is a document that the author is relatively familiar with and it appears to have a background that is relatively typical of the IETF process.

Step 1 – Understanding the Need

The IETF does not generate standards upon a whim (or at least not very often!), nor does it do so to meet some annual production quota (or at least that’s not the intention!). Internet Standards produced by the IETF are intended to address a practical need where a standard specification can assist both vendors and consumers of a product or a service to be assured that a standards conformant implementation will undertake certain functions in a known manner, and that, as appropriate, implementations of the standard specification from different vendors will indeed interoperate in intended ways.

The first step in the IETF’s process is one of reaching a reasonable common understanding of the requirements that the work should address. At times the exposition of the requirements is undertaken during the process of formation of an IETF Working Group, and the requirements are aired in the formative Birds of a Feather (BoF) sessions at IETF meetings. At other times the discussion of requirements may happen within an existing Working Group (WG) as part of a proposal to adopt a specific work item into the scope of the WG’s activities. Also at times WGs have been formed solely to produce requirements, with the intention to pass these requirements to other WGs for subsequent activity. And, of course, at other times the requirements are gathered into the IETF from exposition of the topic in other venues. No matter what the path, the essential question that should be answered is “just what problem are we solving here, and why does this problem need to be solved in this venue?”

In the case of the 4-Byte AS Number work there was no IETF-generated requirement specification that was passed to the Inter-Domain Routing WG. This was a case of a need being expressed through other studies and being bought into the IETF. In the late 1990′s a number of studies of the inter-domain routing space indicated that the consumption of AS numbers was exhibiting clear exponential growth trends, and that exhaustion of the existing AS number space could occur by 2005 if those trends were to continue. This was the subject of presentations to the IETF on routing in the late ’90s.

The form of introduction of how to address this problem into the IETF followed a relatively traditional path in the form of an individually submitted Internet-Draft draft-chen-as4bytes submitted by Enke Chen and Yakov Rekhter in September 2001. In reviewing this draft some years later, it is interesting to note that the draft addressed the relatively straightforward specification of an expanded AS number field in the BGP protocol as the result of a capability advertisement. The motivation for the proposal is not considered in the draft, and is a common convention in Internet-Drafts. The document notes a potential problem with transition from the shorter existing AS number space to this larger 32 bit number space, but does not address how such a transition could be supported. It also does not explain in any detail what may happen if the local routing domain is using a 4-Byte AS number when it attempts to initiate an eBGP peer session with a BGP speaker that does not recognise such 4-Byte AS numbers. So what we have here is the genesis of an idea, but one that clearly has to be refined.

Step 2 – WG Admission

The next step in the IETF process is to place the work item into the agenda of a WG. One option is the chartering of a WG to look quite specifically at a particular item of work, and such decisions to charter a dedicated WG are made by the IESG. The IESG decisions to charter WGs are generally based on their assessment of the level of support from the IETF to take on the work, the degree to which the work fits within the chosen scope of the IETF’s activities. Also taken into consideration is an indication of the feasibility of the proposed activity, and the extent to which there are a sufficient number of individuals who are keen to actually do the work. Of course not every work items generates its own WG, and a more common path is to integrate the work into an existing WG. This is conventionally signalled by the adoption of an individually submitted Internet-Draft as a WG document. Adoption of a draft by a WG involves a shift in the status of the document, in the document is now a WG document and revisions to the document should reflect the rough consensus of the WG.

In the case of the 4-Byte AS draft, the document was accepted as a WG document in 2001 by the IDR WG. This was based on the charter of the IDR WG to standardize and promote the use of BGP-4. The transition to a WG document also saw considerable refinement in the document of the transition case, where the local routing domain is using a 4-Byte AS number when it attempts to initiate an eBGP peer session with a BGP speaker that does not recognise such 4-Byte AS numbers. This initial WG draft draft-ietf-idr-as4bytes-00 describes the dual translation and tunnelling techniques that form the core aspect of this work.

Step 3 – WG Refinement

Once a document is adopted by a WG there is an iterative process of document refinement and WG review to successively refine the document to reflect the WG’s considerations. The intended purpose of these open peer review cycles is to ensure that the document is peer reviewed, that it reflects a shared understanding of the space, that the specification is neutral and unbiased, that it is useful to the Internet, that it reflects a rough consensus of being of high quality, and that it is a feasible and practical approach to addressing the topic. When to complete this iterative process is normally signalled by a WG Last Call on the document. The judgement call of whether a WG Last Call has reached a rough consensus of the WG is one of the roles of the chair (or chairs) of the WG.

The 4-Byte AS document was refined as part of the iterative process a number of times. The initial revision (version 1, February 2001) included specific consideration of the transition mechanism where AS Confederations were being used. Version 2 (April 2001) of the draft included an IANA Considerations section relating to the BGP Capability code point assignment, and BGP Type Code assignments for the new structures introduced in this draft, as well as the assignment of an AS number to be used in the transition phase. Version 3 (May 2001) appears to offer some minor grammatical changes to the draft. Version 4 (September 2001) appears to also offer only minor changes to the grammar and appears to be a token holder for the work to ensure that all references to the work are not lost on the 6 month expiration cycle of Internet-Drafts. Versions 5 (May 2002) through to 10 (July 2005) appear at regular 6 month intervals and have no substantive changes at each iteration. WG documents need volunteer input in order to progress, and in some ways the IETF is no different to any other organization with limited resources – the organization tends to focus on the most pressing needs of the day. In this case, once the Internet bust exerted its influence on the industry the consumption rate of AS numbers slowed dramatically, and the predicted point of exhaustion of the existing number pool pushed outward to around 2011 – 2013.

The urgency in defining a solution to this problem dissipated and the work on this document slowed down as a result. Following the circulation of revised expiry projections and the need to undertake considered planning to assist in the transition issue, in mid-2005 the topic was revised with some external impetus of revised projections concerning the exhaustion of the 2-Byte AS Number space and the need to undertake preparatory activities in a planned fashion. Version 11 (September 2005) reflected some grammatical changes to get the document ready of a Working Group Last Call, as well as a more informative Security Considerations section. Following the Working Group Last Call a further revision of the document was published (version 12, November 2005), including some changes to bring the draft to the current levels of Internet-Draft format and content guidelines, with the inclusion of an Introduction section, use of terms as defined in RFC 2119, and the addition of text relating to proxy aggregation conditions in transition, and explicit text to describe the reconstruction of the 4-Byte AS path. The IANA Considerations section was expanded to include the creation of the larger AS Number registry.

On November 12, 2005, the document was passed from the IDR Working Group to the Routing Area Directors, with the request that the document be published as a Proposed Standard.

Step 4 – Implementability and Interoperability

One of the hallmarks of the IETF’s standards process is to stress the importance of useful and practical standard specifications. The conventional manner in which this is assessed is the evaluation of the functionality and interoperability of two or more independent implementations of the specification. Such an assessment is recorded in the production of an implementation report. Reports that have been prepared for the IETF for various standards can be found here. These documents record the implementation of an IETF protocol specification, those parts to the specification that were implemented and any aspects that were not implemented. They also document the outcomes of interoperability tests, and may include an assessment as to what extent the specification is sufficiently well phrased such that implementations that faithfully follow the specification will indeed interoperate correctly with other implementations.

Formally within the IETF Standards Process this requirement of documentation of implementations and their interoperability occurs when a specification moves from Proposed Standard to Draft Standard in the Internet Standards Process. However, a cursory glance at the RFC collection reveals 1,302 Proposed Standards, 119 Draft Standards, and 104 full Standards. The pragmatic observation is that much of industry that uses standard specifications are happy to work off the IETF’s Proposed Standards, and there is generally little motivation to move any document through the next steps of the IETF Standards Process to a Full Standard. This implies that the formal steps of review of implementations and their interoperation is missing for many of the IETF’s protocol specifications [Editors note: The IETF newtrk WG is looking it this issue].

Each Area of the IETF has some discretion as to how it manages its part of the Standards Process, and the Routing Area has determined to address this issue of the extensive use of Proposed Standard as the stopping point for specifications by adopting the procedure that publication of Routing Area Proposed Standard documents should be accompanied by implementation and interoperability reports of the specification.

In the case of the 4-Byte AS work the report was published as an Internet Draft in September 2005 as an individual submission to the internet drafts editor (draft-huston-idr-as4bytes-survey), documenting two implementations of this draft and their interoperation.

Step 5 – Publication

The next step in the process is the handover from the WG to the IESG publication process. The first step is the handing of the document from the WG to the Area Directors as a publication request. This is the current state of the 4-Byte AS draft, which is currently marked as “publication requested”. Normally within a week or two the document will have been reviewed by the Area Directors and placed on the agenda of the next IESG meeting. The role of the IESG is to conduct a review of the document and include in that review an IETF-wide Last Call for publication of the document. It is not unusual for a document to attract some substantial comment at this step. Formally this is the point in time where the document is subjected to a broader review that includes “cross-area” consideration, and it is often the case that the document needs to resolve issues related to their impact on related technologies and their interoperation. It is not unusual for the document to be passed back to the working group for further consideration at this time to resolve these review comments into the document.

At some point the process of iterative review will reach a conclusion. The document is ready for publication, and is handed over to the RFC Editor for copy-editing and markup into a consistent document format . The document is also checked by the IANA, to ensure that any necessary protocol parameter registries are in place. The authors are consulted on any changes made to the document during this copy-editing phase, and then, once the authors’ permissions have been obtained, the document is published as an RFC.

Step 6 – Use and Experience

At the same time others are making use of the specification in their line of activity, producing implementations of the technology or considering how such a technology could be used within their particular environment.

In this case the suppliers of BGP implementations are consumers of the 4-Byte AS specification, as they will inevitably be asked to provide this capability in their product. In addition, the Regional Internet Registries have an interest in this topic, as they will have to undertake a role of supply of these larger AS numbers, and need to coordinate this supply with availability of BGP implementations that will be able to manipulate these larger AS number fields. There are also implications in the area of documentation, training and supporting material that need to reflect the issues associated with the transition into the larger number space.

Some Observations

This production of an Internet Standard is neither a particularly fast, nor a particularly slow process. As needed, the document review process can be relatively fast, and RFC documents have been produced in timeframes of months, rather than the years taken in the example we have followed. On the other hand, when urgency is not a critical consideration, then the process can take on a more deliberative momentum, and, as with the example we’ve followed here, the process may take some years.

Perhaps more worrisome than the issue of timeframes is that we’re continuing to condense the process of review and collapsing much of the role of Proposed Standards in the later stages of the Internet Draft, and Proposed Standard documents are becoming a surrogate form of Full Standard these days. The implications to the IETF’s ethos of running code as an essential criteria for its documents are certainly a valid consideration as a result, as is the consideration of the utility and clarity of the IETF’s documents. But, of course, every organization evolves to meet changing needs and roles, and the IETF is no exception to this. What constitutes an Internet Standard may change over time, and the process for generation of such standards may also change over time, but I for one would hope that we continue to ensure that its not just the process that counts, but that the outputs continue to be useful to the Internet at large.

[Editors Note: For a more detailed description of the 4-byte AS number specification, see the recent issue of IPJ: www.cisco.com/ipj

1.) This document now is 10 years old, and not unsurprisingly certain aspects of this document have been revised due to the changing landscape. The updates to this original specification can be found in RFC 3932, The IESG and RFC Editor Documents: Procedures, RFC3979 Intellectual Property Rights in IETF Technology and RFC3978 IETF Rights in Contributions.