rfc2580.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,711 行 · 第 1/4 页

                | Groups "," Group
    Group ::=
                  value(OBJECT IDENTIFIER)

    VariationPart ::=
                  Variations
                | empty
    Variations ::=
                  Variation
                | Variations Variation

    Variation ::=
                  ObjectVariation
                | NotificationVariation

    NotificationVariation ::=
                  "VARIATION" value(NotificationName)
                  AccessPart
                  "DESCRIPTION" Text

    ObjectVariation ::=
                  "VARIATION" value(ObjectName)
                  SyntaxPart
                  WriteSyntaxPart
                  AccessPart
                  CreationPart
                  DefValPart
                  "DESCRIPTION" Text

    -- must be a refinement for object's SYNTAX clause
    SyntaxPart ::= "SYNTAX" Syntax
                | empty

    WriteSyntaxPart ::= "WRITE-SYNTAX" Syntax
                | empty

    Syntax ::=    -- Must be one of the following:
                       -- a base type (or its refinement),
                       -- a textual convention (or its refinement), or
                       -- a BITS pseudo-type


McCloghrie, et al.          Standards Track                     [Page 8]





RFC 2580            Conformance Statements for SMIv2          April 1999


                  type
                | "BITS" "{" NamedBits "}"

    NamedBits ::= NamedBit
                | NamedBits "," NamedBit

    NamedBit ::= identifier "(" number ")" -- number is nonnegative

    AccessPart ::=
                  "ACCESS" Access
                | empty

    Access ::=
                  "not-implemented"
                -- only "not-implemented" for notifications
                | "accessible-for-notify"
                | "read-only"
                | "read-write"
                | "read-create"
                -- following is for backward-compatibility only
                | "write-only"

    CreationPart ::=
                  "CREATION-REQUIRES" "{" Cells "}"
                | empty
    Cells ::=
                  Cell
                | Cells "," Cell
    Cell ::=
                  value(ObjectName)

    DefValPart ::= "DEFVAL" "{" Defvalue "}"
                | empty

    Defvalue ::=  -- must be valid for the object's syntax
                  -- in this macro's SYNTAX clause, if present,
                  -- or if not, in object's OBJECT-TYPE macro
                  value(ObjectSyntax)
                | "{" BitsValue "}"

    BitsValue ::= BitNames
                | empty

    BitNames ::=  BitName
                | BitNames "," BitName

    BitName ::= identifier



McCloghrie, et al.          Standards Track                     [Page 9]





RFC 2580            Conformance Statements for SMIv2          April 1999


    -- a character string as defined in [2]
    Text ::= value(IA5String)
END

END


3.  Mapping of the OBJECT-GROUP macro

   For conformance purposes, it is useful to define a collection of
   related managed objects.  The OBJECT-GROUP macro is used to define
   each such collection of related objects.  It should be noted that the
   expansion of the OBJECT-GROUP macro is something which conceptually
   happens during implementation and not during run-time.

   To "implement" an object, an agent must return a reasonably accurate
   value for management protocol retrieval operations; similarly, if the
   object is writable, then in response to a management protocol set
   operation, an agent must accordingly be able to reasonably influence
   the underlying managed entity.  If an agent can not implement an
   object, the management protocol provides for it to return an
   exception or error, e.g, noSuchObject [4].  Under no circumstances
   shall an agent return a value for objects which it does not implement
   -- it must always return the appropriate exception or error, as
   described in the protocol specification [4].

   Note that the OBJECT-GROUP macro itself provides no conformance
   information.  Rather, conformance information is specified through
   the inclusion of defined groups in a MODULE-COMPLIANCE macro.

3.1.  Mapping of the OBJECTS clause

   The OBJECTS clause, which must be present, is used to specify each
   object contained in the conformance group.  Each of the specified
   objects must be defined in the same information module as the
   OBJECT-GROUP macro appears, and must have a MAX-ACCESS clause value
   of "accessible-for-notify", "read-only", "read-write", or "read-
   create".

   It is required that every object defined in an information module
   with a MAX-ACCESS clause other than "not-accessible" be contained in
   at least one object group.  This avoids the common error of adding a
   new object to an information module and forgetting to add the new
   object to a group.






McCloghrie, et al.          Standards Track                    [Page 10]





RFC 2580            Conformance Statements for SMIv2          April 1999


3.2.  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 the group
   should no longer be used for defining conformance.  While the value
   "deprecated" also indicates an obsolete definition, it permits
   new/continued use of conformance definitions using this group.

3.3.  Mapping of the DESCRIPTION clause

   The DESCRIPTION clause, which must be present, contains a textual
   definition of that group, along with a description of any relations
   to other groups.  Note that generic compliance requirements should
   not be stated in this clause.  However, implementation relationships
   between this group and other groups may be defined in this clause.

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

3.5.  Mapping of the OBJECT-GROUP value

   The value of an invocation of the OBJECT-GROUP macro is the name of
   the group, which is an OBJECT IDENTIFIER, an administratively
   assigned name.



















McCloghrie, et al.          Standards Track                    [Page 11]





RFC 2580            Conformance Statements for SMIv2          April 1999


3.6.  Usage Example

   The SNMP Group [3] is described:

   snmpGroup OBJECT-GROUP
       OBJECTS { snmpInPkts,
                 snmpInBadVersions,
                 snmpInASNParseErrs,
                 snmpBadOperations,
                 snmpSilentDrops,
                 snmpProxyDrops,
                 snmpEnableAuthenTraps }
       STATUS  current
       DESCRIPTION
               "A collection of objects providing basic instrumentation
               and control of an agent."
      ::= { snmpMIBGroups 8 }


   According to this invocation, the conformance group named

        { snmpMIBGroups 8 }

   contains 7 objects.

4.  Mapping of the NOTIFICATION-GROUP macro

   For conformance purposes, it is useful to define a collection of
   notifications.  The NOTIFICATION-GROUP macro serves this purpose.  It
   should be noted that the expansion of the NOTIFICATION-GROUP macro is
   something which conceptually happens during implementation and not
   during run-time.

4.1.  Mapping of the NOTIFICATIONS clause

   The NOTIFICATIONS clause, which must be present, is used to specify
   each notification contained in the conformance group.  Each of the
   specified notifications must be defined in the same information
   module as the NOTIFICATION-GROUP macro appears.

   It is required that every notification defined in an information
   module be contained in at least one notification group.







McCloghrie, et al.          Standards Track                    [Page 12]





RFC 2580            Conformance Statements for SMIv2          April 1999


4.2.  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 this group
   should no longer be used for defining conformance.  While the value
   "deprecated" also indicates an obsolete definition, it permits
   new/continued use of conformance definitions using this group.

4.3.  Mapping of the DESCRIPTION clause

   The DESCRIPTION clause, which must be present, contains a textual
   definition of the group, along with a description of any relations to
   other groups.  Note that generic compliance requirements should not
   be stated in this clause.  However, implementation relationships
   between this group and other groups may be defined in this clause.

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

4.5.  Mapping of the NOTIFICATION-GROUP value

   The value of an invocation of the NOTIFICATION-GROUP macro is the
   name of the group, which is an OBJECT IDENTIFIER, an administratively
   assigned name.

4.6.  Usage Example

   The SNMP Basic Notifications Group [3] is described:















McCloghrie, et al.          Standards Track                    [Page 13]





RFC 2580            Conformance Statements for SMIv2          April 1999


   snmpBasicNotificationsGroup NOTIFICATION-GROUP
       NOTIFICATIONS { coldStart, authenticationFailure }
       STATUS        current
       DESCRIPTION
               "The two notifications which an agent is required to
               implement."
      ::= { snmpMIBGroups 7 }

   According to this invocation, the conformance group named

        { snmpMIBGroups 7 }

   contains 2 notifications.

5.  Mapping of the MODULE-COMPLIANCE macro

   The MODULE-COMPLIANCE macro is used to convey a minimum set of
   requirements with respect to implementation of one or more MIB
   modules.  It should be noted that the expansion of the MODULE-
   COMPLIANCE macro is something which conceptually happens during
   implementation and not during run-time.

   A requirement on all "standard" MIB modules is that a corresponding
   MODULE-COMPLIANCE specification is also defined, either in the same
   information module or in a companion information module.

5.1.  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 this
   MODULE-COMPLIANCE specification no longer specifies a valid
   definition of conformance.  While the value "deprecated" also
   indicates an obsolete definition, it permits new/continued use of the
   MODULE-COMPLIANCE specification.

5.2.  Mapping of the DESCRIPTION clause

   The DESCRIPTION clause, which must be present, contains a textual
   definition of this compliance statement and should embody any
   information which would otherwise be communicated in any ASN.1
   commentary annotations associated with the statement.






McCloghrie, et al.          Standards Track                    [Page 14]





RFC 2580            Conformance Statements for SMIv2          April 1999


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

5.4.  Mapping of the MODULE clause

   The MODULE clause, which must be present, is repeatedly used to name
   each MIB module for which compliance requirements are being
   specified.  Each MIB module is named by its module name, and
   optionally, by its associated OBJECT IDENTIFIER as well.  The module
   name can be omitted when the MODULE-COMPLIANCE invocation occurs
   inside a MIB module, to refer to the encompassing MIB module.

5.4.1.  Mapping of the MANDATORY-GROUPS clause

   The MANDATORY-GROUPS clause, which need not be present, names the one
   or more object or notification groups within the correspondent MIB
   module which are unconditionally mandatory for implementation.  If an
   agent claims compliance to the MIB module, then it must implement
   each and every object and notification within each conformance group
   listed.  That is, if an agent returns a noSuchObject exception in