rfc1902.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

    MODULE-IDENTITY, OBJECT-TYPE, experimental
        FROM SNMPv2-SMI;


fizbin MODULE-IDENTITY
    LAST-UPDATED "9505241811Z"
    ORGANIZATION "IETF SNMPv2 Working Group"
    CONTACT-INFO
            "        Marshall T. Rose

             Postal: Dover Beach Consulting, Inc.
                     420 Whisman Court
                     Mountain View, CA  94043-2186
                     US

                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."
-- contact IANA for actual number
    ::= { experimental xx }


END








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


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.

   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 it to foster interoperability
   with older 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 an object assignment defined in some other
   information module.

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 }






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


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.

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

   A extended subset of the full capabilities of ASN.1 sub-typing is
   allowed, as appropriate to the underingly ASN.1 type.  Any such
   restriction on size, range, enumerations or repertoire 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 C 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 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.




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


   Finally, a label for a named-number enumeration must consist of one
   or more letters or digits (no hyphens), 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.)

7.1.2.  OCTET STRING

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

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

   Although there is no SMI-specified limitation on the number of
   enumerations (and therefore on the length of a value), 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 (no hyphens), 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.)

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.

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






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


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 a SYNTAX clause value of TimeStamp (a
   textual convention defined in [3]) indicating the time of the last
   discontinuity.

   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.  The
   maximum value can not be greater than 2^32-1 (4294967295 decimal).
   The value of a Gauge has its maximum value whenever the information
   being modeled is greater or equal to that maximum value; if the
   information being modeled subsequently decreases below the maximum
   value, the Gauge also decreases.

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.



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


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 a SYNTAX clause value of TimeStamp (a
   textual convention defined in [3]) indicating the time of the last
   discontinuity.

   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.







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


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,
   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,
   normally omitting the sub-typing information.  Further, these ASN.1
   types are always present (the 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