rfc2578.txt

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

                   Tel: [phone]
                   Fax: [phone]

                E-mail: [e-mail]"

       DESCRIPTION
               "The MIB module for entities implementing the xxxx
               protocol."
       REVISION      "9505241811Z"
       DESCRIPTION
               "The latest version of this MIB module."
       REVISION      "9210070433Z"
       DESCRIPTION
               "The initial version of this MIB module, published in
               RFC yyyy."
   -- contact IANA for actual number
       ::= { experimental xx }

   END

6.  Mapping of the OBJECT-IDENTITY macro

   The OBJECT-IDENTITY macro is used to define information about an
   OBJECT IDENTIFIER assignment.  All administrative OBJECT IDENTIFIER
   assignments which define a type identification value (see
   AutonomousType, a textual convention defined in [3]) should be
   defined via the OBJECT-IDENTITY macro.  It should be noted that the
   expansion of the OBJECT-IDENTITY macro is something which
   conceptually happens during implementation and not during run-time.

6.1.  Mapping of the STATUS clause

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


McCloghrie, et al.          Standards Track                    [Page 19]





RFC 2578                         SMIv2                        April 1999


   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.

6.2.  Mapping of the DESCRIPTION clause

   The DESCRIPTION clause, which must be present, contains a textual
   description of the object assignment.

6.3.  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.

6.4.  Mapping of the OBJECT-IDENTITY value

   The value of an invocation of the OBJECT-IDENTITY macro is an OBJECT
   IDENTIFIER.

6.5.  Usage Example

   Consider how an OBJECT IDENTIFIER assignment might be made:  e.g.,

   fizbin69 OBJECT-IDENTITY
       STATUS  current
       DESCRIPTION
               "The authoritative identity of the Fizbin 69 chipset."
      ::= { fizbinChipSets 1 }

7.  Mapping of the OBJECT-TYPE macro

   The OBJECT-TYPE macro is used to define a type of managed object.  It
   should be noted that the expansion of the OBJECT-TYPE macro is
   something which conceptually happens during implementation and not
   during run-time.

   For leaf objects which are not columnar objects (i.e., not contained
   within a conceptual table), instances of the object are identified by
   appending a sub-identifier of zero to the name of that object.
   Otherwise, the INDEX clause of the conceptual row object superior to
   a columnar object defines instance identification information.




McCloghrie, et al.          Standards Track                    [Page 20]





RFC 2578                         SMIv2                        April 1999


7.1.  Mapping of the SYNTAX clause

   The SYNTAX clause, which must be present, defines the abstract data
   structure corresponding to that object.  The data structure must be
   one of the following: a base type, the BITS construct, or a textual
   convention.  (SEQUENCE OF and SEQUENCE are also possible for
   conceptual tables, see section 7.1.12).  The base types are those
   defined in the ObjectSyntax CHOICE.  A textual convention is a
   newly-defined type defined as a sub-type of a base type [3].

   An extended subset of the full capabilities of ASN.1 (1988) sub-
   typing is allowed, as appropriate to the underlying ASN.1 type.  Any
   such restriction on size, range or enumerations specified in this
   clause represents the maximal level of support which makes "protocol
   sense".  Restrictions on sub-typing are specified in detail in
   Section 9 and Appendix A of this memo.

   The semantics of ObjectSyntax are now described.

7.1.1.  Integer32 and INTEGER

   The Integer32 type represents integer-valued information between
   -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal).  This
   type is indistinguishable from the INTEGER type.  Both the INTEGER
   and Integer32 types may be sub-typed to be more constrained than the
   Integer32 type.

   The INTEGER type (but not the Integer32 type) may also be used to
   represent integer-valued information as named-number enumerations.
   In this case, only those named-numbers so enumerated may be present
   as a value.  Note that although it is recommended that enumerated
   values start at 1 and be numbered contiguously, any valid value for
   Integer32 is allowed for an enumerated value and, further, enumerated
   values needn't be contiguously assigned.

   Finally, a label for a named-number enumeration must consist of one
   or more letters or digits, up to a maximum of 64 characters, and the
   initial character must be a lower-case letter.  (However, labels
   longer than 32 characters are not recommended.)  Note that hyphens
   are not allowed by this specification (except for use by information
   modules converted from SMIv1 which did allow hyphens).

7.1.2.  OCTET STRING

   The OCTET STRING type represents arbitrary binary or textual data.
   Although the SMI-specified size limitation for this type is 65535
   octets, MIB designers should realize that there may be implementation
   and interoperability limitations for sizes in excess of 255 octets.


McCloghrie, et al.          Standards Track                    [Page 21]





RFC 2578                         SMIv2                        April 1999


7.1.3.  OBJECT IDENTIFIER

   The OBJECT IDENTIFIER type represents administratively assigned
   names.  Any instance of this type may have at most 128 sub-
   identifiers.  Further, each sub-identifier must not exceed the value
   2^32-1 (4294967295 decimal).

7.1.4.  The BITS construct

   The BITS construct represents an enumeration of named bits.  This
   collection is assigned non-negative, contiguous (but see below)
   values, starting at zero.  Only those named-bits so enumerated may be
   present in a value.  (Thus, enumerations must be assigned to
   consecutive bits; however, see Section 9 for refinements of an object
   with this syntax.)

   As part of updating an information module, for an object defined
   using the BITS construct, new enumerations can be added or existing
   enumerations can have new labels assigned to them.  After an
   enumeration is added, it might not be possible to distinguish between
   an implementation of the updated object for which the new enumeration
   is not asserted, and an implementation of the object prior to the
   addition.  Depending on the circumstances, such an ambiguity could
   either be desirable or could be undesirable.  The means to avoid such
   an ambiguity is dependent on the encoding of values on the wire;
   however, one possibility is to define new enumerations starting at
   the next multiple of eight bits.  (Of course, this can also result in
   the enumerations no longer being contiguous.)

   Although there is no SMI-specified limitation on the number of
   enumerations (and therefore on the length of a value), except as may
   be imposed by the limit on the length of an OCTET STRING, MIB
   designers should realize that there may be implementation and
   interoperability limitations for sizes in excess of 128 bits.

   Finally, a label for a named-number enumeration must consist of one
   or more letters or digits, up to a maximum of 64 characters, and the
   initial character must be a lower-case letter.  (However, labels
   longer than 32 characters are not recommended.)  Note that hyphens
   are not allowed by this specification.

7.1.5.  IpAddress

   The IpAddress type represents a 32-bit internet address.  It is
   represented as an OCTET STRING of length 4, in network byte-order.





McCloghrie, et al.          Standards Track                    [Page 22]





RFC 2578                         SMIv2                        April 1999


   Note that the IpAddress type is a tagged type for historical reasons.
   Network addresses should be represented using an invocation of the
   TEXTUAL-CONVENTION macro [3].

7.1.6.  Counter32

   The Counter32 type represents a non-negative integer which
   monotonically increases until it reaches a maximum value of 2^32-1
   (4294967295 decimal), when it wraps around and starts increasing
   again from zero.

   Counters have no defined "initial" value, and thus, a single value of
   a Counter has (in general) no information content.  Discontinuities
   in the monotonically increasing value normally occur at re-
   initialization of the management system, and at other times as
   specified in the description of an object-type using this ASN.1 type.
   If such other times can occur, for example, the creation of an object
   instance at times other than re-initialization, then a corresponding
   object should be defined, with an appropriate SYNTAX clause, to
   indicate the last discontinuity.  Examples of appropriate SYNTAX
   clause include:  TimeStamp (a textual convention defined in [3]),
   DateAndTime (another textual convention from [3]) or TimeTicks.

   The value of the MAX-ACCESS clause for objects with a SYNTAX clause
   value of Counter32 is either "read-only" or "accessible-for-notify".

   A DEFVAL clause is not allowed for objects with a SYNTAX clause value
   of Counter32.

7.1.7.  Gauge32

   The Gauge32 type represents a non-negative integer, which may
   increase or decrease, but shall never exceed a maximum value, nor
   fall below a minimum value.  The maximum value can not be greater
   than 2^32-1 (4294967295 decimal), and the minimum value can not be
   smaller than 0.  The value of a Gauge32 has its maximum value
   whenever the information being modeled is greater than or equal to
   its maximum value, and has its minimum value whenever the information
   being modeled is smaller than or equal to its minimum value.  If the
   information being modeled subsequently decreases below (increases
   above) the maximum (minimum) value, the Gauge32 also decreases
   (increases).  (Note that despite of the use of the term "latched" in
   the original definition of this type, it does not become "stuck" at
   its maximum or minimum value.)






McCloghrie, et al.          Standards Track                    [Page 23]





RFC 2578                         SMIv2                        April 1999


7.1.8.  TimeTicks

   The TimeTicks type represents a non-negative integer which represents
   the time, modulo 2^32 (4294967296 decimal), in hundredths of a second
   between two epochs.  When objects are defined which use this ASN.1
   type, the description of the object identifies both of the reference
   epochs.

   For example, [3] defines the TimeStamp textual convention which is
   based on the TimeTicks type.  With a TimeStamp, the first reference
   epoch is defined as the time when sysUpTime [5] was zero, and the
   second reference epoch is defined as the current value of sysUpTime.

   The TimeTicks type may not be sub-typed.

7.1.9.  Opaque

   The Opaque type is provided solely for backward-compatibility, and
   shall not be used for newly-defined object types.

   The Opaque type supports the capability to pass arbitrary ASN.1
   syntax.  A value is encoded using the ASN.1 Basic Encoding Rules [4]
   into a string of octets.  This, in turn, is encoded as an OCTET
   STRING, in effect "double-wrapping" the original ASN.1 value.

   Note that a conforming implementation need only be able to accept and
   recognize opaquely-encoded data.  It need not be able to unwrap the
   data and then interpret its contents.

   A requirement on "standard" MIB modules is that no object may have a
   SYNTAX clause value of Opaque.

7.1.10.  Counter64

   The Counter64 type represents a non-negative integer which
   monotonically increases until it reaches a maximum value of 2^64-1
   (18446744073709551615 decimal), when it wraps around and starts
   increasing again from zero.

   Counters have no defined "initial" value, and thus, a single value of
   a Counter has (in general) no information content.  Discontinuities
   in the monotonically increasing value normally occur at re-
   initialization of the management system, and at other times as
   specified in the description of an object-type using this ASN.1 type.
   If such other times can occur, for example, the creation of an object
   instance at times other than re-initialization, then a corresponding
   object should be defined, with an appropriate SYNTAX clause, to
   indicate the last discontinuity.  Examples of appropriate SYNTAX


McCloghrie, et al.          Standards Track                    [Page 24]





RFC 2578                         SMIv2                        April 1999


   clause are:  TimeStamp (a textual convention defined in [3]),
   DateAndTime (another textual convention from [3]) or TimeTicks.

   The value of the MAX-ACCESS clause for objects with a SYNTAX clause
   value of Counter64 is either "read-only" or "accessible-for-notify".

   A requirement on "standard" MIB modules is that the Counter64 type
   may be used only if the information being modeled would wrap in less
   than one hour if the Counter32 type was used instead.

   A DEFVAL clause is not allowed for objects with a SYNTAX clause value
   of Counter64.

7.1.11.  Unsigned32

   The Unsigned32 type represents integer-valued information between 0
   and 2^32-1 inclusive (0 to 4294967295 decimal).

7.1.12.  Conceptual Tables

   Management operations apply exclusively to scalar objects.  However,