rfc1452.txt

RFC 的详细文档！

          Network Working Group                                  J. Case
          Request for Comments: 1452                 SNMP Research, Inc.
                                                           K. McCloghrie
                                                      Hughes LAN Systems
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                              Carnegie Mellon University
                                                              April 1993


                Coexistence between version 1 and version 2 of the
                  Internet-standard Network Management Framework


          Status of this Memo

          This RFC specifes an IAB standards track protocol for the
          Internet community, and requests discussion and suggestions
          for improvements.  Please refer to the current edition of the
          "IAB Official Protocol Standards" for the standardization
          state and status of this protocol.  Distribution of this memo
          is unlimited.


          Table of Contents


          1 Introduction ..........................................    2
          2 Management Information ................................    3
          2.1 Object Definitions ..................................    3
          2.2 Trap Definitions ....................................    6
          2.3 Compliance Statements ...............................    7
          2.4 Capabilities Statements .............................    7
          3 Protocol Operations ...................................    8
          3.1 Proxy Agent Behavior ................................    8
          3.1.1 SNMPv2 -> SNMPv1 ..................................    8
          3.1.2 SNMPv1 -> SNMPv2 ..................................    8
          3.2 Bi-lingual Manager Behavior .........................   10
          4 Acknowledgements ......................................   11
          5 References ............................................   15
          6 Security Considerations ...............................   17
          7 Authors' Addresses ....................................   17











          Case, McCloghrie, Rose & Waldbusser                   [Page 1]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


          1.  Introduction

          The purpose of this document is to describe coexistence
          between version 2 of the Internet-standard Network Management
          Framework, termed the SNMP version 2 framework (SNMPv2) [1],
          and the original Internet-standard Network Management
          Framework (SNMPv1), which consists of these three documents:

               RFC 1155 [2] which defines the Structure of Management
               Information (SMI), the mechanisms used for describing and
               naming objects for the purpose of management.

               RFC 1212 [3] which defines a more concise description
               mechanism, which is wholly consistent with the SMI.

               RFC 1157 [4] which defines the Simple Network Management
               Protocol (SNMP), the protocol used for network access to
               managed objects.
































          Case, McCloghrie, Rose & Waldbusser                   [Page 2]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


          2.  Management Information

          The SNMPv2 approach towards describing collections of managed
          objects is nearly a proper superset of the approach defined in
          the Internet-standard Network Management Framework.  For
          example, both approaches use ASN.1 [5] as the basis for a
          formal descriptive notation.  Indeed, one might note that the
          SNMPv2 approach largely codifies the existing practice for
          defining MIB modules, based on extensive experience with the
          current framework.

          The SNMPv2 documents which deal with information modules are:

               Structure of Management Information for SNMPv2 [6], which
               defines concise notations for describing information
               modules, managed objects and notifications;

               Textual Conventions for SNMPv2 [7], which defines a
               concise notation for describing textual conventions, and
               also defines some initial conventions; and,

               Conformance Statements for SNMPv2 [8], which defines
               concise notation for describing compliance and
               capabilities statements.

          The following sections consider the three areas: MIB modules,
          compliance statements, and capabilities statements.

          MIB modules defined using the current framework may continue
          to be used with the SNMPv2 protocol.  However, for the MIB
          modules to conform to the SNMPv2 framework, the following
          changes are required:


          2.1.  Object Definitions

          In general, conversion of a MIB module does not require the
          deprecation of the objects contained therein.  Only if the
          semantics of an object truly changes should deprecation be
          performed.

          (1)  The IMPORTS statement must reference SNMPv2-SMI, instead
               of RFC1155-SMI and RFC-1212.







          Case, McCloghrie, Rose & Waldbusser                   [Page 3]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


          (2)  The MODULE-IDENTITY macro must be invoked immediately
               after any IMPORTs or EXPORTs statement.

          (3)  For any descriptor which contains the hyphen character,
               the hyphen character is removed.

          (4)  For any object with an integer-valued SYNTAX clause, in
               which the corresponding INTEGER does not have a range
               restriction (i.e., the INTEGER has neither a defined set
               of named-number enumerations nor an assignment of lower-
               and upper-bounds on its value), the object must have the
               value of its SYNTAX clause changed to Integer32.

          (5)  For any object with a SYNTAX clause value of an
               enumerated INTEGER, the hyphen character is removed from
               any named-number labels which contain the hyphen
               character.

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

          (7)  For any object with a SYNTAX clause value of Gauge, the
               object must have the value of its SYNTAX clause changed
               to Gauge32.

          (8)  For all objects, the ACCESS clause must be replaced by a
               MAX-ACCESS clause.  The value of the MAX-ACCESS clause is
               the same as that of the ACCESS clause unless some other
               value makes "protocol sense" as the maximal level of
               access for the object.  In particular, object types for
               which instances can be explicitly created by a protocol
               set operation, will have a MAX-ACCESS clause of "read-
               create".  If the value of the ACCESS clause is "write-
               only", then the value of the MAX-ACCESS clause is "read-
               write", and the DESCRIPTION clause notes that reading
               this object will result implementation-specific results.

          (9)  For any columnar object which is used solely for instance
               identification in a conceptual row, the object must have
               the value of its MAX-ACCESS clause set to "not-
               accessible", unless all columnar objects of the
               conceptual row are used for instance identification, in
               which case, the MAX-ACCESS clause for one of them must be
               something other than "not-accessible".





          Case, McCloghrie, Rose & Waldbusser                   [Page 4]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


          (10) For all objects, if the value of the STATUS clause is
               "mandatory", the value must be replaced with "current".

          (11) For all objects, if the value of the STATUS clause is
               "optional", the value must be replaced with "obsolete".

          (12) For any object not containing a DESCRIPTION clause, the
               object must have a DESCRIPTION clause defined.

          (13) For any object corresponding to a conceptual row which
               does not have an INDEX clause, the object must have
               either an INDEX clause or an AUGMENTS clause defined.

          (14) For any object with an INDEX clause that references an
               object with a syntax of NetworkAddress, the value of the
               STATUS clause of the both objects is changed to
               "obsolete".

          (15) For any object containing a DEFVAL clause with an OBJECT
               IDENTIFIER value which is expressed as a collection of
               sub-identifiers, change the value to reference a single
               ASN.1 identifier.

          Other changes are desirable, but not necessary:

          (1)  Creation and deletion of conceptual rows is inconsistent
               using the current framework.  The SNMPv2 framework
               corrects this.  As such, if the MIB module undergoes
               review early in its lifetime, and it contains conceptual
               tables which allow creation and deletion of conceptual
               rows, then it may be worthwhile to deprecate the objects
               relating to those tables and replacing them with objects
               defined using the new approach.

          (2)  For any object with a string-valued SYNTAX clause, in
               which the corresponding OCTET STRING does not have a size
               restriction (i.e., the OCTET STRING has no assignment of
               lower- and upper-bounds on its length), one might
               consider defining the bounds for the size of the object.

          (3)  For all textual conventions informally defined in the MIB
               module, one might consider redefining those conventions
               using the TEXTUAL-CONVENTION macro.  Such a change would
               not necessitate deprecating objects previously defined
               using an informal textual convention.





          Case, McCloghrie, Rose & Waldbusser                   [Page 5]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


          (4)  For any object which represents a measurement in some
               kind of units, one might consider adding a UNITS clause
               to the definition of that object.

          (5)  For any conceptual row which is an extension of another
               conceptual row, i.e., for which subordinate columnar
               objects both exist and are identified via the same
               semantics as the other conceptual row, one might consider
               using an AUGMENTS clause in place of the INDEX clause for
               the object corresponding to the conceptual row which is
               an extension.

          Finally, when encountering common errors in SNMPv1 MIB
          modules:

          (1)  For any object with a SYNTAX clause value of an
               enumerated INTEGER, if a named-number enumeration is
               present with a value of zero, the value of the STATUS
               clause of that object is changed to "obsolete".

          (2)  For any non-columnar object that is instanced as if it
               were immediately subordinate to a conceptual row, the
               value of the STATUS clause of that object is changed to
               "obsolete".

          (3)  For any conceptual row object that is not contained
               immediately subordinate to a conceptual table, the value
               of the STATUS clause of that object (and all subordinate
               objects) is changed to "obsolete".


          2.2.  Trap Definitions