rfc1904.txt

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

SNMPv2 Working Group        Standards Track                     [Page 6]

RFC 1904           Conformance Statements for SNMPv2        January 1996


                | "read-create"

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


-- definitions for capabilities statements

AGENT-CAPABILITIES MACRO ::=
BEGIN
    TYPE NOTATION ::=
                  "PRODUCT-RELEASE" Text
                  "STATUS" Status
                  "DESCRIPTION" Text
                  ReferPart
                  ModulePart

    VALUE NOTATION ::=
                  value(VALUE OBJECT IDENTIFIER)

    Status ::=
                  "current"
                | "obsolete"

    ReferPart ::=
                "REFERENCE" Text
              | empty

    ModulePart ::=
                  Modules
                | empty
    Modules ::=
                  Module
                | Modules Module
    Module ::=
                  -- name of module --
                  "SUPPORTS" ModuleName
                  "INCLUDES" "{" Groups "}"
                  VariationPart

    ModuleName ::=
                  identifier ModuleIdentifier
    ModuleIdentifier ::=
                  value(ModuleID OBJECT IDENTIFIER)
                | empty

    Groups ::=



SNMPv2 Working Group        Standards Track                     [Page 7]

RFC 1904           Conformance Statements for SNMPv2        January 1996


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

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

    Variation ::=
                  ObjectVariation
                | NotificationVariation

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

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

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

    -- must be a refinement for object's SYNTAX clause
    WriteSyntaxPart ::=
                  "WRITE-SYNTAX" type(WriteSYNTAX)
                | empty

    AccessPart ::=
                  "ACCESS" Access
                | empty

    Access ::=
                  "not-implemented"
                -- only "not-implemented" for notifications
                | "accessible-for-notify"



SNMPv2 Working Group        Standards Track                     [Page 8]

RFC 1904           Conformance Statements for SNMPv2        January 1996


                | "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(Cell ObjectName)

    DefValPart ::=
                  "DEFVAL" "{" value(Defval ObjectSyntax) "}"
                | empty

    -- uses the NVT ASCII character set
    Text ::= """" string """"
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, a SNMPv2 entity acting in an agent role
   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, a SNMPv2 entity must
   accordingly be able to reasonably influence the underlying managed
   entity.  If a SNMPv2 entity acting in an agent role can not implement
   an object, the management protocol provides for the SNMPv2 entity to
   return an exception or error, e.g, noSuchObject [4].  Under no
   circumstances shall a SNMPv2 entity 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].




SNMPv2 Working Group        Standards Track                     [Page 9]

RFC 1904           Conformance Statements for SNMPv2        January 1996


3.1.  Mapping of the OBJECTS clause

   The OBJECTS clause, which must be present, is used to name each
   object contained in the conformance group.  Each of the named 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.

3.2.  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 the group to foster
   interoperability with older implementations.

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 a group  defined in some other information module.
   This is useful when de-osifying a MIB module produced by some other
   organization.

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.







SNMPv2 Working Group        Standards Track                    [Page 10]

RFC 1904           Conformance Statements for SNMPv2        January 1996


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 SNMPv2 entity."
    ::= { 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 name each
   notification contained in the conformance group.  Each of the named
   notifications must be defined in the same information module as the
   NOTIFICATION-GROUP macro appears.

4.2.  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 the group to foster



SNMPv2 Working Group        Standards Track                    [Page 11]

RFC 1904           Conformance Statements for SNMPv2        January 1996


   interoperability with older implementations.

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 a group defined in some other information module.
   This is useful when de-osifying a MIB module produced by some other
   organization.

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:

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

According to this invocation, the conformance group named

     { snmpMIBGroups 1 }

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.



SNMPv2 Working Group        Standards Track                    [Page 12]