rfc2578.txt

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

   it is sometimes convenient for developers of management applications
   to impose an imaginary, tabular structure on an ordered collection of
   objects within the MIB.  Each such conceptual table contains zero or
   more rows, and each row may contain one or more scalar objects,
   termed columnar objects.  This conceptualization is formalized by
   using the OBJECT-TYPE macro to define both an object which
   corresponds to a table and an object which corresponds to a row in
   that table.  A conceptual table has SYNTAX of the form:

        SEQUENCE OF <EntryType>

   where <EntryType> refers to the SEQUENCE type of its subordinate
   conceptual row.  A conceptual row has SYNTAX of the form:

        <EntryType>

   where <EntryType> is a SEQUENCE type defined as follows:

        <EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }

   where there is one <type> for each subordinate object, and each
   <type> is of the form:

        <descriptor> <syntax>

   where <descriptor> is the descriptor naming a subordinate object, and
   <syntax> has the value of that subordinate object's SYNTAX clause,


McCloghrie, et al.          Standards Track                    [Page 25]





RFC 2578                         SMIv2                        April 1999


   except that both sub-typing information and the named values for
   enumerated integers or the named bits for the BITS construct, are
   omitted from <syntax>.

   Further, a <type> is always present for every subordinate object.
   (The ASN.1 DEFAULT and OPTIONAL clauses are disallowed in the
   SEQUENCE definition.)  The MAX-ACCESS clause for conceptual tables
   and rows is "not-accessible".

7.1.12.1.  Creation and Deletion of Conceptual Rows

   For newly-defined conceptual rows which allow the creation of new
   object instances and/or the deletion of existing object instances,
   there should be one columnar object with a SYNTAX clause value of
   RowStatus (a textual convention defined in [3]) and a MAX-ACCESS
   clause value of read-create.  By convention, this is termed the
   status column for the conceptual row.

7.2.  Mapping of the UNITS clause

   This UNITS clause, which need not be present, contains a textual
   definition of the units associated with that object.

7.3.  Mapping of the MAX-ACCESS clause

   The MAX-ACCESS clause, which must be present, defines whether it
   makes "protocol sense" to read, write and/or create an instance of
   the object, or to include its value in a notification.  This is the
   maximal level of access for the object.  (This maximal level of
   access is independent of any administrative authorization policy.)

   The value "read-write" indicates that read and write access make
   "protocol sense", but create does not.  The value "read-create"
   indicates that read, write and create access make "protocol sense".
   The value "not-accessible" indicates an auxiliary object (see Section
   7.7).  The value "accessible-for-notify" indicates an object which is
   accessible only via a notification (e.g., snmpTrapOID [5]).

   These values are ordered, from least to greatest:  "not-accessible",
   "accessible-for-notify", "read-only", "read-write", "read-create".

   If any columnar object in a conceptual row has "read-create" as its
   maximal level of access, then no other columnar object of the same
   conceptual row may have a maximal access of "read-write".  (Note that
   "read-create" is a superset of "read-write".)





McCloghrie, et al.          Standards Track                    [Page 26]





RFC 2578                         SMIv2                        April 1999


7.4.  Mapping of the STATUS clause

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

   The value "current" means that the definition is current and valid.
   The value "obsolete" means the definition is obsolete and should not
   be implemented and/or can be removed if previously implemented.
   While the value "deprecated" also indicates an obsolete definition,
   it permits new/continued implementation in order to foster
   interoperability with older/existing implementations.

7.5.  Mapping of the DESCRIPTION clause

   The DESCRIPTION clause, which must be present, contains a textual
   definition of that object 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 object.

7.6.  Mapping of the REFERENCE clause

   The REFERENCE clause, which need not be present, contains a textual
   cross-reference to some other document, either another information
   module which defines a related assignment, or some other document
   which provides additional information relevant to this definition.

7.7.  Mapping of the INDEX clause

   The INDEX clause, which must be present if that object corresponds to
   a conceptual row (unless an AUGMENTS clause is present instead), and
   must be absent otherwise, defines instance identification information
   for the columnar objects subordinate to that object.

   The instance identification information in an INDEX clause must
   specify object(s) such that value(s) of those object(s) will
   unambiguously distinguish a conceptual row.  The objects can be
   columnar objects from the same and/or another conceptual table, but
   must not be scalar objects.  Multiple occurrences of the same object
   in a single INDEX clause is strongly discouraged.

   The syntax of the objects in the INDEX clause indicate how to form
   the instance-identifier:

(1)  integer-valued (i.e., having INTEGER as its underlying primitive
     type):  a single sub-identifier taking the integer value (this
     works only for non-negative integers);



McCloghrie, et al.          Standards Track                    [Page 27]





RFC 2578                         SMIv2                        April 1999


(2)  string-valued, fixed-length strings (or variable-length preceded by
     the IMPLIED keyword):  `n' sub-identifiers, where `n' is the length
     of the string (each octet of the string is encoded in a separate
     sub-identifier);

(3)  string-valued, variable-length strings (not preceded by the IMPLIED
     keyword):  `n+1' sub-identifiers, where `n' is the length of the
     string (the first sub-identifier is `n' itself, following this,
     each octet of the string is encoded in a separate sub-identifier);

(4)  object identifier-valued (when preceded by the IMPLIED keyword):
     `n' sub-identifiers, where `n' is the number of sub-identifiers in
     the value (each sub-identifier of the value is copied into a
     separate sub-identifier);

(5)  object identifier-valued (when not preceded by the IMPLIED
     keyword):  `n+1' sub-identifiers, where `n' is the number of sub-
     identifiers in the value (the first sub-identifier is `n' itself,
     following this, each sub-identifier in the value is copied);

(6)  IpAddress-valued:  4 sub-identifiers, in the familiar a.b.c.d
     notation.

   Note that the IMPLIED keyword can only be present for an object
   having a variable-length syntax (e.g., variable-length strings or
   object identifier-valued objects), Further, the IMPLIED keyword can
   only be associated with the last object in the INDEX clause.
   Finally, the IMPLIED keyword may not be used on a variable-length
   string object if that string might have a value of zero-length.

   Since a single value of a Counter has (in general) no information
   content (see section 7.1.6 and 7.1.10), objects defined using the
   syntax, Counter32 or Counter64, must not be specified in an INDEX

   clause. If an object defined using the BITS construct is used in an
   INDEX clause, it is considered a variable-length string.

   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 should be avoided, except
   in special cases.

   Objects which are both specified in the INDEX clause of a conceptual
   row and also columnar objects of the same conceptual row are termed
   auxiliary objects.  The MAX-ACCESS clause for auxiliary objects is
   "not-accessible", except in the following circumstances:




McCloghrie, et al.          Standards Track                    [Page 28]





RFC 2578                         SMIv2                        April 1999


(1)  within a MIB module originally written to conform to SMIv1, and
     later converted to conform to SMIv2; or

(2)  a conceptual row must contain at least one columnar object which is
     not an auxiliary object.  In the event that all of a conceptual
     row's columnar objects are also specified in its INDEX clause, then
     one of them must be accessible, i.e., have a MAX-ACCESS clause of
     "read-only". (Note that this situation does not arise for a
     conceptual row allowing create access, since such a row will have a
     status column which will not be an auxiliary object.)

   Note that objects specified in a conceptual row's INDEX clause need
   not be columnar objects of that conceptual row.  In this situation,
   the DESCRIPTION clause of the conceptual row must include a textual
   explanation of how the objects which are included in the INDEX clause
   but not columnar objects of that conceptual row, are used in uniquely
   identifying instances of the conceptual row's columnar objects.

7.8.  Mapping of the AUGMENTS clause

   The AUGMENTS clause, which must not be present unless the object
   corresponds to a conceptual row, is an alternative to the INDEX
   clause.  Every object corresponding to a conceptual row has either an
   INDEX clause or an AUGMENTS clause.

   If an object corresponding to a conceptual row has an INDEX clause,
   that row is termed a base conceptual row; alternatively, if the
   object has an AUGMENTS clause, the row is said to be a conceptual row
   augmentation, where the AUGMENTS clause names the object
   corresponding to the base conceptual row which is augmented by this
   conceptual row augmentation.  (Thus, a conceptual row augmentation
   cannot itself be augmented.)  Instances of subordinate columnar
   objects of a conceptual row augmentation are identified according to
   the INDEX clause of the base conceptual row corresponding to the
   object named in the AUGMENTS clause.  Further, instances of
   subordinate columnar objects of a conceptual row augmentation exist
   according to the same semantics as instances of subordinate columnar
   objects of the base conceptual row being augmented.  As such, note
   that creation of a base conceptual row implies the correspondent
   creation of any conceptual row augmentations.

   For example, a MIB designer might wish to define additional columns
   in an "enterprise-specific" MIB which logically extend a conceptual
   row in a "standard" MIB.  The "standard" MIB definition of the
   conceptual row would include the INDEX clause and the "enterprise-
   specific" MIB would contain the definition of a conceptual row using
   the AUGMENTS clause.  On the other hand, it would be incorrect to use
   the AUGMENTS clause for the relationship between RFC 2233's ifTable


McCloghrie, et al.          Standards Track                    [Page 29]





RFC 2578                         SMIv2                        April 1999


   and the many media-specific MIBs which extend it for specific media
   (e.g., the dot3Table in RFC 2358), since not all interfaces are of
   the same media.

   Note that a base conceptual row may be augmented by multiple
   conceptual row augmentations.

7.8.1.  Relation between INDEX and AUGMENTS clauses

   When defining instance identification information for a conceptual
   table:

(1)  If there is a one-to-one correspondence between the conceptual rows
     of this table and an existing table, then the AUGMENTS clause
     should be used.

(2)  Otherwise, if there is a sparse relationship between the conceptual
     rows of this table and an existing table, then an INDEX clause
     should be used which is identical to that in the existing table.
     For example, the relationship between RFC 2233's ifTable and a
     media-specific MIB which extends the ifTable for a specific media
     (e.g., the dot3Table in RFC 2358), is a sparse relationship.

(3)  Otherwise, if no existing objects have the required syntax and
     semantics, then auxiliary objects should be defined within the
     conceptual row for the new table, and those objects should be used
     within the INDEX clause for the conceptual row.

7.9.  Mapping of the DEFVAL clause

   The DEFVAL clause, which need not be present, defines an acceptable
   default value which may be used at the discretion of an agent when an
   object instance is created.  That is, the value is a "hint" to
   implementors.

   During conceptual row creation, if an instance of a columnar object
   is not present as one of the operands in the correspondent management
   protocol set operation, then the value of the DEFVAL clause, if
   present, indicates an acceptable default value that an agent might
   use (especially for a read-only object).

   Note that with this definition of the DEFVAL clause, it is
   appropriate to use it for any columnar object of a read-create table.
   It is also permitted to use it for scalar objects dynamically created
   by an agent, or for columnar objects of a read-write table
   dynamically created by an agent.




McCloghrie, et al.          Standards Track                    [Page 30]





RFC 2578                         SMIv2                        April 1999


   The value of the DEFVAL clause must, of course, correspond to the
   SYNTAX clause for the object.  If the value is an OBJECT IDENTIFIER,
   then it must be expressed as a single ASN.1 identifier, and not as a
   collection of sub-identifiers.

   Note that if an operand to the management protocol set operation is
   an instance of a read-only object, then the error `notWritable' [6]
   will be returned.  As such, the DEFVAL clause can be used to provide
   an acceptable default value that an agent might use.

   By way of example, consider the following possible DEFVAL clauses:

        ObjectSyntax       DEFVAL clause
        ----------------   ------------
        Integer32          DEFVAL { 1 }
                           -- same for Gauge32, TimeTicks, Unsigned32
        INTEGER            DEFVAL { valid } -- enumerated value
        OCTET STRING       DEFVAL { 'ffffffffffff'H }
        DisplayString      DEFVAL { "SNMP agent" }
        IpAddress          DEFVAL { 'c0210415'H } -- 192.33.4.21
        OBJECT IDENTIFIER  DEFVAL { sysDescr }
        BITS               DEFVAL { { primary, secondary } }
                           -- enumerated values that are set
        BITS               DEFVAL { { }