RFC 1120

The Internet Activities Board 🌸

okay bestie, let's get into it 💖 this is RFC 1120 by V. Cerf from NRI, part of the Network Working Group, dated September 1989. It's informational, which means it's a history and description, not a standard 📜. The title block doesn't list anything it obsoletes or updates, so it's just vibes and history 🧚

Status of this Memo 📜

This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. Distribution of this memo is unlimited.

1. Introduction ✨

okay so it all starts in 1968 when the U.S. Defense Advanced Research Projects Agency (DARPA) kicked off an effort to develop a technology we now call packet switching 🛰️ this tech had roots in message switching methods, but it was seriously shaped by low-cost minicomputers and digital telecommunications techniques during the mid-1960's [BARAN 64, ROBERTS 70, HEART 70, ROBERTS 78]. if you want a super useful survey of it, check out [IEEE 78] 🍓

During the early 1970's, DARPA started a bunch of programs exploring packet switching over other media, like mobile radio, satellite and cable [IEEE 78, IEEE 87] 🌈 at the same time, Xerox Palo Alto Research Center (PARC) began experimenting with packet switching on coaxial cable, and that eventually led to Ethernet local area networks [METCALFE 76] iconic behavior fr

Once packet radio and packet satellite technology were successfully implemented, the big question was how to interconnect ARPANET with other types of packet nets 🤔 Cerf and Kahn [CERF 74] proposed a possible solution: an internetwork protocol plus a set of gateways to connect the different networks. That solution got developed further as part of a DARPA-sponsored research program in internetting, and it produced a collection of computer communications protocols built on the original Transmission Control Protocol (TCP) and its lower level counterpart, Internet Protocol (IP). Together with many others developed during the research, these are called the TCP/IP Protocol Suite [LEINER 85, POSTEL 85, CERF 82, CLARK 86, RFC 1100] 💅

In the early stages of the Internet research program, only a few researchers were working on developing and testing versions of the internet protocols. As time went on, the activity grew so much that, in 1979, it became necessary to form an informal committee to guide the technical evolution of the protocol suite 🎀 This group was called the Internet Configuration Control Board (ICCB), and it was established by Dr. Vinton Cerf, who was then the DARPA program manager for the effort. Dr. David C. Clark of the Lab for Computer Science at Massachusetts Institute of Technology was named chairman of this committee.

In January, 1983, the Defense Communications Agency, which was then responsible for operating the ARPANET, declared the TCP/IP protocol suite to be the standard for the ARPANET, and all systems on the network were converted from the earlier Network Control Program (NCP) to TCP/IP 🔥 Later that year, Dr. Barry Leiner, Cerf's successor at DARPA, reorganized the ICCB around a series of task forces looking at different technical aspects of internetting. The reorganized group was named the Internet Activities Board. main character reorg energy 👑

As the Internet expanded, it drew support from U.S. Government organizations including DARPA, the National Science Foundation (NSF), the Department of Energy (DOE) and the National Aeronautics and Space Administration (NASA) 🧚 Key managers in these organizations, the ones responsible for computer networking research and development, formed an informal Federal Research Internet Coordinating Committee (FRICC) to coordinate U.S. Government support for, and development and use of, the Internet system. The FRICC sponsors most of the U.S. research on internetting, including support for the Internet Activities Board and its subsidiary organizations.

At the international level, there's a Coordinating Committee for Intercontinental Research Networks (CCIRN), which includes the U.S. FRICC and its counterparts in North America and Europe 🌍 The CCIRN gives the principal North American and European research networking bodies a forum for cooperative planning.

2. Internet Activities Board 👑

The Internet Activities Board (IAB) is the coordinating committee for Internet design, engineering and management 💜 The Internet is a collection of over a thousand packet switched networks, located principally in the U.S. but also including systems in many other parts of the world, all interlinked and operating using the protocols of the TCP/IP protocol suite. The IAB is an independent committee of researchers and professionals with a technical interest in the health and evolution of the Internet system. Membership changes over time to adjust to the current realities of the participants' research interests, the needs of the Internet system and the concerns of the U.S. Government, university and industrial sponsors of the elements of the Internet.

IAB members are deeply committed to making the Internet function effectively and to evolving it toward a large scale, high speed future ✨ All IAB members are required to have at least one other major role in the Internet community in addition to their IAB membership. New members are appointed by the chairman of the IAB, with the advice and consent of the remaining members. The chairman serves a term of two years.

The IAB focuses on the TCP/IP protocol suite, and on extensions to the Internet system to support multiple protocol suites 🦋

The IAB has two principal subsidiary task forces:

1. Internet Engineering Task Force (IETF)
2. Internet Research Task Force (IRTF)

Each of these Task Forces is led by a chairman and guided by a Steering Group, which reports to the IAB through its chairman. Each task force is organized by the chairman, as required, to carry out its charter. For the most part, a collection of Working Groups carries out the work program of each Task Force 🫶

All decisions of the IAB are made public. The principal vehicle for propagating IAB decisions to the parties interested in the Internet and its TCP/IP protocol suite is the Request for Comment (RFC) note series 📝 The archival RFC series was initiated in 1969 by Dr. Stephen D. Crocker as a means of documenting the development of the original ARPANET protocol suite [RFC 1000]. The editor-in-chief of this series, Dr. Jonathan B. Postel, has maintained the quality of the series and managed its archiving since its inception. A small proportion of the RFCs document Internet standards. Most of them are intended to stimulate comment and discussion. The small number which document standards are especially marked in a "status" section to indicate their special status. An RFC summarizing the status of all standard RFCs is published regularly [RFC 1100].

RFCs describing experimental protocols, along with other submissions whose intent is merely to inform, are typically submitted directly to the RFC Editor. A Standard RFC starts out as a Proposed Standard and may be promoted to Draft Standard and finally Standard after suitable review, comment, implementation, and testing 🌸

Before a Proposed Standard, Draft Standard or Standard RFC is published, it's made available for comment through an on-line Internet-Draft directory 💅 Typically, these Internet-Drafts are working documents of the IAB or of the working groups of the Internet Engineering and Research Task Forces. Internet Drafts are either submitted to the RFC Editor for publication or discarded within three months.

The IAB performs the following functions:

1. Sets Internet Standards,
2. Manages the RFC publication process,
3. Reviews the operation of the IETF and IRTF,
4. Performs strategic planning for the Internet, identifying long-range problems and opportunities,
5. Acts as a technical policy liaison and representative for the Internet community, and
6. Resolves technical issues which cannot be treated within the IETF or IRTF frameworks.

To supplement its work via electronic mail, the IAB meets quarterly to review the condition of the Internet, to review and approve proposed changes or additions to the TCP/IP suite of protocols, to set technical development priorities, to discuss policy matters which may need the attention of the Internet sponsors, and to agree on the addition or retirement of IAB members and on the addition or retirement of task forces reporting to the IAB 🍓 Typically, two of the quarterly meetings are held by video teleconferencing (provided, when possible, through the experimental Internet packet video-conferencing system).

The IAB membership is currently as follows:

            Vinton Cerf          - Chairman
            David Clark          - IRTF Chairman
            Phillip Gross        - IETF Chairman
            Jonathan Postel      - RFC Editor
            Robert Braden        - Executive Director
            Hans-Werner Braun    - Member
            Barry Leiner         - Member
            Daniel Lynch         - Member
            Stephen Kent         - Member

3. The Internet Engineering Task Force ✨

Okay so the Internet has gotten HUGE 🌈 It now spans a bunch of networks that are spread out all over the place, and it's used by academic and research communities, plus a whole lot of other groups with all kinds of interests 🦋 The Internet protocols and system pieces also went from "experimental science project" to "commercial product" 💅 So to help keep the operation, management, and evolution of everything running smoothly, the IAB set up the Internet Engineering Task Force (IETF) 🎀

The IETF is chaired by Mr. Phillip Gross, and it's managed by its Internet Engineering Steering Group (IESG) 👑 The IAB handed the IESG the general job of making the Internet work, and of sorting out all the short- and mid-range protocol and architecture issues needed for the Internet to function effectively 🫶

The IETF's charter includes:

1. Responsibility for specifying the short and mid-term Internet protocols and architecture and recommending standards for IAB approval.
2. Provision of a forum for the exchange of information within the Internet community.
3. Identification of pressing and relevant short- to mid-range operational and technical problem areas and convening of Working Groups to explore solutions.

The IETF is a big open community of network designers, operators, vendors, and researchers who care about the Internet and the Internet protocol suite 💜 It's organized around a set of eight technical areas, and each one is run by a technical area director. Along with the IETF Chairman, the area directors make up the IESG membership. Each area director has primary responsibility for one area of Internet engineering, which means they also handle a subset of the IETF Working Groups. These jobs are of critical importance and difficulty, so area directors are picked not just for their technical expertise but also for their managerial skills and judgment 👑 At present, the eight technical areas and chairs are:

1) Applications          - TBD
2) Host Services         - Craig Partridge
3) Internet Services     - Noel Chiappa
4) Routing               - Robert Hinden
5) Network Management    - David Crocker
6) OSI Coexistence       - Ross Callon and Robert Hagens
7) Operations            - TBD
8) Security              - TBD

The actual work of the IETF happens in subcommittees called Working Groups, and there are currently more than 20 of them 🌸 Working Groups usually have a narrow focus, and they only stick around until a specific task is done (there are exceptions, bestie). The IETF is a major source of proposed protocol standards, which then get final approval from the IAB ✨

The IETF meets quarterly 📅 The IAB Secretariat, over at the Corporation for National Research Initiatives, puts out extensive minutes of the plenary proceedings, plus reports from each of the working groups 💖

---

4. The Internet Research Task Force 🧚

To promote research in networking and the development of new technology, the IAB set up the Internet Research Task Force (IRTF) 🔬

In network protocols, the line between research and engineering isn't always clear, so the IETF and IRTF will sometimes overlap 👀 They literally have a lot of the same members, and that overlap is seen as vital for cross-fertilization and technology transfer 🫶 Generally, the difference between research and engineering comes down to viewpoint and sometimes (but not always) timeframe. The IRTF is more focused on understanding than on products or standard protocols, although specific experimental protocols may need to be developed, implemented and tested in order to gain that understanding 🧪

The IRTF is a community of network researchers, usually with an Internet focus. The IRTF is governed by its Internet Research Steering Group (IRSG). The chairman of the IRTF and IRSG is David Clark. The IRTF is organized into a number of Research Groups (RGs), and the RG chairs are appointed by the chairman of the IRSG. The RG chairs, plus others the IRSG chairman selects, serve on the IRSG 💅

These groups typically have 10 to 20 members, and each one covers a broad area of research and pursues specific topics. Those topics are determined at least partly by the interests of the members and by recommendations of the IAB ✨

The current members of the IRSG are as follows:

David Clark         - Chairman
Robert Braden       - End-to-End Services
Douglas Comer       - Member at Large
Deborah Estrin      - Autonomous Networks
Stephen Kent        - Privacy and Security
Keith Lantz         - User Interfaces
David Mills         - Member at Large

---

5. The Near-term Agenda of the IAB 📋

There are seven main focus areas for the IAB's attention during 1989 - 1990:

1. Operational Stability
2. User Services
3. OSI Coexistence
4. Testbed Facilities
5. Security
6. Getting Big
7. Getting Fast

Operational stability matters a ton to every single user of the Internet 😭 We need better tools for gathering operational data, so faults can be isolated at every level and the performance of the system can be analyzed 🔍 There are loads of chances for operators of the different Internet components to team up [RFC 1109]. Specific known problems should get handled too, like implementation deficiencies in some version of the BIND domain name service resolver software 🛠️ The existing Exterior Gateway Protocol (EGP) can only support limited topologies, so until a more general Inter-Autonomous System routing protocol can be specified, constraints on topological linkages and allowed transit paths should be enforced 🚧 Implementing the Internet would get more flexible if all vendors of internet routers adopted a common internal gateway routing protocol 🌈 A major effort is recommended to get conformance to the Host Requirements RFCs, which are due to be published early in the fourth quarter of calendar 1989 📅

User services are next, and the White Pages (an electronic mailbox directory service) seems the most pressing of all 💌 Efforts should focus on getting these capabilities widely deployed across the Internet by mid-1990. The IAB recommends that existing white pages facilities, and newer ones such as X.500, be filled with up-to-date user information and made accessible to Internet users and to users of other linked systems (e.g., commercial email carriers) 💜 Connecting with commercial electronic mail carriers should be vigorously pursued, along with links to other network research communities in Europe and the rest of the world 🌍

Privacy-enhanced electronic mail software should be developed and deployed faster in 1990, once public domain software implementing the private electronic mail standards is released [RFC 1113, RFC 1114, and RFC 1115] 🔐 Last but not least, support for new or enhanced applications such as computer-based conferencing, multi-media messaging and collaboration support systems should be developed 🎥

The National Network Testbed (NNT) resources planned by the FRICC should be put to work supporting conferencing and collaboration protocol development and application experiments, and supporting multi-vendor router interoperability testing (e.g., interior and exterior routing, network management, multi-protocol routing and forwarding) 🧪🦋

When it comes to growth, architectural attention should focus on scaling the system to hundreds of millions of users and hundreds of thousands of networks 🌏 The naming, addressing, routing and navigation problems that come with that kind of growth should be analyzed. Research should also look at the limits of the existing Internet architecture, including whether the present protocol suite can cope with speeds in the gigabit range and latencies running anywhere from microseconds to seconds in duration ⚡

The Internet should be positioned to support the use of OSI protocols by the end of 1990, or sooner if possible 🌟 Multi-protocol routing and forwarding among diverse vendor routes is one important goal. Introducing X.400 electronic mail services, and interoperating with RFC 822/SMTP [RFC 822, RFC 821, RFC 987, RFC 1026], should also be targeted for 1990 💌 These efforts will need to work alongside the White Pages services mentioned above. The IETF, in particular, should establish liaison with various OSI working groups (e.g., at NIST, RARE, Network Management Forum). The goal is to coordinate planning for OSI introduction into the Internet and to make it easier to register Internet-related information with the various authorities responsible for OSI standards in the United States 🤝

---

Security Considerations 🔐💀

Okay bestie, this part is SUPER serious 😭 Finally, when it comes to security, a concerted effort should be made to develop guidance and documentation for Internet host managers. That guidance should cover configuration management, known security problems (and their solutions), and the software and technologies available to provide enhanced security and privacy to Internet users 🛡️ No skipping this one, it's giving high stakes ✨

REFERENCES 📚

okay bestie, here's the receipts 🧾✨ every paper and RFC this one leans on, listed exactly as it's cited. the classics are iconic 💅

• [BARAN 64] Baran, P., et al, "On Distributed Communications", Volumes I-XI, RAND Corporation Research Documents, August 1964.
• [CERF 74] Cerf V., and R. Kahn, "A Protocol for Packet Network Interconnection", IEEE Trans. on Communications, Vol. COM-22, No. 5, pp. 637-648, May 1974.
• [CERF 82] Cerf V., and E. Cain, "The DoD Internet Protocol Architecture", Proceedings of the SHAPE Technology Center Symposium on Interoperability of Automated Data Systems, November 1982. Also in Computer Networks and ISDN, Vol. 17, No. 5, October 1983.
• [CLARK 86] Clark, D., "The Design Philosophy of the DARPA Internet protocols", Proceedings of the SIGCOMM '88 Symposium, Computer Communications Review, Vol. 18, No. 4, pp. 106-114, August 1988.
• [HEART 70] Heart, F., R. Kahn, S. Ornstein, W. Crowther, and D. Walden, "The Interface Message Processor for the ARPA Computer Network", AFIPS Conf. Proc. 36, pp. 551-567, June 1970.
• [IEEE 78] Kahn, R. (Guest Editor), K. Uncapher, and H. Van Trees (Associate Guest Editors), Proceedings of the IEEE, Special Issue on Packet Communication Networks, Volume 66, No. 11, pp. 1303-1576, November 1978.
• [IEEE 87] Leiner, B. (Guest Editor), D. Nielson, and F. Tobagi (Associate Guest Editors), Proceedings of the IEEE, Special Issue on Packet Radio Networks, Volume 75, No. 1, pp. 1-272, January 1987.
• [LEINER 85] Leiner, B., R. Cole, J. Postel, and D. Mills, "The DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C., March 1985. Also in IEEE Communications Magazine, March 1985.
• [METCALFE 76] Metcalfe, R., and D. Boggs, "Ethernet: Distributed Packet for Local Computer Networks", Communications of the ACM, Vol. 19, No. 7, pp. 395-404, July 1976.
• [POSTEL 85] Postel, J., "Internetwork Applications Using the DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C., March 1985.
• [RFC 821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1982.
• [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, University of Delaware, August 1982.
• [RFC 987] Kille, S., "Mapping between X.400 and RFC 822", University College London, June 1986.
• [RFC 1000] Reynolds, J., and J. Postel, "The Request for Comments References Guide", USC/Information Sciences Institute, RFC 1000, August 1987.
• [RFC 1026] Kille, S., "Addendum to RFC 987: (Mapping between X.400 and RFC 822)", RFC 1026, University College London, September 1987.
• [RFC 1100] Postel, J. (Editor), "IAB Official Protocol Standards", RFC 1100, April 1989.
• [RFC 1109] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989.
• [RFC 1113] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encipherment and Authentication Procedures", RFC 1113, IAB Privacy Task Force, August 1989.
• [RFC 1114] Kent, S., and J. Linn, "Privacy Enhancement for Internet Electronic Mail: Part II -- Certificate-based Key Management", RFC 1114, IAB Privacy Task Force, August 1989.
• [RFC 1115] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part III -- Algorithms, Modes and Identifiers", RFC 1115, IAB Privacy Task Force, August 1989.
• [ROBERTS 70] Roberts, L., and B. Wessler, "Computer Network Development to Achieve Resource Sharing", pp. 543-549, Proc. SJCC 1970.
• [ROBERTS 78] Roberts, L., "Evolution of Packet Switching", Proc. IEEE, Vol. 66, No. 11, pp. 1307-1313, November 1978.

Note: RFCs are available from the Network Information Center at SRI International, 333 Ravenswood Ave., Menlo Park, CA 94025, (1-800-235-3155), or on-line via anonymous file transfer from NIC.DDN.MIL.

---

Author's Address 🎀

the author's contact info, straight from the source 💌

Vinton G. Cerf
Corporation for National Research Initiatives
1895 Preston White Drive, Suite 100
Reston, VA 22091

Phone: (703) 620-8990

EMail: VCERF@NRI.RESTON.VA.US