Many different people were involved in the development of the TCP/IP protocol suite. This presented a need to facilitate the sharing of ideas. A process did evolve that enabled everyone to comment on the proposed definitions of the different standards. Basically, someone would draft a standard and the document would be published for review. This became the Request for Comments (RFC) process. Anyone could, and can, contribute to the RFC process. As you review documentation about the TCP/IP protocol in Windows NT, you will see references to the many RFCs that the product supports.
On its way to becoming a standard, a protocol passes through different stages. The protocol starts as a Proposed Standard. It may be promoted to a Draft Standard, and finally to a full-fledged Standard. At each stage, the protocol faces review, debate, implementation, and testing. Proposed Standards, for example, go through at least six months of review before they may be promoted to a Draft Standard. In general, promoting a standard requires two independent implementations of the protocol. Obviously this process would break down if no one actually monitored it and made decisions when required. The body that takes care of this for the TCP/IP protocol (and therefore also for the Internet) is the Internet Activities Board (IAB). Estab- lished in 1983, it is best described as “an independent committee of researchers and professionals with a technical interest in the health and evolution of the Internet system.” The IAB coordinates design, engineering, and management of the Internet. The IAB has two task forces: the Internet Engineering Task Force (IETF) and the Internet Research Task Force (IRTF).
Two organizations work with the IAB: the Federal Networking Council and the Internet Society. The Federal Networking Council represents all agencies of the United States federal government involved with the Internet. The Internet Society is a public organization that takes its membership from the entire Internet community. Both organizations provide input on Internet policy and standards.
The IETF is responsible for specifying the Internet protocols and architecture. By its own description, the IETF is not a traditional standards organization, although many specifications produced become standards. The IETF is made up of volunteers who meet three times a year to fulfill the IETF mandate. The IETF has no membership. Anyone may register for and attend meetings.
As figure 1.1 shows, the work of the IETF is organized into various areas that change over time.
Figure 1.1
Organizations involved with the Internet.
The directors for the technical areas comprise the Internet Engineering Steering Group, which is responsible for recommending protocol standards. The current IETF areas are as follows:
◆ Applications ◆ Internet ◆ IP Next Generation ◆ Network Management ◆ Operational Requirements ◆ Routing
◆ Security
◆ Transport
◆ User Services
The IRTF is the research organization of the IAB. Membership of the IETF and the IRTF overlap considerably to promote technology transfer.
A memo titled “Internet Official Protocol Standards” describes the standards for protocols to be used on the Internet. It also includes a thorough discussion of the standards process, which has been simplified considerably in this discussion. The memo is updated quarterly and is RFC 2000 as of this writing.
It is important to note that not all RFCs are standards. Many RFCs, for example, have been posted to provide industry input to the process of updating the IP standard. Although not all RFCs are standards, all Internet standards are defined in RFCs and are assigned a standard number.
All documents are assigned RFC numbers for tracking purposes. After a document has been assigned an RFC number and is published, it can never be revised by using the same RFC number. Any published revisions are assigned a new RFC number. If a new RFC replaces an older RFC, the obsolete RFC is identified on the title page. Also, the old RFC is labeled as obsolete and classified as historical. The concern, therefore, is not having the latest version of a particular RFC, because only one version of a given RFC ever exists. The concern is having the current RFC for a given standard. (In the second edition of this book, for example, the Internet Official Protocol Standards RFC was number 1920; it is now 2000.)
Internet protocols can have several designations, depending on their state in the standards process. The designation describes the status of the protocol that the RFC describes. The main designations are as follows:
◆ Proposed Standard. Protocols under consideration for standardization in
the future.
◆ Draft Standard. Protocols in the final stages of study prior to approval as a standard.
◆ Standard. An official standard protocol for the Internet.
◆ Experimental. Protocols undergoing experimentation but not on the stan- dards track.
◆ Historical. Protocols that have been superseded or are otherwise no longer under consideration for standardization.
◆ Informational. Protocols that interest the Internet community but have not been through the IAB standards review process.
As well as a designation, the requirement level for the protocol is defined in each RFC. This requirement level describes the intended use of the RFC. The main requirement levels are as follows:
◆ Required. Must be implemented by all systems connected to the Internet.
◆ Recommended. Should be implemented.
◆ Elective. May be implemented if desired.
◆ Limited. May be useful in some systems. Experimental, specialized, and historic protocols might receive this classification.
◆ Not Recommended. Historical, specialized, or experimental protocols not
recommended for use on the Internet.
In recent years, new technologies have appeared rapidly on the Internet. A case in point is the World Wide Web, which depends on the HyperText Transfer Protocol (HTTP). The web and HTTP were in wide use long before RFC 1945 established an Internet standard for HTTP version 1.0. Increasingly, evolution of the Internet is being led by network heavy hitters such as Microsoft and Netscape. The slow stan- dards process fails to satisfy vendors who want to establish themselves as leaders on the Net.
If you want to obtain information about a particular protocol, you should obtain the RFCs that contain its definition. Obviously the best way to get an RFC is to find it on the Internet. You can easily obtain all the RFCs as well as FYIs and FAQs by visiting the Internic site. Internic is essentially the IAB site on the Internet, and is found at: www.internic.net
An FYI is a For Your Information document that attempts to condense the information from one or more RFCs into something a larger group of people can digest. FYIs are a subset of RFCs and can be found at the Internic site. FAQs are the
Frequently Asked Questions. These are found on many sites. These documents
normally describe (in general terms) the purpose of a site, protocol, newsgroup, and so on. FAQs are written to answer the most often asked questions.