rfc1908.txt

开发snmp的开发包有两个开放的SNMP开发库

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]