rfc3512.txt

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

   passed.




MacFaden, et al.             Informational                     [Page 21]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   One drawback to TimeFilter index tables is that a given row can
   appear at many points in time, which artificially inflates the size
   of the table when performing standard getNext or getBulk data
   retrieval.

3.3.6.3.  Alternate Data Delivery Mechanisms

   If the amount of data to transfer is larger than current SNMP design
   restrictions permit, as in the case of OCTET STRINGS (64k minus
   overhead of IP/UDP header plus SNMP header plus varbind list plus
   varbind encoding), consider delivery of the data via an alternate
   method, such as FTP and use a MIB module to control that data
   delivery process.  In many cases, this problem can be avoided via
   effective MIB design.  In other words, object types requiring this
   kind of transfer size should be used judiciously, if at all.

   There are many enterprise MIB modules that provide control of the
   TFTP or FTP protocol.  Often the SNMP part defines what to send where
   and setting an object initiates the operation (for an example, refer
   to the CISCO-FTP-CLIENT-MIB, discussed in [38]).

   Various approaches exist for allowing a local agent process running
   within the managed node to take a template for an object instance
   (for example for a set of interfaces), and adapt and apply it to all
   of the actual instances within the node.  This is an architecture for
   one form of policy-based configuration (see [36], for example).  Such
   an architecture, which must be designed into the agent and some
   portions of the MIB module, affords the efficiency of specifying many
   copies of instance data only once, along with the execution
   efficiency of distributing the application of the instance data to
   the agent.

   Other work is currently underway to improve efficiency for bulk SNMP
   transfer operations [37].  The objective of these efforts is simply
   the conveyance of more information with less overhead.

3.4.  More Index Design Issues

   Section 3.3.5 described considerations for table row index design as
   it pertains to the synchronization of changes within sizable table
   rows. This section simply considers how to specify this syntactically
   and how to manage indices semantically.

   In many respects, the design issues associated with indices in a MIB
   module are similar to those in a database.  Care must be taken during
   the design phase to determine how often and what kind of information
   must be set or retrieved.  The next few points provide some guidance.




MacFaden, et al.             Informational                     [Page 22]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


3.4.1.  Simple Integer Indexing

   When indexing tables using simple Integer32 or Unsigned32, start with
   one (1) and specify the maximum range of the value.  Since object
   identifiers are unsigned long values, a question that arises is why
   not index from zero (0) instead of one(1)?

   RFC 2578 [2], Section 7.7, page 28 states the following: Instances
   identified by use of integer-valued objects should be numbered
   starting from one (i.e., not from zero).  The use of zero as a value
   for an integer-valued index object type should be avoided, except in
   special cases.  Consider the provisions afforded by the following
   textual convention from the Interfaces Group MIB module [33]:

   InterfaceIndexOrZero ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "d"
       STATUS       current
       DESCRIPTION
           "This textual convention is an extension of the
           InterfaceIndex convention.  The latter defines a greater
           than zero value used to identify an interface or interface
           sub-layer in the managed system.  This extension permits the
           additional value of zero.  the value zero is object-specific
           and must therefore be defined as part of the description of
           any object which uses this syntax.  Examples of the usage of
           zero might include situations where interface was unknown,
           or when none or all interfaces need to be referenced."
       SYNTAX       Integer32 (0..2147483647)

3.4.2.  Indexing with Network Addresses

   There are many objects that use IPv4 addresses (SYNTAX IpAddress) as
   indexes.  One such table is the ipAddrTable from RFC 2011 [14] IP-
   MIB.  This limits the usefulness of the MIB module to IPv4.  To avoid
   such limitations, use the addressing textual conventions INET-
   ADDRESS-MIB [13] (or updates to that MIB module), which provides a
   generic way to represent addresses for Internet Protocols.  In using
   the InetAddress textual convention in this MIB, however, pay heed to
   the following advisory found in its description clause:

      When this textual convention is used as the syntax of an index
      object, there may be issues with the limit of 128 sub-identifiers
      specified in SMIv2, STD 58.  In this case, the OBJECT-TYPE
      declaration MUST include a 'SIZE' clause to limit the number of
      potential instance sub-identifiers.






MacFaden, et al.             Informational                     [Page 23]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   One should consider the SMI limitation on the 128 sub-identifier
   specification when using certain kinds of network address index
   types.  The most likely practical liability encountered in practice
   has been with DNS names, which can in fact be in excess of 128 bytes.
   The problem can be, of course, compounded when multiple indices of
   this type are specified for a table.

3.5.  Conflicting Controls

   MIB module designers should avoid specifying read-write objects that
   overlap in function partly or completely.

   Consider the following situation where two read-write objects
   partially overlap when a dot1dBasePortEntry has a corresponding
   ifEntry.

   The BRIDGE-MIB defines the following managed object:

   dot1dStpPortEnable OBJECT-TYPE
       SYNTAX  INTEGER {
                   enabled(1),
                   disabled(2)            }
       ACCESS  read-write
       STATUS  mandatory
       DESCRIPTION
           "The enabled/disabled status of the port."
       REFERENCE
           "IEEE 802.1D-1990: Section 4.5.5.2"
       ::= { dot1dStpPortEntry 4 }

   The IF-MIB defines a similar managed object:

   ifAdminStatus OBJECT-TYPE
       SYNTAX  INTEGER {
                   up(1),       -- ready to pass packets
                   down(2),
                   testing(3)   -- in some test mode
               }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The desired state of the interface.  The testing(3)
           state indicates that no operational packets can be
           passed.  When a managed system initializes, all
           interfaces start with ifAdminStatus in the down(2) state.
           As a result of either explicit management action or per
           configuration information retained by the managed system,
           ifAdminStatus is then changed to either the up(1) or



MacFaden, et al.             Informational                     [Page 24]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


           testing(3) states (or remains in the down(2) state)."
       ::= { ifEntry 7 }

   If ifAdminStatus is set to testing(3), the value to be returned for
   dot1dStpPortEnable is not defined.  Without clarification on how
   these two objects interact, management implementations will have to
   monitor both objects if bridging is detected and correlate behavior.

   The dot1dStpPortEnable object type could have been written with more
   information about the behavior of this object when values of
   ifAdminStatus which impact it change.  For example, text could be
   added that described proper return values for the dot1dStpPortEnable
   object instance for each of the possible values of ifAdminStatus.

   In those cases where overlap between objects is unavoidable, then as
   we have just described, care should be taken in the description of
   each of the objects to describe their possible interactions.  In the
   case of an object type defined after an incumbent object type, it is
   necessary to include in the DESCRIPTION of this later object type the
   details of these interactions.

3.6.  Textual Convention Usage

   Textual conventions should be used whenever possible to create a
   consistent semantic for an oft-recurring datatype.

   MIB modules often define a binary state object such as enable/disable
   or on/off.  Current practice is to use existing Textual Conventions
   and define the read-write object in terms of a TruthValue from
   SNMPv2-TC [3].  For example, the Q-BRIDGE-MIB [26] defines:

   dot1dTrafficClassesEnabled OBJECT-TYPE
       SYNTAX      TruthValue
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
          "The value true(1) indicates that Traffic Classes are
          enabled on this bridge.  When false(2), the bridge
          operates with a single priority level for all traffic."
       DEFVAL      { true }
       ::= { dot1dExtBase 2 }

   Textual conventions that have a reasonable chance of being reused in
   other MIB modules ideally should also be defined in a separate MIB
   module to facilitate sharing of such object types.  For example, all
   ATM MIB modules draw on the ATM-TC-MIB [39] to reference and utilize
   common definitions for addressing, service class values, and the
   like.



MacFaden, et al.             Informational                     [Page 25]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   To simplify management, it is recommended that existing SNMPv2-TC
   based definitions be used when possible.  For example, consider the
   following object definition:

   acmePatioLights OBJECT-TYPE
       SYNTAX  INTEGER {
                   on(1),
                   off(2),
       }
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "Current status of outdoor lighting."
       ::= { acmeOutDoorElectricalEntry 3 }

   This could be defined as follows using existing SNMPv2-TC TruthValue.

   acmePatioLightsOn OBJECT-TYPE
       SYNTAX  TruthValue
       MAX-ACCESS  read-write
       STATUS      current
       DESCRI2096PTION
           "Current status of outdoor lighting.  When set to true (1),
           this means that the lights are enabled and turned on.
           When set to false (2), the lights are turned off."
        ::= { acmeOutDoorElectricalEntry 3 }

3.7.  Persistent Configuration

   Many network devices have two levels of persistence with regard to
   configuration data.  In the first case, the configuration data sent
   to the device is persistent only until changed with a subsequent
   configuration operation, or the system is reinitialized.  The second
   level is where the data is made persistent as an inherent part of the
   acceptance of the configuration information.  Some configuration
   shares both these properties, that is, that on acceptance of new
   configuration data it is saved permanently and in memory.  Neither of
   these necessarily means that the data is used by the operational
   code.  Sometimes separate objects are required to activate this new
   configuration data for use by the operational code.

   However, many SNMP agents presently implement simple persistence
   models, which do not reflect all the relationships of the
   configuration data to the actual persistence model as described
   above.  Some SNMP set requests against MIB objects with MAX-ACCESS
   read-write are written automatically to a persistent store. In other
   cases, they are not.  In some of the latter cases, enterprise MIB




MacFaden, et al.             Informational                     [Page 26]

RFC 3512       Configuring Networks and Devices with SNMP     April 2003


   objects are required in order to get standard configuration stored,
   thus making it difficult for a generic application to have a
   consistent