rfc2578.txt

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

   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 Values and Strings

   Some clauses in a macro invocation may take a character string as a
   textual value (e.g., the DESCRIPTION clause).  Other clauses take
   binary or hexadecimal strings (in any position where a non-negative
   number is allowed).

   A character string is preceded and followed by the quote character
   ("), and consists of an arbitrary number (possibly zero) of:

      - any 7-bit displayable ASCII characters except quote ("),
      - tab characters,
      - spaces, and
      - line terminator characters (\n or \r\n).

   The value of a character string is interpreted as ASCII.

   A binary string consists of a number (possibly zero) of zeros and
   ones preceded by a single (') and followed by either the pair ('B) or
   ('b), where the number is a multiple of eight.

   A hexadecimal string consists of an even number (possibly zero) of
   hexadecimal digits, preceded by a single (') and followed by either
   the pair ('H) or ('h).  Digits specified via letters can be in upper
   or lower case.

   Note that ASN.1 comments can not be enclosed inside any of these
   types of strings.


McCloghrie, et al.          Standards Track                    [Page 13]





RFC 2578                         SMIv2                        April 1999


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 to refer to objects even when
   there is no collision when IMPORTing symbols.

   Finally, if any of the ASN.1 named types and macros defined in this
   document, specifically:

        Counter32, Counter64, Gauge32, Integer32, IpAddress, MODULE-
        IDENTITY, NOTIFICATION-TYPE, Opaque, OBJECT-TYPE, OBJECT-
        IDENTITY, TimeTicks, Unsigned32,

   or any of those defined in [2] or [3], are used in an information
   module, then they must be imported using the IMPORTS statement.
   However, the following must not be included in an IMPORTS statement:

      - named types defined by ASN.1 itself, specifically: INTEGER,
        OCTET STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type,
      - the BITS construct.

3.3.  Exporting Symbols

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

3.4.  ASN.1 Comments

   ASN.1 comments can be included in an information module.  However, it
   is recommended that all substantive descriptions be placed within an
   appropriate DESCRIPTION clause.



McCloghrie, et al.          Standards Track                    [Page 14]





RFC 2578                         SMIv2                        April 1999


   ASN.1 comments 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.  Comments ended by a pair of hyphens have the
   effect of a single space character.

3.5.  OBJECT IDENTIFIER values

   An OBJECT IDENTIFIER value is an ordered list of non-negative
   numbers.  For the SMIv2, 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:

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

   (Note that this SMI does not recognize "new" well-known names, e.g.,
   as defined when the CCITT became the ITU.)

3.6.  OBJECT IDENTIFIER usage

   OBJECT IDENTIFIERs are used in information modules in two ways:

(1)  registration: the definition of a particular item is registered as
     a particular OBJECT IDENTIFIER value, and associated with a
     particular descriptor.  After such a registration, the semantics
     thereby associated with the value are not allowed to change, the
     OBJECT IDENTIFIER can not be used for any other registration, and
     the descriptor can not be changed nor associated with any other
     registration.  The following macros result in a registration:

          OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP,
          OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE,
          AGENT-CAPABILITIES.

(2)  assignment: a descriptor can be assigned to a particular OBJECT
     IDENTIFIER value.  For this usage, the semantics associated with
     the OBJECT IDENTIFIER value is not allowed to change, and a
     descriptor assigned to a particular OBJECT IDENTIFIER value cannot
     subsequently be assigned to another.  However, multiple descriptors
     can be assigned to the same OBJECT IDENTIFIER value.  Such
     assignments are specified in the following manner:


McCloghrie, et al.          Standards Track                    [Page 15]





RFC 2578                         SMIv2                        April 1999


          mib         OBJECT IDENTIFIER ::= { mgmt 1 }  -- from RFC1156
          mib-2       OBJECT IDENTIFIER ::= { mgmt 1 }  -- from RFC1213
          fredRouter  OBJECT IDENTIFIER ::= { flintStones 1 1 }
          barneySwitch OBJECT IDENTIFIER ::= { flintStones bedrock(2) 1 }

     Note while the above examples are legal, the following is not:

          dinoHost OBJECT IDENTIFIER ::= { flintStones bedrock 2 }

   A descriptor is allowed to be associated with both a registration and
   an assignment, providing both are associated with the same OBJECT
   IDENTIFIER value and semantics.

3.7.  Reserved Keywords

   The following are reserved keywords which must not be used as
   descriptors or module names:

        ABSENT ACCESS AGENT-CAPABILITIES ANY APPLICATION AUGMENTS BEGIN
        BIT BITS BOOLEAN BY CHOICE COMPONENT COMPONENTS CONTACT-INFO
        CREATION-REQUIRES Counter32 Counter64 DEFAULT DEFINED
        DEFINITIONS DEFVAL DESCRIPTION DISPLAY-HINT END ENUMERATED
        ENTERPRISE EXPLICIT EXPORTS EXTERNAL FALSE FROM GROUP Gauge32
        IDENTIFIER IMPLICIT IMPLIED IMPORTS INCLUDES INDEX INTEGER
        Integer32 IpAddress LAST-UPDATED MANDATORY-GROUPS MAX MAX-ACCESS
        MIN MIN-ACCESS MINUS-INFINITY MODULE MODULE-COMPLIANCE MODULE-
        IDENTITY NOTIFICATION-GROUP NOTIFICATION-TYPE NOTIFICATIONS NULL
        OBJECT OBJECT-GROUP OBJECT-IDENTITY OBJECT-TYPE OBJECTS OCTET OF
        OPTIONAL ORGANIZATION Opaque PLUS-INFINITY PRESENT PRIVATE
        PRODUCT-RELEASE REAL REFERENCE REVISION SEQUENCE SET SIZE STATUS
        STRING SUPPORTS SYNTAX TAGS TEXTUAL-CONVENTION TRAP-TYPE TRUE
        TimeTicks UNITS UNIVERSAL Unsigned32 VARIABLES VARIATION WITH
        WRITE-SYNTAX

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:


McCloghrie, et al.          Standards Track                    [Page 16]





RFC 2578                         SMIv2                        April 1999


        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.

   Note that reference in an IMPORTS clause or in clauses of SMIv2
   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.

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.






McCloghrie, et al.          Standards Track                    [Page 17]





RFC 2578                         SMIv2                        April 1999


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.

5.5.1.  Mapping of the DESCRIPTION sub-clause

   The DESCRIPTION sub-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
   specifying an OBJECT IDENTIFIER value to refer to the information
   module containing the invocation.

   Note that it is a common practice to use the value of the MODULE-
   IDENTITY macro as a subtree under which other OBJECT IDENTIFIER
   values assigned within the module are defined.  However, it is legal
   (and occasionally necessary) for the other OBJECT IDENTIFIER values
   assigned within the module to be unrelated to the OBJECT IDENTIFIER
   value of the MODULE-IDENTITY macro.

5.7.  Usage Example

   Consider how a skeletal MIB module might be constructed:  e.g.,

   FIZBIN-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE, experimental


McCloghrie, et al.          Standards Track                    [Page 18]





RFC 2578                         SMIv2                        April 1999


           FROM SNMPv2-SMI;


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

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