rfc1902.txt

RFC 的详细文档！

    ReferPart ::=
                  "REFERENCE" Text
                | empty

    IndexPart ::=
                  "INDEX"    "{" IndexTypes "}"
                | "AUGMENTS" "{" Entry      "}"
                | empty
    IndexTypes ::=
                  IndexType
                | IndexTypes "," IndexType
    IndexType ::=
                  "IMPLIED" Index
                | Index
    Index ::=
                    -- use the SYNTAX value of the
                    -- correspondent OBJECT-TYPE invocation
                  value(Indexobject ObjectName)
    Entry ::=
                    -- use the INDEX value of the
                    -- correspondent OBJECT-TYPE invocation
                  value(Entryobject ObjectName)

    DefValPart ::=



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


                  "DEFVAL" "{" value(Defval Syntax) "}"
                | empty

    -- uses the NVT ASCII character set
    Text ::= """" string """"
END


-- definitions for notifications

NOTIFICATION-TYPE MACRO ::=
BEGIN
    TYPE NOTATION ::=
                  ObjectsPart
                  "STATUS" Status
                  "DESCRIPTION" Text
                  ReferPart

    VALUE NOTATION ::=
                  value(VALUE NotificationName)

    ObjectsPart ::=
                  "OBJECTS" "{" Objects "}"
                | empty
    Objects ::=
                  Object
                | Objects "," Object
    Object ::=
                  value(Name ObjectName)

    Status ::=
                  "current"
                | "deprecated"
                | "obsolete"

    ReferPart ::=
                "REFERENCE" Text
              | empty

    -- uses the NVT ASCII character set
    Text ::= """" string """"
END

-- definitions of administrative identifiers

zeroDotZero    OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION



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


            "A value used for null identifiers."
    ::= { 0 0 }

END

3.  Information Modules

   An "information module" is an ASN.1 module defining information
   relating to network management.

   The SMI describes how to use a subset of ASN.1 to define an
   information module.  Further, additional restrictions are placed on
   "standard" information modules.  It is strongly recommended that
   "enterprise-specific" information modules also adhere to these
   restrictions.

   Typically, there are three kinds of information modules:

(1)  MIB modules, which contain definitions of inter-related managed
     objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros;

(2)  compliance statements for MIB modules, which make use of the
     MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and,

(3)  capability statements for agent implementations which make use of
     the AGENT-CAPABILITIES macros [2].

   This classification scheme does not imply a rigid taxonomy.  For
   example, a "standard" information module will normally include
   definitions of managed objects and a compliance statement.
   Similarly, an "enterprise-specific" information module might include
   definitions of managed objects and a capability statement.  Of
   course, a "standard" information module may not contain capability
   statements.

   The constructs of ASN.1 allowed in SNMPv2 information modules
   include: the IMPORTS clause, value definitions for OBJECT
   IDENTIFIERs, type definitions for SEQUENCEs (with restrictions),
   ASN.1 type assignments of the restricted ASN.1 types allowed in
   SNMPv2, and instances of ASN.1 macros defined in this document and in
   other documents [2, 3] of the SNMPv2 framework.  Additional ASN.1
   macros may not be defined in SNMPv2 information modules.

   The names of all standard information modules must be unique (but
   different versions of the same information module should have the
   same name).  Developers of enterprise information modules are
   encouraged to choose names for their information modules that will
   have a low probability of colliding with standard or other enterprise



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


   information modules. An information module may not use the ASN.1
   construct of placing an object identifier value between the module
   name and the "DEFINITIONS" keyword.

   All information modules start with exactly one invocation of the
   MODULE-IDENTITY macro, which provides contact information as well as
   revision history to distinguish between versions of the same
   information module.  This invocation must appear immediately after
   any IMPORTs statements.

3.1.  Macro Invocation

   Within an information module, each macro invocation appears as:

     <descriptor> <macro> <clauses> ::= <value>

   where <descriptor> corresponds to an ASN.1 identifier, <macro> names
   the macro being invoked, and <clauses> and <value> depend on the
   definition of the macro.  (Note that this definition of a descriptor
   applies to all macros defined in this memo and in [2].)

   For the purposes of this specification, an ASN.1 identifier consists
   of one or more letters or digits, and its initial character must be a
   lower-case letter.  (Note that hyphens are not allowed by this
   specification, even though hyphen is allowed by [1].  This
   restriction enables arithmetic expressions in languages which use the
   minus sign to reference these descriptors without ambiguity.)

   For all descriptors appearing in an information module, the
   descriptor shall be unique and mnemonic, and shall not exceed 64
   characters in length.  (However, descriptors longer than 32
   characters are not recommended.)  This promotes a common language for
   humans to use when discussing the information module and also
   facilitates simple table mappings for user-interfaces.

   The set of descriptors defined in all "standard" information modules
   shall be unique.

   Finally, by convention, if the descriptor refers to an object with a
   SYNTAX clause value of either Counter32 or Counter64, then the
   descriptor used for the object should denote plurality.

3.1.1.  Textual Clauses

   Some clauses in a macro invocation may take a textual value (e.g.,
   the DESCRIPTION clause).  Note that, in order to conform to the ASN.1
   syntax, the entire value of these clauses must be enclosed in double
   quotation marks, and therefore cannot itself contain double quotation



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


   marks, although the value may be multi-line.

3.2.  IMPORTing Symbols

   To reference an external object, the IMPORTS statement must be used
   to identify both the descriptor and the module in which the
   descriptor is defined, where the module is identified by its ASN.1
   module name.

   Note that when symbols from "enterprise-specific" information modules
   are referenced  (e.g., a descriptor), there is the possibility of
   collision.  As such, if different objects with the same descriptor
   are IMPORTed, then this ambiguity is resolved by prefixing the
   descriptor with the name of the information module and a dot ("."),
   i.e.,

     "module.descriptor"

   (All descriptors must be unique within any information module.)

   Of course, this notation can be used even when there is no collision
   when IMPORTing symbols.

   Finally, the IMPORTS statement may not be used to import an ASN.1
   named type which corresponds to either the SEQUENCE or SEQUENCE OF
   type.

3.3.  Exporting Symbols

   The ASN.1 EXPORTS statement is not allowed in SNMPv2 information
   modules.  All items defined in an information module are
   automatically exported.

3.4.  ASN.1 Comments

   Comments in ASN.1 commence with a pair of adjacent hyphens and end
   with the next pair of adjacent hyphens or at the end of the line,
   whichever occurs first.

3.5.  OBJECT IDENTIFIER values

   An OBJECT IDENTIFIER value is an ordered list of non-negative
   numbers.  For the SNMPv2 framework, each number in the list is
   referred to as a sub-identifier, there are at most 128 sub-
   identifiers in a value, and each sub-identifier has a maximum value
   of 2^32-1 (4294967295 decimal).  All OBJECT IDENTIFIER values have at
   least two sub-identifiers, where the value of the first sub-
   identifier is one of the following well-known names:



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


     Value   Name
       0     ccitt
       1     iso
       2     joint-iso-ccitt

4.  Naming Hierarchy

   The root of the subtree administered by the Internet Assigned Numbers
   Authority (IANA) for the Internet is:

     internet       OBJECT IDENTIFIER ::= { iso 3 6 1 }

   That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
   prefix:

     1.3.6.1.

   Several branches underneath this subtree are used for network
   management:

     mgmt           OBJECT IDENTIFIER ::= { internet 2 }
     experimental   OBJECT IDENTIFIER ::= { internet 3 }
     private        OBJECT IDENTIFIER ::= { internet 4 }
     enterprises    OBJECT IDENTIFIER ::= { private 1 }

   However, the SMI does not prohibit the definition of objects in other
   portions of the object tree.

   The mgmt(2) subtree is used to identify "standard" objects.

   The experimental(3) subtree is used to identify objects being
   designed by working groups of the IETF.  If an information module
   produced by a working group becomes a "standard" information module,
   then at the very beginning of its entry onto the Internet standards
   track, the objects are moved under the mgmt(2) subtree.

   The private(4) subtree is used to identify objects defined
   unilaterally.  The enterprises(1) subtree beneath private is used,
   among other things, to permit providers of networking subsystems to
   register models of their products.

5.  Mapping of the MODULE-IDENTITY macro

   The MODULE-IDENTITY macro is used to provide contact and revision
   history for each information module.  It must appear exactly once in
   every information module.  It should be noted that the expansion of
   the MODULE-IDENTITY macro is something which conceptually happens
   during implementation and not during run-time.



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


   Note that reference in an IMPORTS clause or in clauses of SNMPv2
   macros to an information module is NOT through the use of the
   'descriptor' of a MODULE-IDENTITY macro; rather, an information
   module is referenced through specifying its module name.

5.1.  Mapping of the LAST-UPDATED clause

   The LAST-UPDATED clause, which must be present, contains the date and
   time that this information module was last edited.  The date and time
   are represented in UTC Time format (see Appendix B).

5.2.  Mapping of the ORGANIZATION clause

   The ORGANIZATION clause, which must be present, contains a textual
   description of the organization under whose auspices this information
   module was developed.

5.3.  Mapping of the CONTACT-INFO clause

   The CONTACT-INFO clause, which must be present, contains the name,
   postal address, telephone number, and electronic mail address of the
   person to whom technical queries concerning this information module
   should be sent.

5.4.  Mapping of the DESCRIPTION clause

   The DESCRIPTION clause, which must be present, contains a high-level
   textual description of the contents of this information module.

5.5.  Mapping of the REVISION clause

   The REVISION clause, which need not be present, is repeatedly used to
   describe the revisions (including the initial version) made to this
   information module, in reverse chronological order (i.e., most recent
   first).  Each instance of this clause contains the date and time of
   the revision.  The date and time are represented in UTC Time format
   (see Appendix B).

5.5.1.  Mapping of the DESCRIPTION sub-clause

   The DESCRIPTION clause, which must be present for each REVISION
   clause, contains a high-level textual description of the revision
   identified in that REVISION clause.

5.6.  Mapping of the MODULE-IDENTITY value

   The value of an invocation of the MODULE-IDENTITY macro is an OBJECT
   IDENTIFIER.  As such, this value may be authoritatively used when



SNMPv2 Working Group        Standards Track                    [Page 13]