net-snmp 1.2.1 → 1.2.5

package/ref/rfc/v2c/rfc1908.txt

@@ -1,563 +1,563 @@
-
-
-
-
-
-
-Network Working Group                               SNMPv2 Working Group
-Request for Comments: 1908                                       J. Case
-Obsoletes: 1452                                      SNMP Research, Inc.
-Category: Standards Track                                  K. McCloghrie
-                                                     Cisco Systems, Inc.
-                                                                 M. Rose
-                                            Dover Beach Consulting, Inc.
-                                                           S. Waldbusser
-                                          International Network Services
-                                                            January 1996
-
-
-           Coexistence between Version 1 and Version 2 of the
-             Internet-standard Network Management Framework
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Table of Contents
-
-   1. Introduction ................................................    2
-   2. Management Information ......................................    2
-   2.1 Object Definitions .........................................    3
-   2.2 Trap Definitions ...........................................    5
-   2.3 Compliance Statements ......................................    5
-   2.4 Capabilities Statements ....................................    6
-   3 Protocol Operations ..........................................    6
-   3.1 Proxy Agent Behavior .......................................    6
-   3.1.1 SNMPv2 -> SNMPv1 .........................................    7
-   3.1.2 SNMPv1 -> SNMPv2 .........................................    7
-   3.2 Bi-lingual Manager Behavior ................................    8
-   4. Security Considerations .....................................    8
-   5. Editor's Address ............................................    8
-   6. Acknowledgements ............................................    8
-   7. References ..................................................    9
-
-
-
-
-
-
-
-
-
-
-
-SNMPv2 Working Group        Standards Track                     [Page 1]
-
-RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
-
-
-1.  Introduction
-
-   The purpose of this document is to describe coexistence between
-   version 2 of the Internet-standard Network Management Framework [1-
-   6], termed the SNMP version 2 framework (SNMPv2), and the original
-   Internet-standard Network Management Framework (SNMPv1), which
-   consists of these three documents:
-
-      STD 16, RFC 1155 [7] which defines the Structure of Management
-      Information (SMI), the mechanisms used for describing and naming
-      objects for the purpose of management.
-
-      STD 16, RFC 1212 [8] which defines a more concise description
-      mechanism, which is wholly consistent with the SMI.
-
-      STD 15, RFC 1157 [9] which defines the Simple Network Management
-      Protocol (SNMP), the protocol used for network access to managed
-      objects.
-
-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 [10] 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 [1], which defines
-     concise notations for describing information modules, managed
-     objects and notifications;
-
-     Textual Conventions for SNMPv2 [2], which defines a concise
-     notation for describing textual conventions, and also defines some
-     initial conventions; and,
-
-     Conformance Statements for SNMPv2 [3], 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:
-
-
-
-SNMPv2 Working Group        Standards Track                     [Page 2]
-
-RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
-
-
-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.
-
-(2)  The MODULE-IDENTITY macro must be invoked immediately after any
-     IMPORTs statement.
-
-(3)  For any descriptor which contains the hyphen character, the hyphen
-     character is removed.
-
-(4)  For any label for a named-number enumeration which contains the
-     hyphen character, the hyphen character is removed.
-
-(5)  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.
-
-(6)  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.
-
-(7)  For any object with a SYNTAX clause value of Counter, the object
-     must have the value of its SYNTAX clause changed to Counter32.
-
-(8)  For any object with a SYNTAX clause value of Gauge, the object must
-     have the value of its SYNTAX clause changed to Gauge32.
-
-(9)  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.
-
-(10) For all objects, if the value of the STATUS clause is "mandatory",
-     the value must be replaced with "current".
-
-
-
-
-SNMPv2 Working Group        Standards Track                     [Page 3]
-
-RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
-
-
-(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 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 replace 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.
-
-(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
-
-
-
-SNMPv2 Working Group        Standards Track                     [Page 4]
-
-RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
-
-
-     an extension.
-
-Finally, when encountering common errors in SNMPv1 MIB modules:
-
-(1)  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".
-
-(2)  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.
-
-   (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.
-        Specifically, if the value of the ENTERPRISE clause is not 'snmp'
-        then the value of the invocation is the value of the ENTERPRISE
-        clause extended with two sub-identifiers, the first of which has
-        the value 0, and the second has the value of the invocation of the
-        TRAP-TYPE.
-
-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.
-
-
-
-
-
-
-
-
-SNMPv2 Working Group        Standards Track                     [Page 5]
-
-RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
-
-
-2.4.  Capabilities Statements
-
-   In the current framework, the informational document [11] 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.
-
-   In order to ease the coexistence between SNMPv1 and SNMPv2, object
-   groups defined in an SNMPv1 MIB module may be referenced by the
-   INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro:
-   upon encountering a reference to an OBJECT IDENTIFIER subtree defined
-   in an SNMPv1 MIB module, all leaf objects which are subordinate to
-   the subtree and have a STATUS clause value of mandatory are deemed to
-   be INCLUDEd.  (Note that this method is ambiguous when different
-   revisions of a SNMPv1 MIB have different sets of mandatory objects
-   under the same subtree; in such cases, the only solution is to
-   rewrite the MIB using the SNMPv2 SMI in order to define the object
-   groups unambiguously.)
-
-3.  Protocol Operations
-
-   The SNMPv2 documents which deal with protocol operations are:
-
-     Protocol Operations for SNMPv2 [4], which defines the syntax and
-     semantics of the operations conveyed by the protocol; and,
-
-     Transport Mappings for SNMPv2 [5], 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.
-
-
-
-
-
-SNMPv2 Working Group        Standards Track                     [Page 6]
-
-RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
-
-
-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:
-
-(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 GetBulkRequest-PDU, 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 [6], which takes its value from the
-     timestamp field of the Trap-PDU; and, snmpTrapOID.0 [6], 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 [6] is
-     used.  (For example, if the value of the generic-trap field is
-     `coldStart', then the coldStart trap [6] is used.)  Then, one new
-     binding is appended onto the variable-bindings field:
-     snmpTrapEnterprise.0 [6], which takes its value from the enterprise
-     field of the Trap-PDU.  The destinations for the SNMPv2-Trap-PDU
-     are determined in an implementation-dependent fashion by the proxy
-     agent.
-
-
-
-SNMPv2 Working Group        Standards Track                     [Page 7]
-
-RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
-
-
-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.
-
-4.  Security Considerations
-
-   Security issues are not discussed in this memo.
-
-5.  Editor's Address
-
-   Keith McCloghrie
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA  95134-1706
-   US
-
-   Phone: +1 408 526 5260
-   EMail: kzm@cisco.com
-
-6.  Acknowledgements
-
-   This document is the result of significant work by the four major
-   contributors:
-
-   Jeffrey D. Case (SNMP Research, case@snmp.com)
-   Keith McCloghrie (Cisco Systems, kzm@cisco.com)
-   Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
-   Steven Waldbusser (International Network Services, stevew@uni.ins.com)
-
-   In addition, the contributions of the SNMPv2 Working Group are
-   acknowledged.  In particular, a special thanks is extended for the
-   contributions of:
-
-     Alexander I. Alten (Novell)
-     Dave Arneson (Cabletron)
-     Uri Blumenthal (IBM)
-     Doug Book (Chipcom)
-     Kim Curran (Bell-Northern Research)
-     Jim Galvin (Trusted Information Systems)
-     Maria Greene (Ascom Timeplex)
-
-
-
-SNMPv2 Working Group        Standards Track                     [Page 8]
-
-RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
-
-
-     Iain Hanson (Digital)
-     Dave Harrington (Cabletron)
-     Nguyen Hien (IBM)
-     Jeff Johnson (Cisco Systems)
-     Michael Kornegay (Object Quest)
-     Deirdre Kostick (AT&T Bell Labs)
-     David Levi (SNMP Research)
-     Daniel Mahoney (Cabletron)
-     Bob Natale (ACE*COMM)
-     Brian O'Keefe (Hewlett Packard)
-     Andrew Pearson (SNMP Research)
-     Dave Perkins (Peer Networks)
-     Randy Presuhn (Peer Networks)
-     Aleksey Romanov (Quality Quorum)
-     Shawn Routhier (Epilogue)
-     Jon Saperia (BGS Systems)
-     Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
-     Kaj Tesink (Bellcore)
-     Glenn Waters (Bell-Northern Research)
-     Bert Wijnen (IBM)
-
-7.  References
-
-[1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
-     S. Waldbusser, "Structure of Management Information for Version 2
-     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
-     January 1996.
-
-[2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
-     S. Waldbusser, "Textual Conventions for Version 2 of the Simple
-     Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
-
-[3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
-     S. Waldbusser, "Conformance Statements for Version 2 of the Simple
-     Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
-
-[4]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
-     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
-     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
-
-[5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
-     S. Waldbusser, "Transport Mappings for Version 2 of the Simple
-     Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
-
-[6]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
-     S. Waldbusser, "Management Information Base for Version 2 of the
-     Simple Network Management Protocol (SNMPv2)", RFC 1907,
-     January 1996.
-
-
-
-SNMPv2 Working Group        Standards Track                     [Page 9]
-
-RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
-
-
-[7]  Rose, M., and K. McCloghrie, "Structure and Identification of
-     Management Information for TCP/IP-based internets", STD 16, RFC
-     1155, May 1990.
-
-[8]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
-     RFC 1212, March 1991.
-
-[9]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
-     Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
-     Systems International, MIT Laboratory for Computer Science, May
-     1990.
-
-[10] Information processing systems - Open Systems Interconnection -
-     Specification of Abstract Syntax Notation One (ASN.1),
-     International Organization for Standardization.  International
-     Standard 8824, (December, 1987).
-
-[11] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP-
-     based Agents", RFC 1303, Hughes LAN Systems, Dover Beach
-     Consulting, Inc., February 1992.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-SNMPv2 Working Group        Standards Track                    [Page 10]
-
+
+
+
+
+
+
+Network Working Group                               SNMPv2 Working Group
+Request for Comments: 1908                                       J. Case
+Obsoletes: 1452                                      SNMP Research, Inc.
+Category: Standards Track                                  K. McCloghrie
+                                                     Cisco Systems, Inc.
+                                                                 M. Rose
+                                            Dover Beach Consulting, Inc.
+                                                           S. Waldbusser
+                                          International Network Services
+                                                            January 1996
+
+
+           Coexistence between Version 1 and Version 2 of the
+             Internet-standard Network Management Framework
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Table of Contents
+
+   1. Introduction ................................................    2
+   2. Management Information ......................................    2
+   2.1 Object Definitions .........................................    3
+   2.2 Trap Definitions ...........................................    5
+   2.3 Compliance Statements ......................................    5
+   2.4 Capabilities Statements ....................................    6
+   3 Protocol Operations ..........................................    6
+   3.1 Proxy Agent Behavior .......................................    6
+   3.1.1 SNMPv2 -> SNMPv1 .........................................    7
+   3.1.2 SNMPv1 -> SNMPv2 .........................................    7
+   3.2 Bi-lingual Manager Behavior ................................    8
+   4. Security Considerations .....................................    8
+   5. Editor's Address ............................................    8
+   6. Acknowledgements ............................................    8
+   7. References ..................................................    9
+
+
+
+
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 1]
+
+RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
+
+
+1.  Introduction
+
+   The purpose of this document is to describe coexistence between
+   version 2 of the Internet-standard Network Management Framework [1-
+   6], termed the SNMP version 2 framework (SNMPv2), and the original
+   Internet-standard Network Management Framework (SNMPv1), which
+   consists of these three documents:
+
+      STD 16, RFC 1155 [7] which defines the Structure of Management
+      Information (SMI), the mechanisms used for describing and naming
+      objects for the purpose of management.
+
+      STD 16, RFC 1212 [8] which defines a more concise description
+      mechanism, which is wholly consistent with the SMI.
+
+      STD 15, RFC 1157 [9] which defines the Simple Network Management
+      Protocol (SNMP), the protocol used for network access to managed
+      objects.
+
+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 [10] 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 [1], which defines
+     concise notations for describing information modules, managed
+     objects and notifications;
+
+     Textual Conventions for SNMPv2 [2], which defines a concise
+     notation for describing textual conventions, and also defines some
+     initial conventions; and,
+
+     Conformance Statements for SNMPv2 [3], 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:
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 2]
+
+RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
+
+
+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.
+
+(2)  The MODULE-IDENTITY macro must be invoked immediately after any
+     IMPORTs statement.
+
+(3)  For any descriptor which contains the hyphen character, the hyphen
+     character is removed.
+
+(4)  For any label for a named-number enumeration which contains the
+     hyphen character, the hyphen character is removed.
+
+(5)  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.
+
+(6)  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.
+
+(7)  For any object with a SYNTAX clause value of Counter, the object
+     must have the value of its SYNTAX clause changed to Counter32.
+
+(8)  For any object with a SYNTAX clause value of Gauge, the object must
+     have the value of its SYNTAX clause changed to Gauge32.
+
+(9)  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.
+
+(10) For all objects, if the value of the STATUS clause is "mandatory",
+     the value must be replaced with "current".
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 3]
+
+RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
+
+
+(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 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 replace 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.
+
+(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
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 4]
+
+RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
+
+
+     an extension.
+
+Finally, when encountering common errors in SNMPv1 MIB modules:
+
+(1)  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".
+
+(2)  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.
+
+   (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.
+        Specifically, if the value of the ENTERPRISE clause is not 'snmp'
+        then the value of the invocation is the value of the ENTERPRISE
+        clause extended with two sub-identifiers, the first of which has
+        the value 0, and the second has the value of the invocation of the
+        TRAP-TYPE.
+
+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.
+
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 5]
+
+RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
+
+
+2.4.  Capabilities Statements
+
+   In the current framework, the informational document [11] 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.
+
+   In order to ease the coexistence between SNMPv1 and SNMPv2, object
+   groups defined in an SNMPv1 MIB module may be referenced by the
+   INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro:
+   upon encountering a reference to an OBJECT IDENTIFIER subtree defined
+   in an SNMPv1 MIB module, all leaf objects which are subordinate to
+   the subtree and have a STATUS clause value of mandatory are deemed to
+   be INCLUDEd.  (Note that this method is ambiguous when different
+   revisions of a SNMPv1 MIB have different sets of mandatory objects
+   under the same subtree; in such cases, the only solution is to
+   rewrite the MIB using the SNMPv2 SMI in order to define the object
+   groups unambiguously.)
+
+3.  Protocol Operations
+
+   The SNMPv2 documents which deal with protocol operations are:
+
+     Protocol Operations for SNMPv2 [4], which defines the syntax and
+     semantics of the operations conveyed by the protocol; and,
+
+     Transport Mappings for SNMPv2 [5], 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.
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 6]
+
+RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
+
+
+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:
+
+(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 GetBulkRequest-PDU, 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 [6], which takes its value from the
+     timestamp field of the Trap-PDU; and, snmpTrapOID.0 [6], 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 [6] is
+     used.  (For example, if the value of the generic-trap field is
+     `coldStart', then the coldStart trap [6] is used.)  Then, one new
+     binding is appended onto the variable-bindings field:
+     snmpTrapEnterprise.0 [6], which takes its value from the enterprise
+     field of the Trap-PDU.  The destinations for the SNMPv2-Trap-PDU
+     are determined in an implementation-dependent fashion by the proxy
+     agent.
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 7]
+
+RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
+
+
+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.
+
+4.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+5.  Editor's Address
+
+   Keith McCloghrie
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA  95134-1706
+   US
+
+   Phone: +1 408 526 5260
+   EMail: kzm@cisco.com
+
+6.  Acknowledgements
+
+   This document is the result of significant work by the four major
+   contributors:
+
+   Jeffrey D. Case (SNMP Research, case@snmp.com)
+   Keith McCloghrie (Cisco Systems, kzm@cisco.com)
+   Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
+   Steven Waldbusser (International Network Services, stevew@uni.ins.com)
+
+   In addition, the contributions of the SNMPv2 Working Group are
+   acknowledged.  In particular, a special thanks is extended for the
+   contributions of:
+
+     Alexander I. Alten (Novell)
+     Dave Arneson (Cabletron)
+     Uri Blumenthal (IBM)
+     Doug Book (Chipcom)
+     Kim Curran (Bell-Northern Research)
+     Jim Galvin (Trusted Information Systems)
+     Maria Greene (Ascom Timeplex)
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 8]
+
+RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
+
+
+     Iain Hanson (Digital)
+     Dave Harrington (Cabletron)
+     Nguyen Hien (IBM)
+     Jeff Johnson (Cisco Systems)
+     Michael Kornegay (Object Quest)
+     Deirdre Kostick (AT&T Bell Labs)
+     David Levi (SNMP Research)
+     Daniel Mahoney (Cabletron)
+     Bob Natale (ACE*COMM)
+     Brian O'Keefe (Hewlett Packard)
+     Andrew Pearson (SNMP Research)
+     Dave Perkins (Peer Networks)
+     Randy Presuhn (Peer Networks)
+     Aleksey Romanov (Quality Quorum)
+     Shawn Routhier (Epilogue)
+     Jon Saperia (BGS Systems)
+     Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
+     Kaj Tesink (Bellcore)
+     Glenn Waters (Bell-Northern Research)
+     Bert Wijnen (IBM)
+
+7.  References
+
+[1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Structure of Management Information for Version 2
+     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
+     January 1996.
+
+[2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Textual Conventions for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
+
+[3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Conformance Statements for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
+
+[4]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+[5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Transport Mappings for Version 2 of the Simple
+     Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+[6]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
+     S. Waldbusser, "Management Information Base for Version 2 of the
+     Simple Network Management Protocol (SNMPv2)", RFC 1907,
+     January 1996.
+
+
+
+SNMPv2 Working Group        Standards Track                     [Page 9]
+
+RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996
+
+
+[7]  Rose, M., and K. McCloghrie, "Structure and Identification of
+     Management Information for TCP/IP-based internets", STD 16, RFC
+     1155, May 1990.
+
+[8]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
+     RFC 1212, March 1991.
+
+[9]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
+     Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
+     Systems International, MIT Laboratory for Computer Science, May
+     1990.
+
+[10] Information processing systems - Open Systems Interconnection -
+     Specification of Abstract Syntax Notation One (ASN.1),
+     International Organization for Standardization.  International
+     Standard 8824, (December, 1987).
+
+[11] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP-
+     based Agents", RFC 1303, Hughes LAN Systems, Dover Beach
+     Consulting, Inc., February 1992.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+SNMPv2 Working Group        Standards Track                    [Page 10]
+