home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1100s / rfc1160.txt < prev    next >
Text File  |  1990-05-24  |  28KB  |  619 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            V. Cerf
  8. Request for Comments:  1160                                          NRI
  9. Obsoletes: RFC 1120                                             May 1990
  10.  
  11.  
  12.                      The Internet Activities Board
  13.  
  14. Status of this Memo
  15.  
  16.    This RFC provides a history and description of the Internet
  17.    Activities Board (IAB) and its subsidiary organizations.  This memo
  18.    is for informational use and does not constitute a standard.  This is
  19.    a revision of RFC 1120.  Distribution of this memo is unlimited.
  20.  
  21. 1. Introduction
  22.  
  23.    In 1968, the U.S. Defense Advanced Research Projects Agency (DARPA)
  24.    initiated an effort to develop a technology which is now known as
  25.    packet switching.  This technology had its roots in message switching
  26.    methods, but was strongly influenced by the development of low-cost
  27.    minicomputers and digital telecommunications techniques during the
  28.    mid-1960's [BARAN 64, ROBERTS 70, HEART 70, ROBERTS 78].  A very
  29.    useful survey of this technology can be found in [IEEE 78].
  30.  
  31.    During the early 1970's, DARPA initiated a number of programs to
  32.    explore the use of packet switching methods in alternative media
  33.    including mobile radio, satellite and cable [IEEE 78].  Concurrently,
  34.    Xerox Palo Alto Research Center (PARC) began an exploration of packet
  35.    switching on coaxial cable which ultimately led to the development of
  36.    Ethernet local area networks [METCALFE 76].
  37.  
  38.    The successful implementation of packet radio and packet satellite
  39.    technology raised the question of interconnecting ARPANET with other
  40.    types of packet nets.  A possible solution to this problem was
  41.    proposed by Cerf and Kahn [CERF 74] in the form of an internetwork
  42.    protocol and a set of gateways to connect the different networks.
  43.    This solution was further developed as part of a research program in
  44.    internetting sponsored by DARPA and resulted in a collection of
  45.    computer communications protocols based on the original Transmission
  46.    Control Protocol (TCP) and its lower level counterpart, Internet
  47.    Protocol (IP).  Together, these protocols, along with many others
  48.    developed during the course of the research, are referred to as the
  49.    TCP/IP Protocol Suite [RFC 1140, LEINER 85, POSTEL 85, CERF 82, CLARK
  50.    86].
  51.  
  52.    In the early stages of the Internet research program, only a few
  53.    researchers worked to develop and test versions of the internet
  54.    protocols.  Over time, the size of this activity increased until, in
  55.  
  56.  
  57.  
  58. Cerf                                                           [Page 1]
  59.  
  60. RFC 1160                        The IAB                        May 1990
  61.  
  62.  
  63.    1979, it was necessary to form an informal committee to guide the
  64.    technical evolution of the protocol suite.  This group was called the
  65.    Internet Configuration Control Board (ICCB) and was established by
  66.    Dr. Vinton Cerf who was then the DARPA program manager for the
  67.    effort. Dr. David C. Clark of the Laboratory for Computer Science at
  68.    Massachusetts Institute of Technology was named the chairman of this
  69.    committee.
  70.  
  71.    In January, 1983, the Defense Communications Agency, then responsible
  72.    for the operation of the ARPANET, declared the TCP/IP protocol suite
  73.    to be standard for the ARPANET and all systems on the network
  74.    converted from the earlier Network Control Program (NCP) to TCP/IP.
  75.    Late that year, the ICCB was reorganized by Dr. Barry Leiner, Cerf's
  76.    successor at DARPA, around a series of task forces considering
  77.    different technical aspects of internetting.  The re-organized group
  78.    was named the Internet Activities Board.
  79.  
  80.    As the Internet expanded, it drew support from U.S. Government
  81.    organizations including DARPA, the National Science Foundation (NSF),
  82.    the Department of Energy (DOE) and the National Aeronautics and Space
  83.    Administration (NASA).  Key managers in these organizations,
  84.    responsible for computer networking research and development, formed
  85.    an informal Federal Research Internet Coordinating Committee (FRICC)
  86.    to coordinate U.S. Government support for and development and use of
  87.    the Internet system.  The FRICC sponsored most of the U.S. research
  88.    on internetting, including support for the Internet Activities Board
  89.    and its subsidiary organizations.
  90.  
  91.    In 1990, the FRICC was reorganized as part of a larger initiative
  92.    sponsored by the networking subcommittee of the Federal Coordinating
  93.    Committee on Science, Engineering and Technology (FCCSET).  The
  94.    reorganization created the Federal Networking Council (FNC) and its
  95.    Working Groups.  The membership of the FNC included all the former
  96.    FRICC members and many other U.S. Government representatives.  The
  97.    first chairman of the FNC is Dr. Charles Brownstein of the National
  98.    Science Foundation.  The FNC is the Federal Government's body for
  99.    coordinating the agencies that support the Internet.  It provides
  100.    liaison to the Office of Science and Technology Policy (headed by the
  101.    President's Science Advisor) which is responsible for setting science
  102.    and technology policy affecting the Internet.  It endorses and
  103.    employs the existing planning and operational activities of the
  104.    community-based bodies that have grown up to manage the Internet in
  105.    the United States.  The FNC plans to involve user and supplier
  106.    communities through creation of an external advisory board and will
  107.    coordinate Internet activities with other Federal initiatives ranging
  108.    from the Human Genome and Global Change programs to educational
  109.    applications.  The FNC has also participated in planning for the
  110.    creation of a National Research and Education Network in the United
  111.  
  112.  
  113.  
  114. Cerf                                                           [Page 2]
  115.  
  116. RFC 1160                        The IAB                        May 1990
  117.  
  118.  
  119.    States.
  120.  
  121.    At the international level, a Coordinating Committee for
  122.    Intercontinental Research Networks (CCIRN) has been formed which
  123.    includes the U.S. FNC and its counterparts in North America and
  124.    Europe.  Co-chaired by the executive directors of the FNC and the
  125.    European Association of Research Networks (RARE), the CCIRN provides
  126.    a forum for cooperative planning among the principal North American
  127.    and European research networking bodies.
  128.  
  129. 2. Internet Activities Board
  130.  
  131.    The Internet Activities Board (IAB) is the coordinating committee for
  132.    Internet design, engineering and management.  The Internet is a
  133.    collection of over two thousand of packet switched networks located
  134.    principally in the U.S., but also in many other parts of the world,
  135.    all interlinked and operating using the protocols of the TCP/IP
  136.    protocol suite.  The IAB is an independent committee of researchers
  137.    and professionals with a technical interest in the health and
  138.    evolution of the Internet system.  Membership changes with time to
  139.    adjust to the current realities of the research interests of the
  140.    participants, the needs of the Internet system and the concerns of
  141.    constituent members of the Internet.
  142.  
  143.    IAB members are deeply committed to making the Internet function
  144.    effectively and evolve to meet a large scale, high speed future.  New
  145.    members are appointed by the chairman of the IAB, with the advice and
  146.    consent of the remaining members.  The chairman serves a term of two
  147.    years and is elected by the members of the IAB.  The IAB focuses on
  148.    the TCP/IP protocol suite, and extensions to the Internet system to
  149.    support multiple protocol suites.
  150.  
  151.    The IAB has two principal subsidiary task forces:
  152.  
  153.       1)  Internet Engineering Task Force (IETF)
  154.  
  155.       2)  Internet Research Task Force (IRTF)
  156.  
  157.    Each of these Task Forces is led by a chairman and guided by a
  158.    Steering Group which reports to the IAB through its chairman.  Each
  159.    task force is organized, by the chairman, as required, to carry out
  160.    its charter.  For the most part, a collection of Working Groups
  161.    carries out the work program of each Task Force.
  162.  
  163.    All decisions of the IAB are made public.  The principal vehicle by
  164.    which IAB decisions are propagated to the parties interested in the
  165.    Internet and its TCP/IP protocol suite is the Request for Comment
  166.    (RFC) note series.  The archival RFC series was initiated in 1969 by
  167.  
  168.  
  169.  
  170. Cerf                                                           [Page 3]
  171.  
  172. RFC 1160                        The IAB                        May 1990
  173.  
  174.  
  175.    Dr. Stephen D. Crocker as a means of documenting the development of
  176.    the original ARPANET protocol suite [RFC 1000].  The editor-in-chief
  177.    of this series, Dr. Jonathan B. Postel, has maintained the quality of
  178.    and managed the archiving of this series since its inception.  A
  179.    small proportion of the RFCs document Internet standards.  Most of
  180.    them are intended to stimulate comment and discussion.  The small
  181.    number which document standards are especially marked in a "status"
  182.    section to indicate the special status of the document.  An RFC
  183.    summarizing the status of all standard RFCs is published regularly
  184.    [RFC 1140].
  185.  
  186.    RFCs describing experimental protocols, along with other submissions
  187.    whose intent is merely to inform, are typically submitted directly to
  188.    the RFC editor.  A Standard Protocol starts out as a Proposed
  189.    Standard and may be promoted to Draft Standard and finally Standard
  190.    after suitable review, comment, implementation and testing.
  191.  
  192.    Prior to publication of a Proposed Standard RFC, it is made available
  193.    for comment through an on-line Internet-Draft directory.  Typically,
  194.    these Internet-Drafts are working documents of the IAB or of the
  195.    working groups of the Internet Engineering and Research Task Forces.
  196.    Internet-Drafts are either submitted to the RFC editor for
  197.    publication or discarded within 3-6 months.  Prior to promotion to
  198.    Draft Standard or Standard, an Internet-Draft publication and review
  199.    cycle may be initiated if significant changes to the RFC are
  200.    contemplated.
  201.  
  202.    The IAB performs the following functions:
  203.  
  204.       1)   Sets Internet Standards,
  205.  
  206.       2)   Manages the RFC publication process,
  207.  
  208.       3)   Reviews the operation of the IETF and IRTF,
  209.  
  210.       4)   Performs strategic planning for the Internet, identifying
  211.            long-range problems and opportunities,
  212.  
  213.       5)   Acts as an international technical policy liaison and
  214.            representative for the Internet community, and
  215.  
  216.       6)   Resolves technical issues which cannot be treated within
  217.            the IETF or IRTF frameworks.
  218.  
  219.    To supplement its work via electronic mail, the IAB meets quarterly
  220.    to review the condition of the Internet, to review and approve
  221.    proposed changes or additions to the TCP/IP suite of protocols, to
  222.    set technical development priorities, to discuss policy matters which
  223.  
  224.  
  225.  
  226. Cerf                                                           [Page 4]
  227.  
  228. RFC 1160                        The IAB                        May 1990
  229.  
  230.  
  231.    may need the attention of the Internet sponsors, and to agree on the
  232.    addition or retirement of IAB members and on the addition or
  233.    retirement of task forces reporting to the IAB.  Typically, two of
  234.    the quarterly meetings are by means of video teleconferencing
  235.    (provided, when possible, through the experimental Internet packet
  236.    video-conferencing system).  The minutes of the IAB meetings are
  237.    published in the Internet Monthly on-line report.
  238.  
  239.    The IAB membership is currently as follows:
  240.  
  241.             Vinton Cerf/CNRI              Chairman
  242.             Robert Braden/USC-ISI         Executive Director
  243.             David Clark/MIT-LCS           IRTF Chairman
  244.             Phillip Gross/CNRI            IETF Chairman
  245.             Jonathan Postel/USC-ISI       RFC Editor
  246.             Hans-Werner Braun/Merit       Member
  247.             Lyman Chapin/DG               Member
  248.             Stephen Kent/BBN              Member
  249.             Anthony Lauck/Digital         Member
  250.             Barry Leiner/RIACS            Member
  251.             Daniel Lynch/Interop, Inc.    Member
  252.  
  253. 3.  The Internet Engineering Task Force
  254.  
  255.    The Internet has grown to encompass a large number of widely
  256.    geographically dispersed networks in academic and research
  257.    communities.  It now provides an infrastructure for a broad community
  258.    with various interests.  Moreover, the family of Internet protocols
  259.    and system components has moved from experimental to commercial
  260.    development.  To help coordinate the operation, management and
  261.    evolution of the Internet, the IAB established the Internet
  262.    Engineering Task Force (IETF).  The IETF is chaired by Mr. Phillip
  263.    Gross and managed by its Internet Engineering Steering Group (IESG).
  264.    The IAB has delegated to the IESG the general responsibility for
  265.    making the Internet work and for the resolution of all short- and
  266.    mid-range protocol and architectural issues required to make the
  267.    Internet function effectively.
  268.  
  269.    The charter of the IETF includes:
  270.  
  271.       1) Responsibility for specifying the short and mid-term
  272.          Internet protocols and architecture and recommending
  273.          standards for IAB approval.
  274.  
  275.       2) Provision of a forum for the exchange of information within
  276.          the Internet community.
  277.  
  278.       3) Identification of pressing and relevant short- to mid-range
  279.  
  280.  
  281.  
  282. Cerf                                                           [Page 5]
  283.  
  284. RFC 1160                        The IAB                        May 1990
  285.  
  286.  
  287.          operational and technical problem areas and convening of
  288.          Working Groups to explore solutions.
  289.  
  290.    The Internet Engineering Task Force is a large open community of
  291.    network designers, operators, vendors, and researchers concerned with
  292.    the Internet and the Internet protocol suite.  It is organized around
  293.    a set of eight technical areas, each managed by a technical area
  294.    director.  In addition to the IETF Chairman, the area directors make
  295.    up the IESG membership.  Each area director has primary
  296.    responsibility for one area of Internet engineering activity, and
  297.    hence for a subset of the IETF Working Groups.  The area directors
  298.    have jobs of critical importance and difficulty and are selected not
  299.    only for their technical expertise but also for their managerial
  300.    skills and judgment.  At present, the eight technical areas and
  301.    chairs are:
  302.  
  303.             1) Applications             -  Russ Hobby/UC-Davis
  304.             2) Host and User Services   -  Craig Partridge/BBN
  305.             3) Internet Services        -  Noel Chiappa/Consultant
  306.             4) Routing                  -  Robert Hinden/BBN
  307.             5) Network Management       -  David Crocker/DEC
  308.             6) OSI Integration          -  Ross Callon/DEC and
  309.                                            Robert Hagens/UWisc.
  310.             7) Operations               -  Phill Gross/CNRI (Acting)
  311.             8) Security                 -  Steve Crocker/TIS
  312.  
  313.    The work of the IETF is performed by subcommittees known as Working
  314.    Groups.  There are currently more than 40 of these.  Working Groups
  315.    tend to have a narrow focus and a lifetime bounded by completion of a
  316.    specific task, although there are exceptions.  The IETF is a major
  317.    source of proposed protocol standards, for final approval by the IAB.
  318.    The IETF meets quarterly and extensive minutes of the plenary
  319.    proceedings as well as reports from each of the working groups are
  320.    issued by the IAB Secretariat at the Corporation for National
  321.    Research Initiatives.
  322.  
  323. 4.  The Internet Research Task Force
  324.  
  325.    To promote research in networking and the development of new
  326.    technology, the IAB established the Internet Research Task Force
  327.    (IRTF).
  328.  
  329.    In the area of network protocols, the distinction between research
  330.    and engineering is not always clear, so there will sometimes be
  331.    overlap between activities of the IETF and the IRTF.  There is, in
  332.    fact, considerable overlap in membership between the two groups.
  333.    This overlap is regarded as vital for cross-fertilization and
  334.    technology transfer.  In general, the distinction between research
  335.  
  336.  
  337.  
  338. Cerf                                                           [Page 6]
  339.  
  340. RFC 1160                        The IAB                        May 1990
  341.  
  342.  
  343.    and engineering is one of viewpoint and sometimes (but not always)
  344.    time-frame.  The IRTF is generally more concerned with understanding
  345.    than with products or standard protocols, although specific
  346.    experimental protocols may have to be developed, implemented and
  347.    tested in order to gain understanding.
  348.  
  349.    The IRTF is a community of network researchers, generally with an
  350.    Internet focus.  The work of the IRTF is governed by its Internet
  351.    Research Steering Group (IRSG).  The chairman of the IRTF and IRSG is
  352.    David Clark.  The IRTF is organized into a number of Research Groups
  353.    (RGs) whose chairs of these are appointed by the chairman of the
  354.    IRSG. The RG chairs and others selected by the IRSG chairman serve on
  355.    the IRSG.  These groups typically have 10 to 20 members, and each
  356.    covers a broad area of research, pursuing specific topics, determined
  357.    at least in part by the interests of the members and by
  358.    recommendations of the IAB.
  359.  
  360.    The current members of the IRSG are as follows:
  361.  
  362.             David Clark/MIT LCS     -   Chairman
  363.             Robert Braden/USC-ISI   -   End-to-End Services
  364.             Douglas Comer/PURDUE    -   Member-at-Large
  365.             Deborah Estrin/USC      -   Autonomous Networks
  366.             Stephen Kent/BBN        -   Privacy and Security
  367.             Keith Lantz/Consultant  -   Collaboration Technology
  368.             David Mills/UDEL        -   Member-at-Large
  369.  
  370. 5.  The Near-term Agenda of the IAB
  371.  
  372.    There are seven principal foci of IAB attention for the period 1989 -
  373.    1990:
  374.  
  375.       1) Operational Stability
  376.       2) User Services
  377.       3) OSI Coexistence
  378.       4) Testbed Facilities
  379.       5) Security
  380.       6) Getting Big
  381.       7) Getting Fast
  382.  
  383.    Operational stability of the Internet is a critical concern for all
  384.    of its users.  Better tools are needed for gathering operational
  385.    data, to assist in fault isolation at all levels and to analyze the
  386.    performance of the system.  Opportunities abound for increased
  387.    cooperation among the operators of the various Internet components
  388.    [RFC 1109].  Specific, known problems should be dealt with, such as
  389.    implementation deficiencies in some versions of the BIND domain name
  390.    service resolver software.  To the extent that the existing Exterior
  391.  
  392.  
  393.  
  394. Cerf                                                           [Page 7]
  395.  
  396. RFC 1160                        The IAB                        May 1990
  397.  
  398.  
  399.    Gateway Protocol (EGP) is only able to support limited topologies,
  400.    constraints on topological linkages and allowed transit paths should
  401.    be enforced until a more general Inter-Autonomous System routing
  402.    protocol can be specified.  Flexiblity for Internet implementation
  403.    would be enhanced by the adoption of a common internal gateway
  404.    routing protocol by all vendors of internet routers.  A major effort
  405.    is recommended to achieve conformance to the Host Requirements RFCs
  406.    which were published in the fourth quarter of calendar 1989.
  407.  
  408.    Among the most needed user services, the White Pages (electronic
  409.    mailbox directory service) seems the most pressing.  Efforts should
  410.    be focused on widespread deployment of these capabilities in the
  411.    Internet by mid-1990.  The IAB recommends that existing white pages
  412.    facilities and newer ones, such as X.500, be populated with up-to-
  413.    date user information and made accessible to Internet users and users
  414.    of other systems (e.g., commercial email carriers) linked to the
  415.    Internet. Connectivity with commercial electronic mail carriers
  416.    should be vigorously pursued, as well as links to other network
  417.    research communities in Europe and the rest of the world.
  418.  
  419.    Development and deployment of privacy-enhanced electronic mail
  420.    software should be accelerated in 1990 after release of public domain
  421.    software implementing the private electronic mail standards [RFC
  422.    1113, RFC 1114 and RFC 1115].  Finally, support for new or enhanced
  423.    applications such as computer-based conferencing, multi-media
  424.    messaging and collaboration support systems should be developed.
  425.  
  426.    The National Network Testbed (NNT) resources planned by the FRICC
  427.    should be applied to support conferencing and collaboration protocol
  428.    development and application experiments and to support multi-vendor
  429.    router interoperability testing (e.g., interior and exterior routing,
  430.    network management, multi-protocol routing and forwarding).
  431.  
  432.    With respect to growth in the Internet, architectural attention
  433.    should be focused on scaling the system to hundreds of millions of
  434.    users and hundreds of thousands of networks.  The naming, addressing,
  435.    routing and navigation problems occasioned by such growth should be
  436.    analyzed.  Similarly, research should be carried out on analyzing the
  437.    limits to the existing Internet architecture, including the ability
  438.    of the present protocol suite to cope with speeds in the gigabit
  439.    range and latencies varying from microseconds to seconds in duration.
  440.  
  441.    The Internet should be positioned to support the use of OSI protocols
  442.    by the end of 1990 or sooner, if possible.  Provision for multi-
  443.    protocol routing and forwarding among diverse vendor routes is one
  444.    important goal.  Introduction of X.400 electronic mail services and
  445.    interoperation with RFC 822/SMTP [RFC 822, RFC 821, RFC 987, RFC
  446.    1026, and RFC 1148] should be targeted for 1990 as well.  These
  447.  
  448.  
  449.  
  450. Cerf                                                           [Page 8]
  451.  
  452. RFC 1160                        The IAB                        May 1990
  453.  
  454.  
  455.    efforts will need to work in conjunction with the White Pages
  456.    services mentioned above.  The IETF, in particular, should establish
  457.    liaison with various OSI working groups (e.g., at NIST, RARE, Network
  458.    Management Forum) to coordinate planning for OSI introduction into
  459.    the Internet and to facilitate registration of information pertinent
  460.    to the Internet with the various authorities responsible for OSI
  461.    standards in the United States.
  462.  
  463.    Finally, with respect to security, a concerted effort should be made
  464.    to develop guidance and documentation for Internet host managers
  465.    concerning configuration management, known security problems (and
  466.    their solutions) and software and technologies available to provide
  467.    enhanced security and privacy to the users of the Internet.
  468.  
  469. REFERENCES
  470.  
  471.        [BARAN 64]  Baran, P., et al, "On Distributed Communications",
  472.        Volumes I-XI, RAND Corporation Research Documents, August 1964.
  473.  
  474.        [CERF 74]  Cerf V., and R. Kahn, "A Protocol for Packet Network
  475.        Interconnection", IEEE Trans. on Communications, Vol. COM-22,
  476.        No. 5, pp. 637-648, May 1974.
  477.  
  478.        [CERF 82]  Cerf V., and E. Cain, "The DoD Internet Protocol
  479.        Architecture", Proceedings of the SHAPE Technology Center
  480.        Symposium on Interoperability of Automated Data Systems,
  481.        November 1982.  Also in Computer Networks and ISDN,
  482.        Vol. 17, No. 5, October 1983.
  483.  
  484.        [CLARK 86]  Clark, D., "The Design Philosophy of the DARPA
  485.        Internet protocols", Proceedings of the SIGCOMM '88 Symposium,
  486.        Computer Communications Review, Vol. 18, No. 4, pp. 106-114,
  487.        August 1988.
  488.  
  489.        [HEART 70]  Heart, F., Kahn, R., Ornstein, S., Crowther, W.,
  490.        and D. Walden, "The Interface Message Processor for the ARPA
  491.        Computer Network", AFIPS Conf. Proc. 36, pp. 551-567,
  492.        June 1970.
  493.  
  494.        [IEEE 78]  Kahn, R. (Guest Editor), Uncapher, K. and
  495.        H. Van Trees (Associate Guest Editors), Proceedings of the
  496.        IEEE, Special Issue on Packet Communication Networks,
  497.        Volume 66, No. 11, pp. 1303-1576, November 1978.
  498.  
  499.        [IEEE 87]  Leiner, B. (Guest Editor), Nielson, D., and
  500.        F. Tobagi (Associate Guest Editors), Proceedings of the
  501.        IEEE, Special Issue on Packet Radio Networks, Volume 75,
  502.        No. 1, pp. 1-272, January 1987.
  503.  
  504.  
  505.  
  506. Cerf                                                           [Page 9]
  507.  
  508. RFC 1160                        The IAB                        May 1990
  509.  
  510.  
  511.  
  512.        [LEINER 85]  Leiner, B., Cole, R., Postel, J., and D. Mills,
  513.        "The DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C.,
  514.        March 1985.  Also in IEEE Communications Magazine, March 1985.
  515.  
  516.        [METCALFE 76]  Metcalfe, R., and D. Boggs, "Ethernet:
  517.        Distributed Packet for Local Computer Networks", Communications
  518.        of the ACM, Vol. 19, No. 7, pp. 395-404, July 1976.
  519.  
  520.        [POSTEL 85]  Postel, J., "Internetwork Applications Using the
  521.        DARPA Protocol Suite", IEEE INFOCOM 85, Washington, D.C.,
  522.        March 1985.
  523.  
  524.        [RFC 821]  Postel, J., "Simple Mail Transfer Protocol", RFC 821,
  525.        USC/Information Sciences Institute, August 1982.
  526.  
  527.        [RFC 822]  Crocker, D., "Standard for the Format of ARPA Internet
  528.        Text Messages", RFC 822, University of Delaware, August 1982.
  529.  
  530.        [RFC 987]  Kille, S., "Mapping between X.400 and RFC 822",
  531.        University College London, June 1986.
  532.  
  533.        [RFC 1000]  Reynolds, J., and J. Postel, "The Request for
  534.        Comments Reference Guide", RFC 1000, USC/Information Sciences
  535.        Institute, August 1987.
  536.  
  537.        [RFC 1026]  Kille, S., "Addendum to RFC 987: (Mapping between
  538.        X.400 and RFC 822)", RFC 1026, University College London,
  539.        September 1987.
  540.  
  541.        [RFC 1109]  Cerf, V., "Report of the Second Ad Hoc Network
  542.        Management Review Group", RFC 1109, NRI, August 1989.
  543.  
  544.        [RFC 1113]  Linn, J., "Privacy Enhancement for Internet
  545.        Electronic Mail: Part I -- Message Encipherment and
  546.        Authentication Procedures", RFC 1113, IAB Privacy Task
  547.        Force, August 1989.
  548.  
  549.        [RFC 1114]  Kent, S.,  and J. Linn, "Privacy Enhancement for
  550.        Internet Electronic Mail: Part II -- Certificate-based Key
  551.        Management", RFC 1114, IAB Privacy Task Force, August 1989.
  552.  
  553.        [RFC 1115]  Linn, J., "Privacy Enhancement for Internet
  554.        Electronic Mail: Part III -- Algorithms, Modes and Identifiers",
  555.        RFC 1115, IAB Privacy Task Force, August 1989.
  556.  
  557.        [RFC 1140]  Postel, J., Editor, "IAB Official Protocol
  558.        Standards", RFC 1140, Internet Activities Board, May 1990.
  559.  
  560.  
  561.  
  562. Cerf                                                          [Page 10]
  563.  
  564. RFC 1160                        The IAB                        May 1990
  565.  
  566.  
  567.  
  568.        [RFC 1148]  Kille, S., "Mapping between X.400(1988) / ISO 10021
  569.        and RFC 822", RFC 1048, UCL, March 1990.
  570.  
  571.        [ROBERTS 70]  Roberts, L., and B. Wessler, "Computer Network
  572.        Development to Achieve Resource Sharing", pp. 543-549,
  573.        Proc. SJCC 1970.
  574.  
  575.        [ROBERTS 78]  Roberts, L., "Evolution of Packet Switching",
  576.        Proc.  IEEE, Vol. 66, No. 11, pp. 1307-1313, November 1978.
  577.  
  578.    Note:  RFCs are available from the Network Information Center at SRI
  579.    International, 333 Ravenswood Ave., Menlo Park, CA 94025, (1-800-
  580.    235-3155), or on-line via anonymous file transfer from NIC.DDN.MIL.
  581.  
  582. Author's Address
  583.  
  584.    Vinton G. Cerf
  585.    Corporation for National Research Initiatives
  586.    1895 Preston White Drive, Suite 100
  587.    Reston, VA 22091
  588.  
  589.    Phone: (703) 620-8990
  590.  
  591.    EMail: VCERF@NRI.RESTON.VA.US
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Cerf                                                          [Page 11]
  619.