rfc1902.txt

中、英文RFC文档大全打包下载完全版 .

            the columnar objects in the evaluation table."
        ::= { evalEntry 1 }

evalString OBJECT-TYPE
    SYNTAX      DisplayString
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "The string to evaluate."
        ::= { evalEntry 2 }

evalValue OBJECT-TYPE
    SYNTAX      Integer32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The value when evalString was last executed."
    DEFVAL  { 0 }
        ::= { evalEntry 3 }

evalStatus OBJECT-TYPE
    SYNTAX      RowStatus



SNMPv2 Working Group        Standards Track                    [Page 27]

RFC 1902                     SMI for SNMPv2                 January 1996


    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
            "The status column used for creating, modifying, and
            deleting instances of the columnar objects in the evaluation
            table."
    DEFVAL  { active }
        ::= { evalEntry 4 }

8.  Mapping of the NOTIFICATION-TYPE macro

   The NOTIFICATION-TYPE macro is used to define the information
   contained within an unsolicited transmission of management
   information (i.e., within either a SNMPv2-Trap-PDU or InformRequest-
   PDU).  It should be noted that the expansion of the NOTIFICATION-TYPE
   macro is something which conceptually happens during implementation
   and not during run-time.

8.1.  Mapping of the OBJECTS clause

   The OBJECTS clause, which need not be present, defines the ordered
   sequence of MIB object types which are contained within every
   instance of the notification.  An object type specified in this
   clause may not have an MAX-ACCESS clause of "not-accessible".

8.2.  Mapping of the STATUS clause

   The STATUS clause, which must be present, indicates whether this
   definition is current or historic.

   The values "current", and "obsolete" are self-explanatory.  The
   "deprecated" value indicates that the definition is obsolete, but
   that an implementor may wish to support the notification to foster
   interoperability with older implementations.

8.3.  Mapping of the DESCRIPTION clause

   The DESCRIPTION clause, which must be present, contains a textual
   definition of the notification which provides all semantic
   definitions necessary for implementation, and should embody any
   information which would otherwise be communicated in any ASN.1
   commentary annotations associated with the notification.  In
   particular, the DESCRIPTION clause should document which instances of
   the objects mentioned in the OBJECTS clause should be contained
   within notifications of this type.






SNMPv2 Working Group        Standards Track                    [Page 28]

RFC 1902                     SMI for SNMPv2                 January 1996


8.4.  Mapping of the REFERENCE clause

   The REFERENCE clause, which need not be present, contains a textual
   cross-reference to a notification defined in some other information
   module.  This is useful when de-osifying a MIB module produced by
   some other organization.

8.5.  Mapping of the NOTIFICATION-TYPE value

   The value of an invocation of the NOTIFICATION-TYPE macro is the name
   of the notification, which is an OBJECT IDENTIFIER, an
   administratively assigned name.  In order to achieve compatibility
   with the procedures employed by proxy agents (see Section 3.1.2 of
   [7]), the next to last sub-identifier in the name of any newly-
   defined notification must have the value zero.

   Sections 4.2.6 and 4.2.7 of [6] describe how the NOTIFICATION-TYPE
   macro is used to generate a SNMPv2-Trap-PDU or InformRequest-PDU,
   respectively.

8.6.  Usage Example

   Consider how a linkUp trap might be described:

linkUp NOTIFICATION-TYPE
    OBJECTS { ifIndex }
    STATUS  current
    DESCRIPTION
            "A linkUp trap signifies that the SNMPv2 entity, acting in
            an agent role, recognizes that one of the communication
            links represented in its configuration has come up."
    ::= { snmpTraps 4 }

According to this invocation, the trap authoritatively identified as

     { snmpTraps 4 }

is used to report a link coming up.

9.  Refined Syntax

   Some macros have clauses which allows syntax to be refined,
   specifically: the SYNTAX clause of the OBJECT-TYPE macro, and the
   SYNTAX/WRITE-SYNTAX clauses of the MODULE-COMPLIANCE and AGENT-
   CAPABILITIES macros [2].  However, not all refinements of syntax are
   appropriate.  In particular, the object's primitive or application
   type must not be changed.




SNMPv2 Working Group        Standards Track                    [Page 29]

RFC 1902                     SMI for SNMPv2                 January 1996


   Further, the following restrictions apply:

                            Restrictions to Refinement on
  object syntax         range   enumeration     size    repertoire
  -----------------     -----   -----------     ----    ----------
            INTEGER      (1)        (2)           -         -
          Integer32      (1)         -            -         -
         Unsigned32      (1)         -            -         -
       OCTET STRING       -          -           (3)       (4)
  OBJECT IDENTIFIER       -          -            -         -
               BITS       -         (2)           -         -
          IpAddress       -          -            -         -
          Counter32       -          -            -         -
          Counter64       -          -            -         -
            Gauge32      (1)         -            -         -
          TimeTicks       -          -            -         -

where:

(1)  the range of permitted values may be refined by raising the lower-
     bounds, by reducing the upper-bounds, and/or by reducing the
     alternative value/range choices;

(2)  the enumeration of named-values may be refined by removing one or
     more named-values (note that for BITS, a refinement may cause the
     enumerations to no longer be contiguous);

(3)  the size in characters of the value may be refined by raising the
     lower-bounds, by reducing the upper-bounds, and/or by reducing the
     alternative size choices; or,

(4)  the repertoire of characters in the value may be reduced by further
     sub-typing.

   Otherwise no refinements are possible.  Further details on sub-typing
   are provided in Appendix C.

10.  Extending an Information Module

   As experience is gained with a published information module, it may
   be desirable to revise that information module.

   To begin, the invocation of the MODULE-IDENTITY macro should be
   updated to include information about the revision.  Usually, this
   consists of updating the LAST-UPDATED clause and adding a pair of
   REVISION and DESCRIPTION clauses.  However, other existing clauses in
   the invocation may be updated.




SNMPv2 Working Group        Standards Track                    [Page 30]

RFC 1902                     SMI for SNMPv2                 January 1996


   Note that the module's label (e.g., "FIZBIN-MIB" from the example in
   Section 5.8), is not changed when the information module is revised.

10.1.  Object Assignments

   If any non-editorial change is made to any clause of a object
   assignment, then the OBJECT IDENTIFIER value associated with that
   object assignment must also be changed, along with its associated
   descriptor.

10.2.  Object Definitions

   An object definition may be revised in any of the following ways:

(1)  A SYNTAX clause containing an enumerated INTEGER may have new
     enumerations added or existing labels changed.

(2)  A STATUS clause value of "current" may be revised as "deprecated"
     or "obsolete".  Similarly, a STATUS clause value of "deprecated"
     may be revised as "obsolete".

(3)  A DEFVAL clause may be added or updated.

(4)  A REFERENCE clause may be added or updated.

(5)  A UNITS clause may be added.

(6)  A conceptual row may be augmented by adding new columnar objects at
     the end of the row.

(7)  Entirely new objects may be defined, named with previously
     unassigned OBJECT IDENTIFIER values.

   Otherwise, if the semantics of any previously defined object are
   changed (i.e., if a non-editorial change is made to any clause other
   those specifically allowed above), then the OBJECT IDENTIFIER value
   associated with that object must also be changed.

   Note that changing the descriptor associated with an existing object
   is considered a semantic change, as these strings may be used in an
   IMPORTS statement.

   Finally, note that if an object has the value of its STATUS clause
   changed, then the value of its DESCRIPTION clause should be updated
   accordingly.






SNMPv2 Working Group        Standards Track                    [Page 31]

RFC 1902                     SMI for SNMPv2                 January 1996


10.3.  Notification Definitions

   A notification definition may be revised in any of the following
   ways:

   (1)  A REFERENCE clause may be added or updated.

   Otherwise, if the semantics of any previously defined notification
   are changed (i.e., if a non-editorial change is made to any clause
   other those specifically allowed above), then the OBJECT IDENTIFIER
   value associated with that notification must also be changed.

   Note that changing the descriptor associated with an existing
   notification is considered a semantic change, as these strings may be
   used in an IMPORTS statement.

   Finally, note that if an object has the value of its STATUS clause
   changed, then the value of its DESCRIPTION clause should be updated
   accordingly.
































SNMPv2 Working Group        Standards Track                    [Page 32]

RFC 1902                     SMI for SNMPv2                 January 1996


11.  Appendix A: de-OSIfying a MIB module

   There has been an increasing amount of work recently on taking MIBs
   defined by other organizations (e.g., the IEEE) and de-osifying them
   for use with the Internet-standard network management framework.  The
   steps to achieve this are straight-forward, though tedious.  Of
   course, it is helpful to already be experienced in writing MIB
   modules for use with the Internet-standard network management
   framework.

   The first step is to construct a skeletal MIB module, as shown
   earlier in Section 5.8.  The next step is to categorize the objects
   into groups.  Optional objects are not permitted.  Thus, when a MIB
   module is created, optional objects must be placed in a additional
   groups, which, if implemented, all objects in the group must be
   implemented.  For the first pass, it is wisest to simply ignore any
   optional objects in the original MIB:  experience shows it is better
   to define a core MIB module first, containing only essential objects;
   later, if experience demands, other objects can be added.

11.1.  Managed Object Mapping

   Next for each managed object class, determine whether there can exist
   multiple instances of that managed object class.  If not, then for
   each of its attributes, use the OBJECT-TYPE macro to make an
   equivalent definition.

   Otherwise, if multiple instances of the managed object class can
   exist, then define a conceptual table having conceptual rows each
   containing a columnar object for each of the managed object class's
   attributes.  If the managed object class is contained within the
   containment tree of another managed object class, then the assignment
   of an object is normally required for each of the "distinguished
   attributes" of the containing managed object class.  If they do not
   already exist within the MIB module, then they can be added via the
   definition of additional columnar objects in the conceptual row
   corresponding to the contained managed object class.

   In defining a conceptual row, it is useful to consider the
   optimization of network management operations which will act upon its
   columnar objects.  In particular, it is wisest to avoid defining more
   columnar objects within a conceptual row, than can fit in a single
   PDU.  As a rule of thumb, a conceptual row should contain no more
   than approximately 20 objects.  Similarly, or as a way to abide by
   the "20 object guideline", columnar objects should be grouped into
   tables according to the expected grouping of network management
   operations upon them.  As such, the content of conceptual rows should
   reflect typical access scenarios, e.g., they should be organized



SNMPv2 Working Group        Standards Track                    [Page 33]

RFC 1902                     SMI for SNMPv2                 January 1996


   along functional lines such as one row for statistics and another row