home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1052 < prev    next >
Text File  |  1991-04-21  |  30KB  |  788 lines

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