rfc2576.txt

RFC 的详细文档！

   MIB modules defined using the SMIv1 may continue to be used with
   protocol versions which use SNMPv2 PDUs.  However, for the MIB
   modules to conform to the SMIv2, the following changes SHALL be made:

2.1.1.  Object Definitions

   In general, conversion of a MIB module does not require the
   deprecation of the objects contained therein.  If the definition of
   an object is truly inadequate for its intended purpose, the object
   SHALL be deprecated or obsoleted, otherwise deprecation is not
   required.

   (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 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, or have an appropriate range specified.

   (4)  For any object with a SYNTAX clause value of Counter, the object
        MUST have the value of its SYNTAX clause changed to Counter32.

   (5)  For any object with a SYNTAX clause value of Gauge, the object
        MUST have the value of its SYNTAX clause changed to Gauge32, or
        Unsigned32 where appropriate.

   (6)  For all objects, the ACCESS clause MUST be replaced by a MAX-
        ACCESS clause.  The value of the MAX-ACCESS clause SHALL be 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, SHALL have a



Frye, et al.                Standards Track                     [Page 6]

RFC 2576           Coexistence between SNMP versions          March 2000


        MAX-ACCESS clause of "read-create".  If the value of the ACCESS
        clause is "write-only", then the value of the MAX-ACCESS clause
        MUST be "read-write", and the DESCRIPTION clause SHALL note that
        reading this object will result in implementation-specific
        results.  Note that in SMIv1, the ACCESS clause specifies the
        minimal required access, while in SMIv2, the MAX-ACCESS clause
        specifies the maximum allowed access.  This should be considered
        when converting an ACCESS clause to a MAX-ACCESS clause.

   (7)  For all objects, if the value of the STATUS clause is
        "mandatory" or "optional", the value MUST be replaced with
        "current", "deprecated", or "obsolete" depending on the current
        usage of such objects.

   (8)  For any object not containing a DESCRIPTION clause, the object
        MUST have a DESCRIPTION clause defined.

   (9)  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.

   (10) If any INDEX clause contains a reference to an object with a
        syntax of NetworkAddress, then a new object MUST be created and
        placed in this INDEX clause immediately preceding the object
        whose syntax is NetworkAddress.  This new object MUST have a
        syntax of INTEGER, it MUST be not-accessible, and its value MUST
        always be 1.  This approach allows one to convert a MIB module
        in SMIv1 format to one in SMIv2 format, and then use it with the
        SNMPv1 protocol with no impact to existing SNMPv1 agents and
        managers.

   (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST
        be changed to IpAddress.  Note that the use of NetworkAddress in
        new MIB documents is strongly discouraged (in fact, new MIB
        documents should be written using SMIv2, which does not define
        NetworkAddress).

   (12) For any object containing a DEFVAL clause with an OBJECT
        IDENTIFIER value which is expressed as a collection of sub-
        identifiers, the value MUST be changed to reference a single
        ASN.1 identifier.  This may require defining a series of new
        administrative assignments (OBJECT IDENTIFIERS) in order to
        define the single ASN.1 identifier.

   (13) One or more OBJECT-GROUPS MUST be defined, and related objects
        SHOULD be collected into appropriate groups.  Note that SMIv2
        requires all OBJECT-TYPEs to be a member of at least one
        OBJECT-GROUP.



Frye, et al.                Standards Track                     [Page 7]

RFC 2576           Coexistence between SNMP versions          March 2000


   Other changes are desirable, but not necessary:

   (1)  Creation and deletion of conceptual rows is inconsistent using
        the SMIv1.  The SMIv2 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 the objects relating to those tables MAY
        be deprecated and replaced with objects defined using the new
        approach.  The approach based on SMIv2 can be found in section 7
        of RFC2578 [7], and the RowStatus and StorageType TEXTUAL-
        CONVENTIONs are described in section 2 of RFC2579 [8].

   (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), the bounds for the size of the object
        SHOULD be defined.

   (3)  All textual conventions informally defined in the MIB module
        SHOULD be redefined 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, a UNITS clause SHOULD be added 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, an AUGMENTS clause SHOULD be used in place
        of the INDEX clause for the object corresponding to the
        conceptual row which is an extension.

   Finally, to avoid common errors in SMIv1 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 MUST be 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) MUST be
        changed to "obsolete".







Frye, et al.                Standards Track                     [Page 8]

RFC 2576           Coexistence between SNMP versions          March 2000


2.1.2.  Trap and Notification Definitions

   If a MIB module is changed to conform to the SMIv2, 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 [4], and MUST
        reference SNMPv2-SMI instead.

   (2)  The ENTERPRISE clause MUST be removed.

   (3)  The VARIABLES clause MUST be renamed to the OBJECTS clause.

   (4)  A STATUS clause MUST be added, with an appropriate value.
        Normally the value should be 'current,' although 'deprecated' or
        'obsolete' may be used as needed.

   (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 SHALL be
        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.  If the value
        of the ENTERPRISE clause is 'snmp', then the value of the
        invocation of the NOTIFICATION-TYPE macro SHALL be mapped in the
        same manner as described in section 3.1 in this document.

   (6)  A DESCRIPTION clause MUST be added, if not already present.

   (7)  One or more NOTIFICATION-GROUPs MUST be defined, and related
        notifications MUST be collected into those groups.  Note that
        SMIv2 requires that all NOTIFICATION-TYPEs be a member of at
        least one NOTIFICATION-GROUP.

2.2.  Compliance Statements

   For those information modules which are "standards track", a
   corresponding invocation of the MODULE-COMPLIANCE macro and related
   OBJECT-GROUP and/or NOTIFICATION-GROUP macros 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 SHOULD be removed.  Typically this editing can occur when
   the information module undergoes review.







Frye, et al.                Standards Track                     [Page 9]

RFC 2576           Coexistence between SNMP versions          March 2000


   Note that a MODULE-COMPLIANCE statement is not required for a MIB
   document that is not on the standards track (for example, an
   enterprise MIB), though it may be useful in some circumstances to
   define a MODULE-COMPLIANCE statement for such a MIB document.

2.3.  Capabilities Statements

   RFC1303 [5] 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 SMIv2 requires these changes:

   (1)  The macro name AGENT-CAPABILITIES SHOULD be used instead of
        MODULE-CONFORMANCE.

   (2)  The STATUS clause SHOULD be added, with a value of 'current'.

   (3)  All occurrences of the CREATION-REQUIRES clause MUST either be
        omitted if appropriate, or be changed such that the semantics
        are consistent with RFC2580 [9].

   In order to ease coexistence, object groups defined in an SMIv1
   compliant 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 SMIv1 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 an
   SMIv1 MIB have different sets of mandatory objects under the same
   subtree; in such cases, the only solution is to rewrite the MIB using
   the SMIv2 in order to define the object groups unambiguously.)

3.  Translating Notifications Parameters

   This section describes how parameters used for generating
   notifications are translated between the format used for SNMPv1
   notification protocol operations and the format used for SNMPv2
   notification protocol operations.  The parameters used to generate a
   notification are called 'notification parameters'.  The format of
   parameters used for SNMPv1 notification protocol operations is
   refered to in this document as 'SNMPv1 notification parameters'.  The
   format of parameters used for SNMPv2 notification protocol operations
   is refered to in this document as 'SNMPv2 notification parameters'.









Frye, et al.                Standards Track                    [Page 10]

RFC 2576           Coexistence between SNMP versions          March 2000


   The situations where notification parameters MUST be translated are:

      -  When an entity generates a set of notification parameters in a
         particular format, and the configuration of the entity
         indicates that the notification must be sent using an SNMP
         message version that requires the other format for notification
         parameters.

      -  When a proxy receives a notification that was sent using an
         SNMP message version that requires one format of notification
         parameters, and must forward the notification using an SNMP
         message version that requires the other format of notification
         parameters.

   In addition, it MAY be desirable to translate notification parameters
   in a notification receiver application in order to present
   notifications to the end user in a consistent format.

   Note that for the purposes of this section, the set of notification
   parameters is independent of whether the notification is to be sent
   as a trap or an inform.

   SNMPv1 notification parameters consist of:

      -  An enterprise parameter (OBJECT IDENTIFIER).