home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1052.txt < prev    next >
Text File  |  1996-05-07  |  30KB  |  398 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            V. Cerf Request for Comments: 1052                                           NRI                                                               April 1988 
  8.  
  9.                IAB Recommendations for the Development of                  Internet Network Management Standards 
  10.  
  11. Status of this Memo 
  12.  
  13.    This memo is intended to convey to the Internet community and other    interested parties the recommendations of the Internet Activities    Board (IAB) for the development of network management protocols for    use in the TCP/IP environment.  The memo does NOT, in and of itself,    define or propose an Official Internet Protocol.  It does reflect,    however, the policy of the IAB with respect to further network    management development in the short and the long term.  Distribution    of this memo is unlimited. 
  14.  
  15. Background 
  16.  
  17.    At the IAB meeting on 21 March 88 in videoconference, the report of    the Ad Hoc Network Management Review Committee was reviewed.  The    recommendations of the committee were endorsed by the IAB and    direction given to the chairman of the Internet Engineering Task    Force to take the necessary steps to implement the recommendations. 
  18.  
  19.    The IAB expressed its gratitude for the efforts of the HEMS, SNMP and    CMIP/CMIS working groups and urged that parties with technical    interest in the outcome of the network management working groups    convey their ideas and issues to the relevant working group chairmen. 
  20.  
  21.    The IETF chairman was directed to form two new working groups, one of    which would be responsible for the further specification and    definition of elements to be included in the Management Information    Base (MIB).  The other would be responsible for defining extensions    to the Simple Network Management Protocol to accommodate the short-    term needs of the network vendor and operator communities.  The    longer-term needs of the Internet community are to be met using the    ISO CMIS/CMIP framework as a basis.  A working group of the IETF    exists for this work and would continue its work, coordinating with    the two new groups and reporting to the IETF chairman for guidance. 
  22.  
  23.    The output of the MIB working group is to be provided to both the    SNMP working group and the CMIS/CMIP ["Netman"] working group so as    to assure compatibility of monitored items for both network    management frameworks. 
  24.  
  25.  
  26.  
  27.  
  28.  
  29. Cerf                                                            [Page 1] 
  30.  RFC 1052                  Internet Management                 April 1988 
  31.  
  32.  Specific Recommendations 
  33.  
  34.    The IAB recommends that the Simple Network Management Protocol be    adopted as the BASIS for network management in the short-term.    Extensions may be required to the existing SNMP specification to    accommodate additional data types or to deal with functional or    performance issues arising as multiple SNMP implementations are    deployed and applied, especially in multi-vendor applications. 
  35.  
  36.    The SNMP working group constituted by the IETF is charged with    considering requirements not met by the present SNMP definition,    defining extensions, if necessary, to accommodate these needs, and    preparing revisions of the SNMP specifications to address any new    extensions. 
  37.  
  38.    The IAB urges the working group to be extremely sensitive to the need    to keep SNMP simple, to work quickly to come to concensus on any    revisions needed and to promulgate expeditiously the results of its    work in one or more RFCs within the next 90 days.  The IETF chairman    is responsible for resolving disagreements arising if they cannot be    resolved within the working group and is instructed to escalate    problems quickly to the IAB should resolution not be forthcoming. 
  39.  
  40.    The IAB further recommends that the MIB working group begin its work    equally expeditiously, taking as its starting inputs the MIB    definitions found in the existing High-Level Entity Management    Systems (HEMS) RFC-1024, the SNMP IDEA-11, and CMIS/CMIP IDEAs. 
  41.  
  42.    It is the intention of the IAB that the MIB definitions be applied    both to the SNMP system in the short term and CMIS/CMIP for TCP/IP in    the longer term.  The three working groups will have to coordinate    their efforts carefully to achieve these objectives: 
  43.  
  44.            1. Rapid convergence and definition for SNMP. 
  45.  
  46.            2. Rapid convergence and definition for the TCP/IP MIB. 
  47.  
  48.            3. Provision for transitioning from SNMP to CMIP/CMIS. 
  49.  
  50.            4. Early demonstration of the CMIP/CMIS capability using the               TCP/IP MIB. 
  51.  
  52.    The IAB remains extremely interested in progress towards these goals    and intends to have representation, whenever possible, in the various    working group and IETF plenary activities. 
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  Cerf                                                            [Page 2] 
  59.  RFC 1052                  Internet Management                 April 1988 
  60.  
  61.           REPORT OF THE AD HOC NETWORK MANAGEMENT REVIEW COMMITTEE 
  62.  
  63.                       Edited by Vinton Cerf, Chairman 
  64.  
  65.                                 March 1988 
  66.  
  67. EXECUTIVE SUMMARY 
  68.  
  69.    On 29 February 88, an ad hoc committee was convened to review the    network management options for the Internet in particular and the    TCP/IP protocol suite in general.  This meeting was called at the    request of the Internet Activities Board in the course of exercising    its responsibilities to the Federal Research Internet Coordinating    Council (FRICC) and by the MITRE Corporation as a consequence of its    work for the U.S. Air Force on the ULANA project. 
  70.  
  71.    At the conclusion of the one day meeting, it was agreed that the    following recommendations be forwarded to the Internet Activities    Board chairman, Dr. David C. Clark, for consideration at the next IAB    meeting scheduled for 21 March: 
  72.  
  73.       1. In the short term, the Internet community should adopt and       adapt the Simple Network Management Protocol (SNMP) for use as the       basis of common network management throughout the system. 
  74.  
  75.       (Rationale:  The software is available and in operation.) 
  76.  
  77.       2. In the longer term, the Internet research community and the       vendors should develop, deploy and test a network management       system based on the International Standards Organization (ISO)       Common Management Information Services/Common Management       Information Protocol (CMIS/CMIP). 
  78.  
  79.       (Rationale: The Internet community can take the high ground in       protocol development by virtue of the experimental environment in       which it can operate.  Recommendations to the ISO from this       community, the IAB and the vendors will carry great weight if they       are in the language of the ISO common network management system       and if they are rooted in actual experience with implementation       and use in the field.) 
  80.  
  81.       3. Responsibility for the SNMP effort should be placed in the       hands of an IETF task force. 
  82.  
  83.       (Rationale:  Eliminate vendor-specific bias or control over the       SNMP and its evolution and harmonize inputs from the Internet       community.) 
  84.  
  85.  
  86.  
  87.  Cerf                                                            [Page 3] 
  88.  RFC 1052                  Internet Management                 April 1988 
  89.  
  90.        4. As a high priority effort, define an extended Management       Information Base (MIB) for SNMP and TCP/IP CMIP to bring them into       closer conformance with the MIB defined for the experimental       HighLevel Entity Management System (HEMS). 
  91.  
  92.       (Rationale:  The HEMS effort produced a very thorough and widely-       discussed set of elements to monitor, along with definitions of       the semantics of these elements.  The current SNMP definitions are       more restricted and the CMIP definitions less precise.       Implementation of SNMP in a timely and useful fashion through the       Internet cannot be satisfactorily completed without such a       definition of information elements in hand.) 
  93.  
  94.       The ad hoc committee therefore recommends immediate action by the       IAB on all four of these points.  It should be noted that this       resolution would not have been possible in such a timely way       without the statesman-like efforts of Craig Partridge who, at the       end of the day, recommended that the HEMS effort be withdrawn from       consideration so as to pave the way for an Internet-wide       agreement.  In consideration of this unselfish act, the ad hoc       committee urges the IAB to approve the recommendations above and       to instruct the IETF to move quickly to accept and act on the SNMP       items requiring completion. 
  95.  
  96. 1. INTRODUCTION 
  97.  
  98.    During its development history, the community of researchers,    developers, implementors and users of the DARPA/DoD TCP/IP protocol    suite have experimented with a wide range of protocols in a variety    of different networking environments.  The Internet has grown,    especially in the last few years, as a result of the widespread    availability of software and hardware supporting this system.  The    scaling of the size and scope of the Internet and increased use of    its technology in commercial applications has underscored for    researchers, developers and vendors the need for a common network    management framework within which TCP/IP products can be made to    work. 
  99.  
  100.    In recognition of this need, several efforts were started to develop    network management concepts which might be applied to the Internet    and to the internet technology in general.  Three of these efforts    had made sufficient progress by the end of 1987 that it became clear    that some choices had to be made or the community would find itself    with a set of incompatible network management tools.  These efforts    included the High-Level Entity Management System (HEMS), the Simple    Gateway Monitoring Protocol (SGMP) and the Common Management    Information Service/Protocol. 
  101.  
  102.  
  103.  
  104.  Cerf                                                            [Page 4] 
  105.  RFC 1052                  Internet Management                 April 1988 
  106.  
  107.     The latter is an ISO initiative which was adapted to Internet use in    a vendor-initiated effort.  The HEMS work was carried out in the    context of the Gateway Monitoring group of the Internet Engineering    Task Force.  The SGMP effort was carried out largely in the practical    context of the NYSERNET and SURAnet regional networks which needed    network management facilities to operate satisfactorily. 
  108.  
  109.    Independent of the general Internet situation and requirements, the    U.S.  Air Force has been pursuing a Universal Local Area Network    Architecture (ULANA) for its own use. The principal agent for the    development of the ULANA specifications is the MITRE Corporation.    Faced with several long and short term network management options,    the MITRE ULANA specification team initiated an effort with    substantial vendor participation called the NETMAN working group. 
  110.  
  111.    It was against this fabric of various options that the IAB appointed    a chairman to convene a review committee to discuss these various    options and to make recommendations on long and short term choices.    The MITRE Corporation co-sponsored this work to further its aims in    the specification of the ULANA design. 
  112.  
  113.    Reference material listed at the end of this report was provided in    advance of the meeting. 
  114.  
  115. 2. DISCUSSION 
  116.  
  117.    Rather than attempting to produce minutes of the meeting, this    section summarizes in very high level terms the substance of the    discussion which took place during most of the meeting.  Presentation    viewgraphs can be made available to IAB/FRICC members interested in    their contents. 
  118.  
  119.    The agenda was followed fairly closely with the technical    presentations made in the order suggested: HEMS, SGMP, CMIP/CMIS. 
  120.  
  121.    The HEMS effort has established a benchmark for other network    management work in the sense that it took a comprehensive conceptual    view of the problem and went into considerable detail on the design    of the underlying management information database, the mechanics of    access to and reporting of information, considerations of scaling and    performance (e.g., Query Language vs Remote Procedure Call style),    definition of information required and so on.  HEMS has been    implemented in an experimental version from which some encouraging    performance measurements were taken.  Serious vendor interest in this    protocol was expressed by Cisco Systems and implementation efforts    were under way as of the meeting. 
  122.  
  123.    The SGMP effort, though somewhat less documented, was rooted in a 
  124.  
  125.  
  126.  
  127. Cerf                                                            [Page 5] 
  128.  RFC 1052                  Internet Management                 April 1988 
  129.  
  130.     practical need for network management tools for the NYSERNET,    SURAnet, and, by extension, other components of the Internet.    Implementations of it exist, in its RFC-1028 form (probably with some    experimental extensions based on experience gained from the initial    work), and are in use today.  Serious vendor support for this work is    found at Proteon and, more recently, in the NSFNET effort by MERIT,    IBM and MCI, specifically in the IBM Network Switching System (NSS)    nodes.  Applications running above SGMP exist and provide useful    monitoring information, presented in easily grasped form.     The ISO CMIS/CMIP effort, voluminously documented, has had almost no    implementation as yet.  Reports from Unisys/SDC about an experimental    implementation were heard at the meeting.  There is substantial    momentum in the international community for the adoption of this    service and protocol suite for network management.  The Draft    Proposal is out for its second ballot (it failed to make Draft    International Standard on its first ballot).  There is vocal vendor    support for this work, based on the premise that ultimately the ISO    protocol suite will propagate and the vendors must support it. 
  131.  
  132.    In general, all of the network management proposals make use of the    Abstract Syntax Notation 1 (ASN.1) which has emerged from the ISO    efforts as a kind of lingua franca for the representation of    arbitrary data structures.  The data types used in the SGMP    Management Information Base (aspects of network components to be    monitored) are the most restricted of the three proposals, confined    to integers and octet strings only.  HEMS has the most extensive    Management Information Base and added some rather unique ideas such    as self-knowledge about what could be monitored so that a    device/unit/component could respond to a query asking "what can you    tell me about yourself and your operation and how is it represented?"    (!).  CMIS/CMIP is probably the broadest in scope, but less precisely    defined at this point, with respect to information which should be    monitored.  The draft RFCs referenced above relating to the CMIS/CMIP    concerning items to be monitored are still in the definition stages. 
  133.  
  134.    A point made strongly by the HEMS team was their concern that a    Remote Operations basis for CMIP may not scale well into a very large    Internet which needs to be monitored from a few central sites.    Remote Operations is a term used by ISO and means, roughly, what the    Internet community has long referred to as Remote Procedure Calls.    If each atomic action is a Remote Procedure Call, the HEMS team    argues that increasing Internet size and potential delays may vastly    constrain the amount and timeliness of information which can be    collected.  The HEMS design uses, instead, a general query language    approach which permits more elaborate, multi-variable queries to be    formulated at the requesting site and processed at the responding    site(s). 
  135.  
  136.  
  137.  
  138. Cerf                                                            [Page 6] 
  139.  RFC 1052                  Internet Management                 April 1988 
  140.  
  141.     Although it does substantial injustice to the very lucid and helpful    presentations by representatives of each of the network management    research groups, I have chosen to leave out much of the detail from    this report and move directly to the points of agreement which were    reached by the Committee. 
  142.  
  143. 3. POINTS OF AGREEMENT 
  144.  
  145.    (i) Future Internet development is a joint interest of the R&D    community, the vendor community and the user community. 
  146.  
  147.    [Editor's comment: The development of the Internet is now not only    dependent on research work, but on the hardware and software of    vendors selling to both commercial ("internet") and the research    environment ("Internet").  Moreover, the Internet users are not all    concerned with network research; many of the components of the    Internet are based on vendor-supplied and supported subsystems.] 
  148.  
  149.    (ii) We still don't have a common understanding of what    [Inter]Network Management really is. 
  150.  
  151.    [Editor's comment: We haven't tried to manage the Internet as a    collection of autonomous systems in an effective way, yet.] 
  152.  
  153.    (iii) We will learn what [Inter]Network Management is by doing it. 
  154.  
  155.         (a) in as large a scale as is possible 
  156.  
  157.         (b) with as much diversity of implementation as possible 
  158.  
  159.         (c) over as wide a range of protocol layers as possible 
  160.  
  161.         (d) with as much administrative diversity as we can stand. 
  162.  
  163.    (iv) There are more than HEMS, SGMP and CMIS/CMIP as potential    candidates: 
  164.  
  165.         HEMS, SGMP, CMIS/CMIP [multiple profiles], NETVIEW,         LANMANAGER, Network Computing Forum "Fat Document"... 
  166.  
  167.    [Editor's comment: The multiplicity of options is motivation for    coalescing the energy of the Internet environment around single short    and long term foci so as to make more substantial progress in really    understanding network management per point (iii).] 
  168.  
  169.    (v) Define the Management Information Base for TCP/IP suite NOW! 
  170.  
  171.    (vi) Seek a seat for IETF on ANSI, ISO and/or CCITT!!! 
  172.  
  173.  
  174.  
  175. Cerf                                                            [Page 7] 
  176.  RFC 1052                  Internet Management                 April 1988 
  177.  
  178.     [Editor's comment: This may actually be feasible.] 
  179.  
  180.    (vii) Define a CMIS interface to any of the surviving network    management schemes so as to provide a migration path to ISO. 
  181.  
  182. 4. RESOLUTION AND CONCLUSIONS 
  183.  
  184.    In a dramatic act of statesmanship, Craig Partridge volunteered that    the HEMS proposal be dropped in favor of the other two efforts, SGMP    and CMIS/CMIP - IF THIS WOULD LEAD TO INTERNET-WIDE AGREEMENT ON A    NETWORK MANAGEMENT PLAN FOR THE SHORT AND LONG TERM. 
  185.  
  186.    A rationale for the long term was proposed, based on the assumption    that the ISO initiatives, and the U.S. Government issuance of the    GOSIP guidelines, would ultimately require at least the Government    users, and hence their vendor suppliers, to use ISO-based protocols    and tools. In this rationale, the Internet research community and its    vendors would "take the high ground" in network management by    implementing the CMIS/CMIP on top of the TCP/IP protocol suite and    deploy it widely for experimental use in the Internet. 
  187.  
  188.    Neither the ISO nor any other organization, including the Corporation    for Open Systems (COS) has anything close to the laboratory in large    that the Internet represents. By taking the initiative, the Internet    working groups can establish credibility based on experience which    will make it far more feasible to affect the evolution of the ISO    network management and other related efforts. The Internet community    will be able to speak with authority about problems with the design    or definition of CMIS/CMIP based on real implementation experience    and use, rather than solely analytic means. 
  189.  
  190.    In the short term, however, the Internet desperately needs tools to    apply to the operational management problems associated with its    rapid growth. Given the present state of advanced implementation of    the SGMP and its relative simplicity, the general agreement was that    SGMP (or its re-named successor, SNMP) should be quickly brought to    more complete specification for widespread implementation and use. 
  191.  
  192.    In short, the ad hoc committee recommends: 
  193.  
  194.       1. In the short term, the Internet community should adopt and       adapt the Simple Network Management Protocol (SNMP) for use as the       basis of common network management throughout the system. 
  195.  
  196.       (Rationale: The software is available and in operation.) 
  197.  
  198.       2. In the longer term, the Internet research community and the       vendors should develop, deploy and test a network management 
  199.  
  200.  
  201.  
  202. Cerf                                                            [Page 8] 
  203.  RFC 1052                  Internet Management                 April 1988 
  204.  
  205.        system based on the International Standards Organization (ISO)       Common Management Information Services/Common Management       Information Protocol (CMIS/CMIP). 
  206.  
  207.       (Rationale: The Internet community can take the high ground in       protocol development by virtue of the experimental environment in       which it can operate.  Recommendations to the ISO from this       community, the IAB and the vendors will carry great weight if they       are in the language of the ISO common network management system       and if they are rooted in actual experience with implementation       and use in the field.) 
  208.  
  209.       3. Responsibility for the SNMP effort should be placed in the       hands of an IETF task force. 
  210.  
  211.       (Rationale: Eliminate vendor-specific bias or control over the       SNMP and its evolution and harmonize inputs from the Internet       community.) 
  212.  
  213.       4. As a high priority effort, define an extended Management       Information Base (MIB) for SNMP and TCP/IP CMIP to bring them into       closer conformance with the MIB defined for the experimental       HighLevel Entity Management System (HEMS).           (Rationale:       The HEMS effort produced a very thorough and widely-discussed set       of elements to monitor, along with definitions of the semantics of       these elements. The current SNMP definitions are more restricted       and the CMIP definitions less precise. Implementation of SNMP in a       timely and useful fashion through the Internet cannot be       satisfactorily completed without such a definition of information       elements in hand.) 
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235. Cerf                                                            [Page 9] 
  236.  RFC 1052                  Internet Management                 April 1988 
  237.  
  238.  MEMBERS OF THE AD HOC NET MANAGEMENT REVIEW COMMITTEE 
  239.  
  240.    Amatzia Ben-Artzi    Sytek Corp.    1225 Charleston Rd.    Mountain View, CA 94043         Amatzia@amadeus.stanford.edu 
  241.  
  242.    Bob Braden    USC-ISI    4676 Admiralty Way    Marina del Rey, CA 90292         braden@isi.edu 
  243.  
  244.    Jeff Case    University of Tennessee    200 Stokely Management Center    Knoxville, TN 37996         case@utkcs2.cs.utk.edu 
  245.  
  246.    Vint Cerf - Chairman    Corp. for National Research Initiatives    1895 Preston White Dr., Suite 100    Reston, VA 22091        (703) 620-8990        Cerf@ISI.EDU 
  247.  
  248.    Chuck Davin    Proteon, Inc.    2 Technology Dr.    Westborough, MA 01536        jrd@monk.proteon.com 
  249.  
  250.    Stephen Dunford    UNISYS Corp.    System Development Corporation    5151 Camino Road    Camarillo, CA 93010         dunford@cam.unisys.com 
  251.  
  252.    Mark Fedor    NYSERNET    125 Jordan Road    Troy, NY 12180         fedor@nisc.nyser.net 
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  Cerf                                                           [Page 10] 
  259.  RFC 1052                  Internet Management                 April 1988 
  260.  
  261.     Phill Gross - IETF Chairman    MITRE Corporation    1820 Dolley Madison Blvd.    McLean, VA 22012         Gross@Gateway.MITRE.Org 
  262.  
  263.    Lee LaBarre    MITRE Corporation    Burlington Road    Bedford, MA 01730         cel@mitre-bedford.arpa 
  264.  
  265.    Dan Lynch    Advanced Computing Environments    480 San Antonio Rd.    Mountain View, CA 94040         Lynch@isi.edu 
  266.  
  267.    Jim Mathis    Apple Computer, Inc.    MS 27-0    20525 Mariani Ave.    Cupertino, CA 95014         Mathis@Apple.com 
  268.  
  269.    Craig Partridge    BBN Labs    10 Moulton St.    Cambridge, MA 02238        craig@bbn.com 
  270.  
  271.    Marshall T. Rose    The Wollongong Group, Inc.    1129 San Antonio Road    Palo Alto, CA 94043         MRose@twg.com 
  272.  
  273.    Greg Satz    Cisco Systems    1360 Willow Rd., Suite 201    Menlo Park, CA 94301         satz@cisco.com 
  274.  
  275.    Martin Lee Schoffstall    NYSERNET    125 Jordan Road    Troy, NY 12180         schoff@nisc.nyser.net 
  276.  
  277.  
  278.  
  279. Cerf                                                           [Page 11] 
  280.  RFC 1052                  Internet Management                 April 1988 
  281.  
  282.     Glenn Trewitt    Center for Integrated Systems, Room 216    Stanford University    Stanford, CA 94305         Trewitt@amadeus.stanford.edu 
  283.  
  284. MEETING LOCATION:  San Diego Supercomputer Center, UC San Diego 
  285.  
  286. LOCAL ARRANGEMENTS:  Paul Love, SDSC 
  287.  
  288. MEETING DATE:  29 February 1988 
  289.  
  290. AGENDA ITEMS: 
  291.  
  292.    0900 Introductions and Objectives/Cerf 
  293.  
  294.    0915 HEMS: Craig Partridge and Glenn Trewitt 
  295.  
  296.    1030 Break 
  297.  
  298.    1045 SGMP - Jeff Case 
  299.  
  300.    1145 CMIP/CMIS - Amatzia Ben-Artzi 
  301.  
  302.    1245 Lunch Break 
  303.  
  304.    1430 TCP/IP and ISO: Politics, Technology, Penetration/Cerf 
  305.  
  306.    1530 Break 
  307.  
  308.    1545 Tradeoffs among alternate paths (Discussion) 
  309.  
  310.    1700 Resolution of alternatives 
  311.  
  312.    1730 Summary of conclusions/actions 
  313.  
  314.    1800 Adjourn 
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  Cerf                                                           [Page 12] 
  329.  RFC 1052                  Internet Management                 April 1988 
  330.  
  331.  REFERENCES 
  332.  
  333.    The following reference material was provided in advance of the    meeting.  Note that some of the citations include informal    descriptors (such as IDEA numbers or DRAFT letter codes), for    example, IDEA-13 or DRAFT-AAAA.  IDEA notes may be updated from time    to time reusing the same number.  The IDEA notes are the working    notes of the Engineering Task Force.  The DRAFT is a temporary    notation and may not be meaningful for more than a few months. 
  334.  
  335.    HEMS 
  336.  
  337.       (1) Craig Partridge, "A UNIX Implementation of HEMS", USENIX,       February 1988.  [Available from C. Partridge, BBN Labs] 
  338.  
  339.       (2) Craig Partridge and Glenn Trewitt, "The High-Level Entity       Management System", RFC-1021. 
  340.  
  341.       (3) Craig Partridge and Glenn Trewitt, "The High-Level Entity       Management Protocol", RFC-1022. 
  342.  
  343.       (4) Glenn Trewitt and Craig Partridge, "The HEMS Monitoring and       Control Language", RFC-1023. 
  344.  
  345.       (5) Craig Partridge and Glenn Trewitt, "HEMS Variable       Definitions", RFC-1024. 
  346.  
  347.       (6) Craig Partridge and Glenn Trewitt, "The High-Level Entity       Management System", IEEE Network magazine, March 1988. 
  348.  
  349.    SGMP/SNMP 
  350.  
  351.       (1) James Davin, Jeff Case, Mark Fedor and Martin Schoffstall, "A       Simple Gateway Monitoring Protocol", RFC-1028, November 1987. 
  352.  
  353.       (2) James Davin, Jeff Case, Mark Fedor and Martin Schoffstall, "A       Simple Network Management Protocol", IDEA-11, February 1988,       obsoletes RFC-1028 when issued. 
  354.  
  355.       (3) Jeffrey R. Case, James R. Davin, Mark S. Fedor, Martin L.       Schoffstall, "Introduction to the Simple Gateway Monitoring       Protocol", IEEE Network Magazine, March 1988. 
  356.  
  357.    CMIS/CMIP 
  358.  
  359.       (1) Amatzia Ben-Artzi, "Network Management for TCP/IP Network: An       Overview", IDEA-12, February 1988. 
  360.  
  361.  
  362.  
  363.  Cerf                                                           [Page 13] 
  364.  RFC 1052                  Internet Management                 April 1988 
  365.  
  366.        (2) Lee LaBarre, " TCP/IP Network Management Implementors       Agreements", IDEA-13, January 1988. 
  367.  
  368.       (3) Lee LaBarre, "Data Link Layer Management Information:       MAC802.3", DRAFT-MMMM, February 1988. 
  369.  
  370.       (4) Lee LaBarre, "Network Layer Management Information: IP",       DRAFT-NNNN, February 1988. 
  371.  
  372.       (5) Marshall Rose, "ISO Presentation Services on Top of TCP/IP-       based Internets", DRAFT-PPPP, February 1988. 
  373.  
  374.       (6) Lee LaBarre, "Structure and Identification of Management       Information for the Internet", DRAFT-SMI, February 1988. 
  375.  
  376.       (7) Lee LaBarre, "Transport Layer Management Information: TCP",       DRAFT-TTTT, February 1988. 
  377.  
  378.       (8) Lee LaBarre, "Transport Layer Management Information: UDP",       DRAFT-UUUU, February 1988. 
  379.  
  380.       (9) ISO/IEC JTC 1/21 N 2058, "2nd DP 9595-1 Information Processing       Systems - Open Systems Interconnection - Management Information       Service Definition - Part 1: Overview", December 1987. 
  381.  
  382.       (10) ISO/IEC JTC 1/21 N 2059, "2nd DP 9595-2, Information       Processing Systems - Open Systems Interconnection - Management       Information Service Definition - Part 2: Common Management       Information Service Definition", December 1987. 
  383.  
  384.       (11) ISO/IEC JTC 1/21 N 2060, "2nd DP 9596-2, Information       Processing Systems - Open Systems Interconnection - Management       Information Protocol Specification - Part 2: Common Management       Information Protocol", December 1987. 
  385.  
  386.       (12) ISO/TC97/SC21/WG4 N 472, "US Comments on the Proposal for       Extension of the Common Management Information Services and       Protocol: Creation and Deletion Functions", November 1987. 
  387.  
  388.       (13) JTC1/SC21/WG4 N 482, "Proposal to extend M-Set and M-       Confirmed-Set to allow adding and removing values of a multi-       valued attribute", November 1987. 
  389.  
  390.       (14) S. Mark Klerer, "The OSI Management Architecture: An       Overview", IEEE Network Magazine, March 1988. 
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  Cerf                                                           [Page 14] 
  397.  
  398.