summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1052.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1052.txt')
-rw-r--r--doc/rfc/rfc1052.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc1052.txt b/doc/rfc/rfc1052.txt
new file mode 100644
index 0000000..35de17f
--- /dev/null
+++ b/doc/rfc/rfc1052.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group V. Cerf
+Request for Comments: 1052 NRI
+ April 1988
+
+ IAB Recommendations for the Development of
+ Internet Network Management Standards
+
+Status of this Memo
+
+ 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.
+
+Background
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+Cerf [Page 1]
+
+RFC 1052 Internet Management April 1988
+
+
+Specific Recommendations
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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:
+
+ 1. Rapid convergence and definition for SNMP.
+
+ 2. Rapid convergence and definition for the TCP/IP MIB.
+
+ 3. Provision for transitioning from SNMP to CMIP/CMIS.
+
+ 4. Early demonstration of the CMIP/CMIS capability using the
+ TCP/IP MIB.
+
+ 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.
+
+
+
+
+
+
+Cerf [Page 2]
+
+RFC 1052 Internet Management April 1988
+
+
+ REPORT OF THE AD HOC NETWORK MANAGEMENT REVIEW COMMITTEE
+
+ Edited by Vinton Cerf, Chairman
+
+ March 1988
+
+EXECUTIVE SUMMARY
+
+ 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.
+
+ 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:
+
+ 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.
+
+ (Rationale: The software is available and in operation.)
+
+ 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).
+
+ (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.)
+
+ 3. Responsibility for the SNMP effort should be placed in the
+ hands of an IETF task force.
+
+ (Rationale: Eliminate vendor-specific bias or control over the
+ SNMP and its evolution and harmonize inputs from the Internet
+ community.)
+
+
+
+
+Cerf [Page 3]
+
+RFC 1052 Internet Management April 1988
+
+
+ 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.)
+
+ 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.
+
+1. INTRODUCTION
+
+ 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.
+
+ 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.
+
+
+
+
+Cerf [Page 4]
+
+RFC 1052 Internet Management April 1988
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ Reference material listed at the end of this report was provided in
+ advance of the meeting.
+
+2. DISCUSSION
+
+ 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.
+
+ The agenda was followed fairly closely with the technical
+ presentations made in the order suggested: HEMS, SGMP, CMIP/CMIS.
+
+ 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.
+
+ The SGMP effort, though somewhat less documented, was rooted in a
+
+
+
+Cerf [Page 5]
+
+RFC 1052 Internet Management April 1988
+
+
+ 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.
+
+ 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.
+
+ 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).
+
+
+
+Cerf [Page 6]
+
+RFC 1052 Internet Management April 1988
+
+
+ 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.
+
+3. POINTS OF AGREEMENT
+
+ (i) Future Internet development is a joint interest of the R&D
+ community, the vendor community and the user community.
+
+ [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.]
+
+ (ii) We still don't have a common understanding of what
+ [Inter]Network Management really is.
+
+ [Editor's comment: We haven't tried to manage the Internet as a
+ collection of autonomous systems in an effective way, yet.]
+
+ (iii) We will learn what [Inter]Network Management is by doing it.
+
+ (a) in as large a scale as is possible
+
+ (b) with as much diversity of implementation as possible
+
+ (c) over as wide a range of protocol layers as possible
+
+ (d) with as much administrative diversity as we can stand.
+
+ (iv) There are more than HEMS, SGMP and CMIS/CMIP as potential
+ candidates:
+
+ HEMS, SGMP, CMIS/CMIP [multiple profiles], NETVIEW,
+ LANMANAGER, Network Computing Forum "Fat Document"...
+
+ [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).]
+
+ (v) Define the Management Information Base for TCP/IP suite NOW!
+
+ (vi) Seek a seat for IETF on ANSI, ISO and/or CCITT!!!
+
+
+
+Cerf [Page 7]
+
+RFC 1052 Internet Management April 1988
+
+
+ [Editor's comment: This may actually be feasible.]
+
+ (vii) Define a CMIS interface to any of the surviving network
+ management schemes so as to provide a migration path to ISO.
+
+4. RESOLUTION AND CONCLUSIONS
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ In short, the ad hoc committee recommends:
+
+ 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.
+
+ (Rationale: The software is available and in operation.)
+
+ 2. In the longer term, the Internet research community and the
+ vendors should develop, deploy and test a network management
+
+
+
+Cerf [Page 8]
+
+RFC 1052 Internet Management April 1988
+
+
+ system based on the International Standards Organization (ISO)
+ Common Management Information Services/Common Management
+ Information Protocol (CMIS/CMIP).
+
+ (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.)
+
+ 3. Responsibility for the SNMP effort should be placed in the
+ hands of an IETF task force.
+
+ (Rationale: Eliminate vendor-specific bias or control over the
+ SNMP and its evolution and harmonize inputs from the Internet
+ community.)
+
+ 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.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cerf [Page 9]
+
+RFC 1052 Internet Management April 1988
+
+
+MEMBERS OF THE AD HOC NET MANAGEMENT REVIEW COMMITTEE
+
+ Amatzia Ben-Artzi
+ Sytek Corp.
+ 1225 Charleston Rd.
+ Mountain View, CA 94043
+ Amatzia@amadeus.stanford.edu
+
+ Bob Braden
+ USC-ISI
+ 4676 Admiralty Way
+ Marina del Rey, CA 90292
+ braden@isi.edu
+
+ Jeff Case
+ University of Tennessee
+ 200 Stokely Management Center
+ Knoxville, TN 37996
+ case@utkcs2.cs.utk.edu
+
+ Vint Cerf - Chairman
+ Corp. for National Research Initiatives
+ 1895 Preston White Dr., Suite 100
+ Reston, VA 22091
+ (703) 620-8990
+ Cerf@ISI.EDU
+
+ Chuck Davin
+ Proteon, Inc.
+ 2 Technology Dr.
+ Westborough, MA 01536
+ jrd@monk.proteon.com
+
+ Stephen Dunford
+ UNISYS Corp.
+ System Development Corporation
+ 5151 Camino Road
+ Camarillo, CA 93010
+ dunford@cam.unisys.com
+
+ Mark Fedor
+ NYSERNET
+ 125 Jordan Road
+ Troy, NY 12180
+ fedor@nisc.nyser.net
+
+
+
+
+
+
+Cerf [Page 10]
+
+RFC 1052 Internet Management April 1988
+
+
+ Phill Gross - IETF Chairman
+ MITRE Corporation
+ 1820 Dolley Madison Blvd.
+ McLean, VA 22012
+ Gross@Gateway.MITRE.Org
+
+ Lee LaBarre
+ MITRE Corporation
+ Burlington Road
+ Bedford, MA 01730
+ cel@mitre-bedford.arpa
+
+ Dan Lynch
+ Advanced Computing Environments
+ 480 San Antonio Rd.
+ Mountain View, CA 94040
+ Lynch@isi.edu
+
+ Jim Mathis
+ Apple Computer, Inc.
+ MS 27-0
+ 20525 Mariani Ave.
+ Cupertino, CA 95014
+ Mathis@Apple.com
+
+ Craig Partridge
+ BBN Labs
+ 10 Moulton St.
+ Cambridge, MA 02238
+ craig@bbn.com
+
+ Marshall T. Rose
+ The Wollongong Group, Inc.
+ 1129 San Antonio Road
+ Palo Alto, CA 94043
+ MRose@twg.com
+
+ Greg Satz
+ Cisco Systems
+ 1360 Willow Rd., Suite 201
+ Menlo Park, CA 94301
+ satz@cisco.com
+
+ Martin Lee Schoffstall
+ NYSERNET
+ 125 Jordan Road
+ Troy, NY 12180
+ schoff@nisc.nyser.net
+
+
+
+Cerf [Page 11]
+
+RFC 1052 Internet Management April 1988
+
+
+ Glenn Trewitt
+ Center for Integrated Systems, Room 216
+ Stanford University
+ Stanford, CA 94305
+ Trewitt@amadeus.stanford.edu
+
+MEETING LOCATION: San Diego Supercomputer Center, UC San Diego
+
+LOCAL ARRANGEMENTS: Paul Love, SDSC
+
+MEETING DATE: 29 February 1988
+
+AGENDA ITEMS:
+
+ 0900 Introductions and Objectives/Cerf
+
+ 0915 HEMS: Craig Partridge and Glenn Trewitt
+
+ 1030 Break
+
+ 1045 SGMP - Jeff Case
+
+ 1145 CMIP/CMIS - Amatzia Ben-Artzi
+
+ 1245 Lunch Break
+
+ 1430 TCP/IP and ISO: Politics, Technology, Penetration/Cerf
+
+ 1530 Break
+
+ 1545 Tradeoffs among alternate paths (Discussion)
+
+ 1700 Resolution of alternatives
+
+ 1730 Summary of conclusions/actions
+
+ 1800 Adjourn
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cerf [Page 12]
+
+RFC 1052 Internet Management April 1988
+
+
+REFERENCES
+
+ 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.
+
+ HEMS
+
+ (1) Craig Partridge, "A UNIX Implementation of HEMS", USENIX,
+ February 1988. [Available from C. Partridge, BBN Labs]
+
+ (2) Craig Partridge and Glenn Trewitt, "The High-Level Entity
+ Management System", RFC-1021.
+
+ (3) Craig Partridge and Glenn Trewitt, "The High-Level Entity
+ Management Protocol", RFC-1022.
+
+ (4) Glenn Trewitt and Craig Partridge, "The HEMS Monitoring and
+ Control Language", RFC-1023.
+
+ (5) Craig Partridge and Glenn Trewitt, "HEMS Variable
+ Definitions", RFC-1024.
+
+ (6) Craig Partridge and Glenn Trewitt, "The High-Level Entity
+ Management System", IEEE Network magazine, March 1988.
+
+ SGMP/SNMP
+
+ (1) James Davin, Jeff Case, Mark Fedor and Martin Schoffstall, "A
+ Simple Gateway Monitoring Protocol", RFC-1028, November 1987.
+
+ (2) James Davin, Jeff Case, Mark Fedor and Martin Schoffstall, "A
+ Simple Network Management Protocol", IDEA-11, February 1988,
+ obsoletes RFC-1028 when issued.
+
+ (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.
+
+ CMIS/CMIP
+
+ (1) Amatzia Ben-Artzi, "Network Management for TCP/IP Network: An
+ Overview", IDEA-12, February 1988.
+
+
+
+
+Cerf [Page 13]
+
+RFC 1052 Internet Management April 1988
+
+
+ (2) Lee LaBarre, " TCP/IP Network Management Implementors
+ Agreements", IDEA-13, January 1988.
+
+ (3) Lee LaBarre, "Data Link Layer Management Information:
+ MAC802.3", DRAFT-MMMM, February 1988.
+
+ (4) Lee LaBarre, "Network Layer Management Information: IP",
+ DRAFT-NNNN, February 1988.
+
+ (5) Marshall Rose, "ISO Presentation Services on Top of TCP/IP-
+ based Internets", DRAFT-PPPP, February 1988.
+
+ (6) Lee LaBarre, "Structure and Identification of Management
+ Information for the Internet", DRAFT-SMI, February 1988.
+
+ (7) Lee LaBarre, "Transport Layer Management Information: TCP",
+ DRAFT-TTTT, February 1988.
+
+ (8) Lee LaBarre, "Transport Layer Management Information: UDP",
+ DRAFT-UUUU, February 1988.
+
+ (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.
+
+ (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.
+
+ (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.
+
+ (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.
+
+ (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.
+
+ (14) S. Mark Klerer, "The OSI Management Architecture: An
+ Overview", IEEE Network Magazine, March 1988.
+
+
+
+
+
+
+Cerf [Page 14]
+