path: root/doc/rfc/rfc1452.txt

          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L




          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]
^L