rfc3512.txt

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

   as in ACME-ATM-MIB.

   Object descriptors (the "human readable names" assigned to object
   identifiers [2]) defined in standard MIB modules should be unique
   across all MIB modules.  Generally, a prefix is added to each managed
   object that can help reference the MIB module it was defined in.  For
   example, the IF-MIB uses "if" prefix for descriptors of object types
   such as ifTable, ifStackTable and so forth.

   MIB module object type descriptors can include an abbreviation for
   the function they perform.  For example the objects that control
   configuration in the example MIB module in Section 8 include "Cfg" as
   part of the object descriptor, as in bldgHVACCfgDesiredTemp.

   This is more fully realized when the object descriptors that include
   the fault, configuration, accounting, performance and security [33]
   abbreviations are combined with an organized OID assignment approach.
   For example, a vendor could create a configuration branch in their
   private enterprises area.  In some cases this might be best done on a
   per product basis.  Whatever the approach used, "Cfg" might be
   included in every object descriptor in the configuration branch.
   This has two operational benefits.  First, for those that do look at
   instances of MIB objects, descriptors as seen through MIB browsers or
   other command line tools assist in conveying the meaning of the
   object type.  Secondly, management applications can be pointed at
   specific subtrees for fault or configuration, causing a more
   efficient retrieval of data and a simpler management application with
   potentially better performance.



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


3.3.  Transaction Control And State Tracking

   Transactions and keeping track of their state is an important
   consideration when performing any type of configuration activity
   regardless of the protocol.  Here are a few areas to consider when
   designing transaction support into an SNMP-based configuration
   system.

3.3.1.  Conceptual Table Row Modification Practices

   Any discussion of transaction control as it pertains to MIB module
   design often begins with how the creation or modification of object
   instances in a conceptual row in the MIB module is controlled.

   RowStatus [3] is a standard textual convention for the management of
   conceptual rows in a table.  Specifically, the RowStatus textual
   convention that is used for the SYNTAX value of a single column in a
   table controls the creation, deletion, activation, and deactivation
   of conceptual rows of the table.  When a table has been defined with
   a RowStatus object as one of its columns, changing an instance of the
   object to 'active' causes the row in which that object instance
   appears to become 'committed'.

   In a multi-table scenario where the configuration data must be spread
   over many columnar objects, a RowStatus object in one table can be
   used to cause the entire set of data to be put in operation or stored
   based on the definition of the objects.

   In some cases, very large amounts of data may need to be 'committed'
   all at once.  In these cases, another approach is to configure all of
   the rows in all the tables required and have an "activate" object
   that has a set method that commits all the modified rows.

   The RowStatus textual convention specifies that, when used in a
   conceptual row, a description must define what can be modified.
   While the description of the conceptual row and its columnar object
   types is the correct place to derive this information on instance
   modifiability, it is often wrongly assumed in some implementations
   that:

   1) objects either must all be presently set or none need be set to
      make a conceptual RowStatus object transition to active(1)

   2) objects in a conceptual row cannot be modified once a RowStatus
      object is active(1).  Restricting instance modifiability like
      this, so that after a RowStatus object is set to active(1) is in
      fact a reasonable limitation, since such a set of RowStatus may
      have agent system side-effects which depend on committed columnar



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


      object instance values.  However, where this restriction exists on
      an object, it should be made clear in a DESCRIPTION clause such as
      the following:

      protocolDirDescr OBJECT-TYPE
        SYNTAX      DisplayString (SIZE (1..64))
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
            "A textual description of the protocol encapsulation.
            A probe may choose to describe only a subset of the
            entire encapsulation (e.g., only the highest layer).

            This object is intended for human consumption only.

            This object may not be modified if the associated
            protocolDirStatus object is equal to active(1)."
        ::= { protocolDirEntry 4 }

   Any such restrictions on columnar object instance modification while
   a row's RowStatus object instance is set to active(1) should appear
   in the DESCRIPTION clause of the RowStatus columnar OBJECT-TYPE as
   well.

3.3.2.  Fate sharing with multiple tables

   An important principle associated with transaction control is fate
   sharing of rows in different tables.  Consider the case where a
   relationship has been specified between two conceptual tables of a
   MIB module (or tables in two different MIB modules).  In this
   context, fate sharing means that when a row of a table is deleted,
   the corresponding row in the other table is also deleted.  Fate
   sharing in a transaction control context can also be used with the
   activation of very large configuration changes.  If we have two
   tables that hold a set of configuration information, a row in one
   table might have to be put in the 'ready' state before the second can
   be put in the 'ready' state.  When that second table can be placed in
   the 'ready' state, then the entire transaction can be considered to
   have been 'committed'.

   Fate sharing of SNMP table data should be explicitly defined where
   possible using the SMI index qualifier AUGMENTS.  If the relationship
   between tables cannot be defined using SMIv2 macros, then the
   DESCRIPTION clause of the object types which particularly effect the
   cross-table relationship should define what should happen when rows
   in related tables are added or deleted.





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


   Consider the relationship between the dot1dBasePortTable and the
   ifTable.  These tables have a sparse relationship.  If a given
   ifEntry supports 802.1D bridging then there is a dot1dBasePortEntry
   that has a pointer to it via dot1dBasePortIfIndex.

   Now, what should happen if an ifEntry that can bridge is deleted?
   Should the object dot1dBasePortIfIndex simply be set to 0 or should
   the dot1dBasePortEntry be deleted as well?  A number of acceptable
   design and practice techniques can provide the answer to these
   questions, so it is important for the MIB module designer to provide
   the guidance to guarantee consistency and interoperability.

   To this end, when two tables are related in such a way, ambiguities
   such as this should be avoided by having the DESCRIPTION clauses of
   the pertinent row object types define the fate sharing of entries in
   the respective tables.

3.3.3.  Transaction Control MIB Objects

   When a MIB module is defined that includes configuration object
   types, consider providing transaction control objects.  These objects
   can be used to cause a large transaction to be committed.  For
   example, we might have several tables that define the configuration
   of a portion of a system.  In order to avoid churn in the operational
   state of the system we might create a single scalar object that, when
   set to a particular value, will cause the activation of the rows in
   all the necessary tables.  Here are some examples of further usage
   for such object types:

   o  Control objects that are the 'write' or 'commit' objects.

      Such objects can cause all pending transactions (change MIB object
      values as a result of SET operations) to be committed to a
      permanent repository or operational memory, as defined by the
      semantics of the MIB objects.

   o  Control objects at different levels of configuration granularity.

      One of the decisions for a MIB module designer is what are the
      levels of granularity that make sense in practice.  For example,
      in the routing area, would changes be allowed on a per protocol
      basis such as BGP? If allowed at the BGP level, are sub-levels
      permitted such as per autonomous system? The design of these
      control objects will be impacted by the underlying software
      design.  RowStatus (see Section 3.3.1) also has important
      relevance as a general transaction control object.





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


3.3.4.  Creating And Activating New Table Rows

   When designing read-create objects in a table, a MIB module designer
   should first consider the default state of each object in the table
   when a row is created.  Should an implementation of a standard MIB
   module vary in terms of the objects that need to be set in order to
   create an instance of a given row, an agent capabilities statement
   should be used to name the additional objects in that table using the
   CREATION-REQUIRES clause.

   It is useful when configuring new rows to use the notReady status to
   indicate row activation cannot proceed.

   When creating a row instance of a conceptual table, one should
   consider the state of instances of required columnar objects in the
   row.  The DESCRIPTION clause of such a required columnar object
   should specify it as such.

   During the period of time when a management application is attempting
   to create a row, there may be a period of time when not all of these
   required (and non-defaultable) columnar object instances have been
   set. Throughout this time, an agent should return a noSuchInstance
   error for a GET of any object instance of the row until such time
   that all of these required instance values are set.  The exception is
   the RowStatus object instance, for which a notReady(3) value should
   be returned during this period.

   One need only be concerned with the notReady value return for a
   RowStatus object when the row under creation does not yet have all of
   the required, non-defaultable instance values for the row.  One
   approach to simplifying in-row configuration transactions when
   designing MIB modules is to construct table rows that have no more
   instance data for columnar objects than will fit inside a single SET
   PDU.  In this case, the createAndWait() value for the RowStatus
   columnar object is not required.  It is possible to use createAndGo()
   in the same SET PDU, thus simplifying transactional management.

3.3.5.  Summary Objects and State Tracking

   Before beginning a new set of configuration transactions, a
   management application might want to checkpoint the state of the
   managed devices whose configuration it is about to change.  There are
   a number of techniques that a MIB module designer can provide to
   assist in the (re-)synchronization of the managed systems.  These
   objects can also be used to verify that the management application's
   notion of the managed system state is the same as that of the managed
   device.




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


   These techniques include:

   1. Provide an object that reports the number of rows in a table

   2. Provide an object that flags when data in the table was last
      modified.

   3. Send a notification message (InformRequests are preferable) to
      deliver configuration change.

   By providing an object containing the number of rows in a table,
   management applications can decide how best to retrieve a given
   table's data and may choose different retrieval strategies depending
   on table size.  Note that the availability of and application
   monitoring of such an object is not sufficient for determining the
   presence of table data change over a checkpointed duration since an
   equal number of row creates and deletes over that duration would
   reflect no change in the object instance value.  Additionally, table
   data change which does not change the number of rows in the table
   would not be reflected through simple monitoring of such an object
   instance.

   Instead, the change in the value of any table object instance data
   can be tracked through an object that monitors table change state as
   a function of time.  An example is found in RFC 2790, Host Resources
   MIB:

   hrSWInstalledLastUpdateTime OBJECT-TYPE
       SYNTAX     TimeTicks
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
           "The value of sysUpTime when the hrSWInstalledTable