From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1452.txt | 1003 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1003 insertions(+) create mode 100644 doc/rfc/rfc1452.txt (limited to 'doc/rfc/rfc1452.txt') 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] + -- cgit v1.2.3