summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1452.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1452.txt')
-rw-r--r--doc/rfc/rfc1452.txt1003
1 files changed, 1003 insertions, 0 deletions
diff --git a/doc/rfc/rfc1452.txt b/doc/rfc/rfc1452.txt
new file mode 100644
index 0000000..d5cdcc3
--- /dev/null
+++ b/doc/rfc/rfc1452.txt
@@ -0,0 +1,1003 @@
+
+
+
+ Network Working Group J. Case
+ Request for Comments: 1452 SNMP Research, Inc.
+ K. McCloghrie
+ Hughes LAN Systems
+ M. Rose
+ Dover Beach Consulting, Inc.
+ S. Waldbusser
+ Carnegie Mellon University
+ April 1993
+
+
+ Coexistence between version 1 and version 2 of the
+ Internet-standard Network Management Framework
+
+
+ Status of this Memo
+
+ This RFC specifes an IAB standards track protocol for the
+ Internet community, and requests discussion and suggestions
+ for improvements. Please refer to the current edition of the
+ "IAB Official Protocol Standards" for the standardization
+ state and status of this protocol. Distribution of this memo
+ is unlimited.
+
+
+ Table of Contents
+
+
+ 1 Introduction .......................................... 2
+ 2 Management Information ................................ 3
+ 2.1 Object Definitions .................................. 3
+ 2.2 Trap Definitions .................................... 6
+ 2.3 Compliance Statements ............................... 7
+ 2.4 Capabilities Statements ............................. 7
+ 3 Protocol Operations ................................... 8
+ 3.1 Proxy Agent Behavior ................................ 8
+ 3.1.1 SNMPv2 -> SNMPv1 .................................. 8
+ 3.1.2 SNMPv1 -> SNMPv2 .................................. 8
+ 3.2 Bi-lingual Manager Behavior ......................... 10
+ 4 Acknowledgements ...................................... 11
+ 5 References ............................................ 15
+ 6 Security Considerations ............................... 17
+ 7 Authors' Addresses .................................... 17
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 1]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ 1. Introduction
+
+ The purpose of this document is to describe coexistence
+ between version 2 of the Internet-standard Network Management
+ Framework, termed the SNMP version 2 framework (SNMPv2) [1],
+ and the original Internet-standard Network Management
+ Framework (SNMPv1), which consists of these three documents:
+
+ RFC 1155 [2] which defines the Structure of Management
+ Information (SMI), the mechanisms used for describing and
+ naming objects for the purpose of management.
+
+ RFC 1212 [3] which defines a more concise description
+ mechanism, which is wholly consistent with the SMI.
+
+ RFC 1157 [4] which defines the Simple Network Management
+ Protocol (SNMP), the protocol used for network access to
+ managed objects.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 2]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ 2. Management Information
+
+ The SNMPv2 approach towards describing collections of managed
+ objects is nearly a proper superset of the approach defined in
+ the Internet-standard Network Management Framework. For
+ example, both approaches use ASN.1 [5] as the basis for a
+ formal descriptive notation. Indeed, one might note that the
+ SNMPv2 approach largely codifies the existing practice for
+ defining MIB modules, based on extensive experience with the
+ current framework.
+
+ The SNMPv2 documents which deal with information modules are:
+
+ Structure of Management Information for SNMPv2 [6], which
+ defines concise notations for describing information
+ modules, managed objects and notifications;
+
+ Textual Conventions for SNMPv2 [7], which defines a
+ concise notation for describing textual conventions, and
+ also defines some initial conventions; and,
+
+ Conformance Statements for SNMPv2 [8], which defines
+ concise notation for describing compliance and
+ capabilities statements.
+
+ The following sections consider the three areas: MIB modules,
+ compliance statements, and capabilities statements.
+
+ MIB modules defined using the current framework may continue
+ to be used with the SNMPv2 protocol. However, for the MIB
+ modules to conform to the SNMPv2 framework, the following
+ changes are required:
+
+
+ 2.1. Object Definitions
+
+ In general, conversion of a MIB module does not require the
+ deprecation of the objects contained therein. Only if the
+ semantics of an object truly changes should deprecation be
+ performed.
+
+ (1) The IMPORTS statement must reference SNMPv2-SMI, instead
+ of RFC1155-SMI and RFC-1212.
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 3]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ (2) The MODULE-IDENTITY macro must be invoked immediately
+ after any IMPORTs or EXPORTs statement.
+
+ (3) For any descriptor which contains the hyphen character,
+ the hyphen character is removed.
+
+ (4) For any object with an integer-valued SYNTAX clause, in
+ which the corresponding INTEGER does not have a range
+ restriction (i.e., the INTEGER has neither a defined set
+ of named-number enumerations nor an assignment of lower-
+ and upper-bounds on its value), the object must have the
+ value of its SYNTAX clause changed to Integer32.
+
+ (5) For any object with a SYNTAX clause value of an
+ enumerated INTEGER, the hyphen character is removed from
+ any named-number labels which contain the hyphen
+ character.
+
+ (6) For any object with a SYNTAX clause value of Counter, the
+ object must have the value of its SYNTAX clause changed
+ to Counter32.
+
+ (7) For any object with a SYNTAX clause value of Gauge, the
+ object must have the value of its SYNTAX clause changed
+ to Gauge32.
+
+ (8) For all objects, the ACCESS clause must be replaced by a
+ MAX-ACCESS clause. The value of the MAX-ACCESS clause is
+ the same as that of the ACCESS clause unless some other
+ value makes "protocol sense" as the maximal level of
+ access for the object. In particular, object types for
+ which instances can be explicitly created by a protocol
+ set operation, will have a MAX-ACCESS clause of "read-
+ create". If the value of the ACCESS clause is "write-
+ only", then the value of the MAX-ACCESS clause is "read-
+ write", and the DESCRIPTION clause notes that reading
+ this object will result implementation-specific results.
+
+ (9) For any columnar object which is used solely for instance
+ identification in a conceptual row, the object must have
+ the value of its MAX-ACCESS clause set to "not-
+ accessible", unless all columnar objects of the
+ conceptual row are used for instance identification, in
+ which case, the MAX-ACCESS clause for one of them must be
+ something other than "not-accessible".
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 4]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ (10) For all objects, if the value of the STATUS clause is
+ "mandatory", the value must be replaced with "current".
+
+ (11) For all objects, if the value of the STATUS clause is
+ "optional", the value must be replaced with "obsolete".
+
+ (12) For any object not containing a DESCRIPTION clause, the
+ object must have a DESCRIPTION clause defined.
+
+ (13) For any object corresponding to a conceptual row which
+ does not have an INDEX clause, the object must have
+ either an INDEX clause or an AUGMENTS clause defined.
+
+ (14) For any object with an INDEX clause that references an
+ object with a syntax of NetworkAddress, the value of the
+ STATUS clause of the both objects is changed to
+ "obsolete".
+
+ (15) For any object containing a DEFVAL clause with an OBJECT
+ IDENTIFIER value which is expressed as a collection of
+ sub-identifiers, change the value to reference a single
+ ASN.1 identifier.
+
+ Other changes are desirable, but not necessary:
+
+ (1) Creation and deletion of conceptual rows is inconsistent
+ using the current framework. The SNMPv2 framework
+ corrects this. As such, if the MIB module undergoes
+ review early in its lifetime, and it contains conceptual
+ tables which allow creation and deletion of conceptual
+ rows, then it may be worthwhile to deprecate the objects
+ relating to those tables and replacing them with objects
+ defined using the new approach.
+
+ (2) For any object with a string-valued SYNTAX clause, in
+ which the corresponding OCTET STRING does not have a size
+ restriction (i.e., the OCTET STRING has no assignment of
+ lower- and upper-bounds on its length), one might
+ consider defining the bounds for the size of the object.
+
+ (3) For all textual conventions informally defined in the MIB
+ module, one might consider redefining those conventions
+ using the TEXTUAL-CONVENTION macro. Such a change would
+ not necessitate deprecating objects previously defined
+ using an informal textual convention.
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 5]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ (4) For any object which represents a measurement in some
+ kind of units, one might consider adding a UNITS clause
+ to the definition of that object.
+
+ (5) For any conceptual row which is an extension of another
+ conceptual row, i.e., for which subordinate columnar
+ objects both exist and are identified via the same
+ semantics as the other conceptual row, one might consider
+ using an AUGMENTS clause in place of the INDEX clause for
+ the object corresponding to the conceptual row which is
+ an extension.
+
+ Finally, when encountering common errors in SNMPv1 MIB
+ modules:
+
+ (1) For any object with a SYNTAX clause value of an
+ enumerated INTEGER, if a named-number enumeration is
+ present with a value of zero, the value of the STATUS
+ clause of that object is changed to "obsolete".
+
+ (2) For any non-columnar object that is instanced as if it
+ were immediately subordinate to a conceptual row, the
+ value of the STATUS clause of that object is changed to
+ "obsolete".
+
+ (3) For any conceptual row object that is not contained
+ immediately subordinate to a conceptual table, the value
+ of the STATUS clause of that object (and all subordinate
+ objects) is changed to "obsolete".
+
+
+ 2.2. Trap Definitions
+
+ If a MIB module is changed to conform to the SNMPv2 framework,
+ then each occurrence of the TRAP-TYPE macro must be changed to
+ a corresponding invocation of the NOTIFICATION-TYPE macro:
+
+ (1) The IMPORTS statement must not reference RFC-1215.
+
+ (2) The ENTERPRISES clause must be removed.
+
+ (3) The VARIABLES clause must be renamed to the OBJECTS
+ clause.
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 6]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ (4) The STATUS clause must be added.
+
+ (5) The value of an invocation of the NOTIFICATION-TYPE macro
+ is an OBJECT IDENTIFIER, not an INTEGER, and must be
+ changed accordingly.
+
+
+ 2.3. Compliance Statements
+
+ For those information modules which are "standard", a
+ corresponding invocation of the MODULE-COMPLIANCE macro must
+ be included within the information module (or in a companion
+ information module), and any commentary text in the
+ information module which relates to compliance must be
+ removed. Typically this editing can occur when the
+ information module undergoes review.
+
+
+ 2.4. Capabilities Statements
+
+ In the current framework, the informational document [9] uses
+ the MODULE-CONFORMANCE macro to describe an agent's
+ capabilities with respect to one or more MIB modules.
+ Converting such a description for use with the SNMPv2
+ framework requires these changes:
+
+ (1) Use the macro name AGENT-CAPABILITIES instead of MODULE-
+ CONFORMANCE.
+
+ (2) The STATUS clause must be added.
+
+ (3) For all occurrences of the CREATION-REQUIRES clause, note
+ the slight change in semantics, and omit this clause if
+ appropriate.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 7]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ 3. Protocol Operations
+
+ The SNMPv2 documents which deal with protocol operations are:
+
+ Protocol Operations for SNMPv2 [10], which defines the
+ syntax and semantics of the operations conveyed by the
+ protocol; and,
+
+ Transport Mappings for SNMPv2 [11], which defines how the
+ protocol operations are carried over different transport
+ services.
+
+ The following section considers two areas: the proxy behavior
+ between a SNMPv2 entity and a SNMPv1 agent; and, the behavior
+ of "bi-lingual" protocol entities acting in a manager role.
+
+
+ 3.1. Proxy Agent Behavior
+
+ To achieve coexistence at the protocol-level, a proxy
+ mechanism may be used. A SNMPv2 entity acting in an agent
+ role may be implemented and configured to act in the role of a
+ proxy agent.
+
+
+ 3.1.1. SNMPv2 -> SNMPv1
+
+ When converting requests from a SNMPv2 entity acting in a
+ manager role into requests sent to a SNMPv1 entity acting in
+ an agent role:
+
+ (1) If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-
+ PDU is received, then it is passed unaltered by the proxy
+ agent.
+
+ (2) If a GetBulkRequest-PDU is received, the proxy agent sets
+ the non-repeaters and max-repetitions fields to zero, and
+ sets the tag of the PDU to GetNextRequest-PDU.
+
+
+ 3.1.2. SNMPv1 -> SNMPv2
+
+ When converting responses received from a SNMPv1 entity acting
+ in an agent role into responses sent to a SNMPv2 entity acting
+ in a manager role:
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 8]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ (1) If a GetResponse-PDU is received, then it is passed
+ unaltered by the proxy agent. Note that even though a
+ SNMPv2 entity will never generate a Response-PDU with a
+ error-status field having a value of `noSuchName',
+ `badValue', or `readOnly', the proxy agent must not
+ change this field. This allows the SNMPv2 entity acting
+ in a manager role to interpret the response correctly.
+
+ If a GetResponse-PDU is received with an error-status
+ field having a value of `tooBig', the proxy agent will
+ remove the contents of the variable-bindings field before
+ propagating the response. Note that even though a SNMPv2
+ entity will never generate a `tooBig' in response to a
+ GetBulkRequestPDU, the proxy agent must propagate such a
+ response.
+
+ (2) If a Trap-PDU is received, then it is mapped into a
+ SNMPv2-Trap-PDU. This is done by prepending onto the
+ variable-bindings field two new bindings: sysUpTime.0
+ [12], which takes its value from the timestamp field of
+ the Trap-PDU; and, snmpTrapOID.0 [13], which is
+ calculated thusly: if the value of generic-trap field is
+ `enterpriseSpecific', then the value used is the
+ concatenation of the enterprise field from the Trap-PDU
+ with two additional sub-identifiers, `0', and the value
+ of the specific-trap field; otherwise, the value of the
+ corresponding trap defined in [13] is used. (For
+ example, if the value of the generic-trap field is
+ `coldStart', then the coldStart trap [13] is used.) Then,
+ one new binding is appended onto the variable-bindings
+ field: snmpTrapEnterpriseOID.0 [13], which takes its
+ value from the enterprise field of the Trap-PDU. To
+ determine the destinations for the SNMPv2-Trap-PDU, the
+ proxy agent applies the procedures defined in Section
+ 4.2.6 of [10], with the exception that no check is made
+ to see if the instances associated with this trap are
+ present in the proxy agent's view.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 9]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ 3.2. Bi-lingual Manager Behavior
+
+ To achieve coexistence at the protocol-level, a protocol
+ entity acting in a manager role might support both SNMPv1 and
+ SNMPv2. When a management application needs to contact a
+ protocol entity acting in an agent role, the entity acting in
+ a manager role consults a local database to select the correct
+ management protocol to use.
+
+ In order to provide transparency to management applications,
+ the entity acting in a manager role must map operations as if
+ it were acting as a proxy agent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 10]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ 4. Acknowledgements
+
+ The comments of the SNMP version 2 working group are
+ gratefully acknowledged:
+
+ Beth Adams, Network Management Forum
+ Steve Alexander, INTERACTIVE Systems Corporation
+ David Arneson, Cabletron Systems
+ Toshiya Asaba
+ Fred Baker, ACC
+ Jim Barnes, Xylogics, Inc.
+ Brian Bataille
+ Andy Bierman, SynOptics Communications, Inc.
+ Uri Blumenthal, IBM Corporation
+ Fred Bohle, Interlink
+ Jack Brown
+ Theodore Brunner, Bellcore
+ Stephen F. Bush, GE Information Services
+ Jeffrey D. Case, University of Tennessee, Knoxville
+ John Chang, IBM Corporation
+ Szusin Chen, Sun Microsystems
+ Robert Ching
+ Chris Chiotasso, Ungermann-Bass
+ Bobby A. Clay, NASA/Boeing
+ John Cooke, Chipcom
+ Tracy Cox, Bellcore
+ Juan Cruz, Datability, Inc.
+ David Cullerot, Cabletron Systems
+ Cathy Cunningham, Microcom
+ James R. (Chuck) Davin, Bellcore
+ Michael Davis, Clearpoint
+ Mike Davison, FiberCom
+ Cynthia DellaTorre, MITRE
+ Taso N. Devetzis, Bellcore
+ Manual Diaz, DAVID Systems, Inc.
+ Jon Dreyer, Sun Microsystems
+ David Engel, Optical Data Systems
+ Mike Erlinger, Lexcel
+ Roger Fajman, NIH
+ Daniel Fauvarque, Sun Microsystems
+ Karen Frisa, CMU
+ Shari Galitzer, MITRE
+ Shawn Gallagher, Digital Equipment Corporation
+ Richard Graveman, Bellcore
+ Maria Greene, Xyplex, Inc.
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 11]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ Michel Guittet, Apple
+ Robert Gutierrez, NASA
+ Bill Hagerty, Cabletron Systems
+ Gary W. Haney, Martin Marietta Energy Systems
+ Patrick Hanil, Nokia Telecommunications
+ Matt Hecht, SNMP Research, Inc.
+ Edward A. Heiner, Jr., Synernetics Inc.
+ Susan E. Hicks, Martin Marietta Energy Systems
+ Geral Holzhauer, Apple
+ John Hopprich, DAVID Systems, Inc.
+ Jeff Hughes, Hewlett-Packard
+ Robin Iddon, Axon Networks, Inc.
+ David Itusak
+ Kevin M. Jackson, Concord Communications, Inc.
+ Ole J. Jacobsen, Interop Company
+ Ronald Jacoby, Silicon Graphics, Inc.
+ Satish Joshi, SynOptics Communications, Inc.
+ Frank Kastenholz, FTP Software
+ Mark Kepke, Hewlett-Packard
+ Ken Key, SNMP Research, Inc.
+ Zbiginew Kielczewski, Eicon
+ Jongyeoi Kim
+ Andrew Knutsen, The Santa Cruz Operation
+ Michael L. Kornegay, VisiSoft
+ Deirdre C. Kostik, Bellcore
+ Cheryl Krupczak, Georgia Tech
+ Mark S. Lewis, Telebit
+ David Lin
+ David Lindemulder, AT&T/NCR
+ Ben Lisowski, Sprint
+ David Liu, Bell-Northern Research
+ John Lunny, The Wollongong Group
+ Robert C. Lushbaugh Martin, Marietta Energy Systems
+ Michael Luufer, BBN
+ Carl Madison, Star-Tek, Inc.
+ Keith McCloghrie, Hughes LAN Systems
+ Evan McGinnis, 3Com Corporation
+ Bill McKenzie, IBM Corporation
+ Donna McMaster, SynOptics Communications, Inc.
+ John Medicke, IBM Corporation
+ Doug Miller, Telebit
+ Dave Minnich, FiberCom
+ Mohammad Mirhakkak, MITRE
+ Rohit Mital, Protools
+ George Mouradian, AT&T Bell Labs
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 12]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ Patrick Mullaney, Cabletron Systems
+ Dan Myers, 3Com Corporation
+ Rina Nathaniel, Rad Network Devices Ltd.
+ Hien V. Nguyen, Sprint
+ Mo Nikain
+ Tom Nisbet
+ William B. Norton, MERIT
+ Steve Onishi, Wellfleet Communications, Inc.
+ David T. Perkins, SynOptics Communications, Inc.
+ Carl Powell, BBN
+ Ilan Raab, SynOptics Communications, Inc.
+ Richard Ramons, AT&T
+ Venkat D. Rangan, Metric Network Systems, Inc.
+ Louise Reingold, Sprint
+ Sam Roberts, Farallon Computing, Inc.
+ Kary Robertson, Concord Communications, Inc.
+ Dan Romascanu, Lannet Data Communications Ltd.
+ Marshall T. Rose, Dover Beach Consulting, Inc.
+ Shawn A. Routhier, Epilogue Technology Corporation
+ Chris Rozman
+ Asaf Rubissa, Fibronics
+ Jon Saperia, Digital Equipment Corporation
+ Michael Sapich
+ Mike Scanlon, Interlan
+ Sam Schaen, MITRE
+ John Seligson, Ultra Network Technologies
+ Paul A. Serice, Corporation for Open Systems
+ Chris Shaw, Banyan Systems
+ Timon Sloane
+ Robert Snyder, Cisco Systems
+ Joo Young Song
+ Roy Spitier, Sprint
+ Einar Stefferud, Network Management Associates
+ John Stephens, Cayman Systems, Inc.
+ Robert L. Stewart, Xyplex, Inc. (chair)
+ Kaj Tesink, Bellcore
+ Dean Throop, Data General
+ Ahmet Tuncay, France Telecom-CNET
+ Maurice Turcotte, Racal Datacom
+ Warren Vik, INTERACTIVE Systems Corporation
+ Yannis Viniotis
+ Steven L. Waldbusser, Carnegie Mellon Universitty
+ Timothy M. Walden, ACC
+ Alice Wang, Sun Microsystems
+ James Watt, Newbridge
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 13]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ Luanne Waul, Timeplex
+ Donald E. Westlake III, Digital Equipment Corporation
+ Gerry White
+ Bert Wijnen, IBM Corporation
+ Peter Wilson, 3Com Corporation
+ Steven Wong, Digital Equipment Corporation
+ Randy Worzella, IBM Corporation
+ Daniel Woycke, MITRE
+ Honda Wu
+ Jeff Yarnell, Protools
+ Chris Young, Cabletron
+ Kiho Yum, 3Com Corporation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 14]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ 5. References
+
+ [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Introduction to version 2 of the Internet-standard
+ Network Management Framework", RFC 1441, SNMP Research,
+ Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
+ Carnegie Mellon University, April 1993.
+
+ [2] Rose, M., and McCloghrie, K., "Structure and
+ Identification of Management Information for TCP/IP-based
+ internets", STD 16, RFC 1155, May 1990.
+
+ [3] Rose, M., and McCloghrie, K., "Concise MIB Definitions",
+ STD 16, RFC 1212, March 1991.
+
+ [4] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple
+ Network Management Protocol", STD 15, RFC 1157, SNMP
+ Research, Performance Systems International, MIT
+ Laboratory for Computer Science, May 1990.
+
+ [5] Information processing systems - Open Systems
+ Interconnection - Specification of Abstract Syntax
+ Notation One (ASN.1), International Organization for
+ Standardization. International Standard 8824, (December,
+ 1987).
+
+ [6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Structure of Management Information for version 2 of the
+ Simple Network Management Protocol (SNMPv2)", RFC 1442,
+ SNMP Research, Inc., Hughes LAN Systems, Dover Beach
+ Consulting, Inc., Carnegie Mellon University, April 1993.
+
+ [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Textual Conventions for version 2 of the the Simple
+ Network Management Protocol (SNMPv2)", RFC 1443, SNMP
+ Research, Inc., Hughes LAN Systems, Dover Beach
+ Consulting, Inc., Carnegie Mellon University, April 1993.
+
+ [8] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Conformance Statements for version 2 of the the Simple
+ Network Management Protocol (SNMPv2)", RFC 1444, SNMP
+ Research, Inc., Hughes LAN Systems, Dover Beach
+ Consulting, Inc., Carnegie Mellon University, April 1993.
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 15]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ [9] McCloghrie, K., and Rose, M., "A Convention for
+ Describing SNMP-based Agents", RFC 1303, Hughes LAN
+ Systems, Dover Beach Consulting, Inc., February 1992.
+
+ [10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Protocol Operations for version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1448, SNMP Research,
+ Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
+ Carnegie Mellon University, April 1993.
+
+ [11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Transport Mappings for version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1449, SNMP Research,
+ Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
+ Carnegie Mellon University, April 1993.
+
+ [12] McCloghrie, K., and Rose, M., "Management Information
+ Base for Network Management of TCP/IP-based internets:
+ MIB-II", STD 17, RFC 1213, March 1991.
+
+ [13] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Management Information Base for version 2 of the Simple
+ Network Management Protocol (SNMPv2)", RFC 1450, SNMP
+ Research, Inc., Hughes LAN Systems, Dover Beach
+ Consulting, Inc., Carnegie Mellon University, April 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 16]
+
+
+
+
+
+ RFC 1452 Coexistence between SNMPv1 and SNMPv2 April 1993
+
+
+ 6. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+ 7. Authors' Addresses
+
+ Jeffrey D. Case
+ SNMP Research, Inc.
+ 3001 Kimberlin Heights Rd.
+ Knoxville, TN 37920-9716
+ US
+
+ Phone: +1 615 573 1434
+ Email: case@snmp.com
+
+
+ Keith McCloghrie
+ Hughes LAN Systems
+ 1225 Charleston Road
+ Mountain View, CA 94043
+ US
+
+ Phone: +1 415 966 7934
+ Email: kzm@hls.com
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Mountain View, CA 94043-2186
+ US
+
+ Phone: +1 415 968 1052
+ Email: mrose@dbc.mtview.ca.us
+
+ Steven Waldbusser
+ Carnegie Mellon University
+ 4910 Forbes Ave
+ Pittsburgh, PA 15213
+ US
+
+ Phone: +1 412 268 6628
+ Email: waldbusser@cmu.edu
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 17]
+