rfc1444.txt

RFC 的详细文档！

              Variation ::=
                            "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"
                          | "read-only"
                          | "read-write"
                          | "read-create"
                          -- following is for backward-compatibility only
                          | "write-only"

              CreationPart ::=
                            "CREATION-REQUIRES" "{" Cells "}"
                          | empty

              Cells ::=





          Case, McCloghrie, Rose & Waldbusser                   [Page 8]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


                            Cell
                          | Cells "," Cell

              Cell ::=
                            value(Cell ObjectName)

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

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


          END


































          Case, McCloghrie, Rose & Waldbusser                   [Page 9]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


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


          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 "read-only", "read-write", or "read-create".


          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.


          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





          Case, McCloghrie, Rose & Waldbusser                  [Page 10]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          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.































          Case, McCloghrie, Rose & Waldbusser                  [Page 11]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          3.6.  Usage Example

          Consider how the system group from MIB-II [3] might be
          described:

          systemGroup OBJECT-GROUP
              OBJECTS     { sysDescr, sysObjectID, sysUpTime,
                            sysContact, sysName, sysLocation,
                            sysServices }
              STATUS  current
              DESCRIPTION
                      "The system group defines objects which are common
                      to all managed systems."
              ::= { mibIIGroups 1 }

          According to this invocation, the conformance group named

               { mibIIGroups 1 }

          contains 7 objects.






























          Case, McCloghrie, Rose & Waldbusser                  [Page 12]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


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


          4.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 that object is obsolete,
          but that an implementor may wish to support that object to
          foster interoperability with older implementations.


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


          4.3.  Mapping of the REFERENCE clause

          The REFERENCE clause, which need not be present, contains a
          textual cross-reference to a compliance statement defined in
          some other information module.


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





          Case, McCloghrie, Rose & Waldbusser                  [Page 13]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          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.


          4.4.1.  Mapping of the MANDATORY-GROUPS clause

          The MANDATORY-GROUPS clause, which need not be present, names
          the one or more groups within the correspondent MIB module
          which are unconditionally mandatory for implementation.  If a
          SNMPv2 entity acting in an agent role claims compliance to the
          MIB module, then it must implement each and every object
          within each conformance group listed.  That is, if a SNMPv2
          entity returns a noSuchObject exception in response to a
          management protocol get operation [5] for any object within
          any mandatory conformance group for every MIB view, then that
          SNMPv2 entity is not a conformant implementation of the MIB
          module.


          4.4.2.  Mapping of the GROUP clause

          The GROUP clause which need not be present, is repeatedly used
          to name each MIB group which is conditionally mandatory or
          unconditionally optional for compliance to the MIB module.  A
          MIB group named in a GROUP clause must be absent from the
          correspondent MANDATORY-GROUPS clause.

          Conditionally mandatory groups include those which are
          mandatory only if a particular protocol is implemented, or
          only if another group is implemented.  A GROUP clause's
          DESCRIPTION specifies the conditions under which the group is
          conditionally mandatory.

          A MIB group which is named in neither a MANDATORY-GROUPS
          clause nor a GROUP clause, is unconditionally optional for
          compliance to the MIB module.


          4.4.3.  Mapping of the OBJECT clause

          The OBJECT clause which need not be present, is repeatedly
          used to name each MIB object for which compliance has a





          Case, McCloghrie, Rose & Waldbusser                  [Page 14]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          refined requirement with respect to the MIB module definition.
          The MIB object must be present in one of the conformance
          groups named in the correspondent MANDATORY-GROUPS clause or
          GROUP clauses.


          4.4.3.1.  Mapping of the SYNTAX clause

          The SYNTAX clause, which need not be present, is used to
          provide a refined SYNTAX for the object named in the
          correspondent OBJECT clause.  Note that if this clause and a
          WRITE-SYNTAX clause are both present, then this clause only
          applies when instances of the object named in the
          correspondent OBJECT clause are read.

          Consult Section 10 of [2] for more information on refined
          syntax.


          4.4.3.2.  Mapping of the WRITE-SYNTAX clause

          The WRITE-SYNTAX clause, which need not be present, is used to
          provide a refined SYNTAX for the object named in the
          correspondent OBJECT clause when instances of that object are
          written.

          Consult Section 10 of [2] for more information on refined
          syntax.


          4.4.3.3.  Mapping of the MIN-ACCESS clause

          The MIN-ACCESS clause, which need not be present, is used to
          define the minimal level of access for the object named in the
          correspondent OBJECT clause.  If this clause is absent, the
          minimal level of access is the same as the maximal level
          specified in the correspondent invocation of the OBJECT-TYPE
          macro.  If present, this clause must not specify a greater
          level of access than is specified in the correspondent
          invocation of the OBJECT-TYPE macro.

          The level of access for certain types of objects is fixed
          according to their syntax definition.  These types are:
          conceptual tables and rows, auxiliary objects, and objects
          with the syntax of Counter32, Counter64, or certain types of





          Case, McCloghrie, Rose & Waldbusser                  [Page 15]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          textual conventions (e.g., RowStatus [6]).  A MIN-ACCESS
          clause should not be present for such objects.

          An implementation is compliant if the level of access it
          provides is greater or equal to the minimal level in the
          MODULE-COMPLIANCE macro and less or equal to the maximal level
          in the OBJECT-TYPE macro.


          4.4.3.4.  Mapping of the DESCRIPTION clause

          The DESCRIPTION clause must be present for each use of the
          GROUP or OBJECT clause.  For an OBJECT clause, it contains a
          textual description of the refined compliance requirement.
          For a GROUP clause, it contains a textual description of the
          conditions under which the group is conditionally mandatory or
          unconditionally optional.


          4.5.  Mapping of the MODULE-COMPLIANCE value

          The value of an invocation of the MODULE-COMPLIANCE macro is
          an OBJECT IDENTIFIER.  As such, this value may be
          authoritatively used when referring to the compliance
          statement embodied by that invocation of the macro.