Appendix A - The Internet Standardization Process
 |  |
Throughout this book, there have been many references to specifications and documents, such as the RFCs and STDs that define the various protocols and data formats in use on the Internet. How these documents get developed is an interesting aspect of the Internet community, and one that needs to be discussed in order to fully understand how the Internet really works.
RFC 2026 gives an overview of the Internet standardization process. It is a mustread for anybody who wants to get a true understanding of the process. This appendix attempts to summarize this document (and others) for those people who are interested only in an overview.
Perhaps the best analogy comes from Ed Krol's book, The Whole Internet User's Guide and Catalog, in which Krol says that the Internet is kind of church. It has a council of elders, every member has an opinion on how things should work, and you can either choose to participate or you can choose not to participate. This is a pretty accurate assessment.
Although the defining element of what the Internet is is the conformance to Internet-based standards and services, it is important to note that the use of these standards is strictly voluntary. There is no Internet Police force that goes around and makes you IP and SMTP, for example. Instead, your usage of these protocols is entirely optional.
However, by not using these standards, you would also be making a choice of being isolated from the rest of the Internet community. Therefore, most people find that using these standards makes more sense than not using them, and as such they remain extremely popular. However, their popularity is also directly related to the usability and functionality that these protocols and service provide. After all, if the protocols didn't work, then they wouldn't be very popular.
Developing a protocol to perform a simple task is easy; anybody can write a simple protocol in just a few minutes by giving it some thought. However, making a protocol that is usable on a wide variety on computing platforms (as is the case with TCP/IP) is significantly harder, and takes a lot more work. You have to develop the protocol within very simple host constraints (taking into consideration old platforms, odd-ball platforms, etc.), and the protocol also has to be generic enough so as not to present implementation challenges for a large number of users. If a protocol is hard to implement or use, then it will not be widely adopted. And after all that, the protocol still has to be functional enough to satisfy the design goals. This can be extremely difficult to do when you're having to deal with systems that will only exchange seven-bit ASCII characters, for example.
This is the task of the developers of the protocols and services used on the Internet. They must develop protocols that are both functional and usable on a wide variety of systems. Also, they have to do this so well that vendors and users alike will actually want to use these protocols for their networking services. Remember that the Internet standards are not mandated by anybody, and that acceptance is only realized when people want to use them.
The Internet Authorities.
There are a variety of interrelated organizations that work to develop, promote, and standardize the protocols and services used on the Internet. The most visible of these organizations is the Internet Engineering Task Force (IETF). In a nutshell, the protocols and services used on the Internet are developed by volunteers, who work within a collaborative development environment sponsored by the IETF.
The IETF has a sister organization called the Internet Engineering Steeing Group (IESG), which is the body that ratifies specifications as standards. All of the voting members of the IESG are also participants within the IETF. In addition, a related organization—called the Internet Architecture Board (IAB)—provides think-tank services on behalf of the IETF, examining the broader technology issues that are affecting the usage and adoption of Internet standards (such as support for international character sets).
As part of this service, the IAB also has a dedicated research organization, called the Internet Research Task Force (IRTF), which delves into particularly thorny and complex issues. The IAB also has two administrative organizations that facilitate the usage of the standards that get developed. These groups are the Internet Assigned Numbers Authority (IANA) and the RFC Editor.
You can find more information on each of these organizations in the following sections.
The Internet Engineering Task Force
The IETF consists of a handful of areas, each of which are focused on particular topics of interest (such as routing or security). Each area is chaired by an Area Director, who is responsible for guiding the development of the protocols and services within the group.
The IETF areas are further broken into working groups that conduct research and development on specific protocols within the relevant area. For example, the Applications Area has working groups on HTTP, SMTP, and other application protocols.
The majority of the work performed by each of the working group is conducted using mailing lists. In addition to the mailing lists, the IETF holds face-to-face meetings three times a year, allowing the working group participants to get together and hash out issues in person. Anyone can subscribe to any of these mailing lists or attend these meetings.
For more information on the IETF, visit their web page at http://www.ietf.org/.
The Internet Engineering Steering Group
Although the IETF is where the protocol development effort takes place, the IESG is the organization that actually moves these protocols along the standards track.
Whenever an IETF working group finishes a proposal, it is submitted to the IESG for consideration. If the IESG thinks the protocol is useful and functional, they vote to advance the work along a standards track until it eventually becomes an Internet standard. Note that the IESG is the body responsible for making things standards or informational&rdquo.; This process is discussed in more detail in The Standards-Track Process later in this chapter.
The IESG membership is made up entirely of the IETF Area Directors, who themselves are nominated by the IETF. In many regards, the IETF and the IESG are inseparable and sometimes indistinguishable.
For more information on the IESG, visit their web page at http://www.ietf.org/iesg/.
The Internet Architecture Board
Perhaps the most critical function that the IAB serves is to provide think-tank services for the Internet in general, dealing with such issues as overal architecture, support for international character sets, and so on. The IAB also acts as a pseudoappellate court for users to go to when they feel that the IESG has made a critical error in the standardization process. The IAB is also responsible for interacting with other standards bodies (such as IEEE, ITU, and ISO).
The IAB consists of thirteen voting members. Twelve of these board positions are filled by a nomination process sponsored by the IETF. The thirteenth position is an ex officio seat provided to the current chair of the IETF. In addition, the chairs of the IANA and the IRTF are also invited to attend all IAB meetings, although they do not have any votes.
For more information on the IAB, visit their web page at http://www.iab.org/.
The Internet Research Task Force
When the IAB encounters a particularly deep or thorny problem that must be researched in depth, it can request the Internet Research Task Force (IRTF) to review the problem and report back with their findings. The work performed by the IRTF does not typically result in any new standards, but instead tends to take the form of suggestions that the IAB follows when a working group is established to create a new protocol or specification.
For more information on the IRTF, visit their web page at http://www.irtf.org/.
The Internet Assigned Numbers Authority
Since many different protocols and data types exist, and since many of these documents use numeric or keyword assignments that must not be duplicated, a registry is required to act as a central clearinghouse for these types of assignments. This is the purpose of the Internet Assigned Number Authority (IANA).
The IANA keeps track of every type of assignment specified in the different RFCs and STDs, including mundane lists such as the protocol identifiers (like 17 for UDP and 6 for TCP) and esoteric lists such as the different MIME media types.
For more information on the IANA, visit their web page at http://www.iana.org/.
The RFC Editor
The RFC Editor is the office that is responsible for publishing RFCs, for assigning them unique identifiers, and for the final editorial review of the documents. This is mostly provided as an administrative service for the benefit of the standards process, and is not a clerical service (the RFC Editor does not fix spelling mistakes, for example).
Although the RFC Editor and IANA are different organizations, they have historically been served by the same person. This precedent has recently changed, however.
For more information on the office of the RFC Editor, visit their web page athttp://www.rfc-editor.org/.
Internet Documents (Drafts, RFCs, and STDs)
The process for developing standards in the Internet community is simple on the surface, but arduous in practice. Not only does it require the robust participation of various contributors, but it must also be able to stand up to the harsh criticism of its detractors. For these reasons, it can easily take several years for an otherwise simple and straightforward protocol to make it all the way through the various stages, finally emerging as an official standard for the Internet community.
RFC 2026 defines an Internet standard as a specification that is stable and wellunderstood, is technically competent, has multiple, independent, and interoperable implementations with substantial operational experience, enjoys significant public support, and is recognizably useful in some or all parts of the Internet&rdquo.; This is a tall order to fill for anybody. Even companies such as Sun and Novell—who have many years of experience in developing network protocols and services—would have a hard time delivering a protocol that stood up to that definition. This is an even taller order when the process is opened to any and all participants, some of whom may have their own agendas.
The process itself can also be somewhat convoluted. Depending on the number of revisions and drafts that a document may go through, the process can either be a straightforward series of clearly delineated steps, or it can turn a simple proposal into a complex schema that becomes something totally different from its original goals.
The Standards-Track Process
When the process works like it's supposed to, the IAB charters the IESG with creating an IETF working group to research and develop a protocol or other specification that addresses a specific problem. The working group hammers out the issues, develops a syntax or structure that addresses the problem, and then publishes a draft proposal.
The draft is then posted to the IETF's servers for peer review , at which time people make whatever comments they have about the proposed solution. If any significant errors are found or if any other major changes need to be made, the draft may be replaced at any time with a new version of the document.
After a waiting period of at least two weeks, a draft can be proposed to the IESG as the final specification. If the IESG accepts the draft, it becomes a Request for Comments (RFC), and is assigned a unique identifier. If the RFC is for an IESGsanctioned standard, then it becomes a Proposed Standard immediately upon its acceptance.
An RFC remains a Proposed Standard until at least two interoperable implementations have been built and demonstrated, and for at least six months following publication as a Proposed Standard. At this point, the RFC may become a Draft Standard if the IESG approves of the change in status.
RFCs must remain as Draft Standards for at least four months, or until a face-to-face IETF meeting has occurred, whichever is longer. The last step for an RFC is to become an official Internet Standard, once the specification has been proven to work widely and reliably.
Changes to the documents.
Over time, the state of the technology may change to such a degree that fundamental alterations must be made to a proposal. Typically, changes that require radical modifications will result in the creation of a new IETF working group, or a rechartering of the existing working group.
Minor changes that do not have a significant impact on the technology are allowed at any time, although typically these changes are made whenever a document moves to the next step in the standards process. For example, a Proposed Standard may require some minor modifications, and those changes could be incorporated into the document when it becomes a Draft Standard.
However, no changes (except for typographical or spelling errors) are allowed to be made to a document when it moves from the Draft Standard stage to the Internet Standard stage.
If the changes made at any of these transition Points are severe, the new document may be required to re-enter the process as a Proposed Standard, effectively requiring that the process be restarted.
Requirement levels
Because there are so many different types of documents published, not all of which are suggested or required, RFC 2026 also defines a set of requirement levels that should be applied to each RFC that gets published. These requirement levels are listed in Table A-1.
| ||||||
| ||||||||||||
STD 1 acts as a clearinghouse for the status of each RFC, and also provides the current requirement level status for each of them. Only standards-track documents will have requirement levels.
Off-Track Documents
Not all of the available RFCs out there are standards-track documents. In fact, many of the RFCs currently floating around are not even on their way to becomeing sanctioned Internet standards in any shape or form. Such a document may be an informational notice provided by a vendor, a historical note or procedure, or an experiment that is simply being documented for everybody to see.
In all of these cases, the RFCs are simply provided as public knowledge, and nobody is required to implement any of them. In some cases, vendors who implement the mechanisms detailed in these documents may actually cause interoperability problems.
Informational RFCs
Sometimes a vendor or consultant will choose to share information with the Internet community, and this information can be published as an Informational RFC.
Informational RFCs may be anything, ranging from the simple to the extraordinarily complex. For example, there are some Informational RFCs that advocate certain technologies or make observations about specific implementations. Conversely, some complex protocols (such as NFS) are also published as Informational RFCs, in the hopes that doing so will lead to a broader adoption of the proprietary service.
Sometimes a protocol that is published as an Informational RFC will be adopted on a widescale level. For example, Gopher (RFC 1436) and Ph (RFC 2378) have both achieved a large number of implementations over the years, although both of these protocols were published as Informational RFCs.
Historical RFCs
Any RFC that gets replaced by another RFC is automatically labelled as Historic.
In addition, it is possible that a new technology will simply make an existing specification obsolete. When this happens, one or more existing specifications may need to be retired. In this case, the existing RFCs and standards will also be marked as Historical RFCs.
Note that historic specifications are kept in the archives for reference purposes. Users should be careful to verify that the document they are reading is not an historical one that has no bearing on the current state of things.
Experimental RFCs
Experimental RFCs are typically the result of ongoing research projects that are experimenting with new technologies or approaches for doing something. These documents are only published for the benefit of public record.
Under no circumstances should a vendor incorporate any Experimental RFCs into a shipping product. Interoperability problems are likely to occur if this warning is ignored.
Best Common Practice (BCP) RFCs
Besides the standards-track and off-track documents, the IETF also publishes some other documents from time to time that are known as Best Common Practice (BCP) documents. These documents are most likely to be informational in nature, offering advice to the reader about how to do something, rather than prescribing a set methodology for doing it. Although these documents are also published as RFCs, they are most often referred to as BCPs. An example of this is RFC 2026—also published as BCP 9—which describes the Internet standardization process that much of this appendix refers to.
For Your Information (FYI) RFCs
Another variant on the informational them is the For Your Information series of RFCs. FYIs are mostly informational in nature, although their intended target reader is the end user who is trying to make heads or tails about the Internet in general. Although these documents are also published as RFCs, they are most often referred to as FYIs. An examples of the FYI series includes RFC 1178—also published as FYI 5—which describes why computers have hostnames.
| | |
EAN: 2147483647
Pages: 17