rfc1444.txt

中、英文RFC文档大全打包下载完全版 .

          Case, McCloghrie, Rose & Waldbusser                  [Page 16]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          4.6.  Usage Example

          Consider how a compliance statement might be included at the
          end of the MIB-II document [3], assuming that conformance
          groups were defined therein:

          mibIICompliances
                         OBJECT IDENTIFIER ::= { mibIIConformance 1 }
          mibIIGroups    OBJECT IDENTIFIER ::= { mibIIConformance 2 }

          mibIICompliance MODULE-COMPLIANCE
              STATUS  current
              DESCRIPTION
                      "The compliance statement for SNMPv2 entities
                      residing on systems which implement the Internet
                      suite of protocols."
              MODULE  -- compliance to the containing MIB module
                  MANDATORY-GROUPS   { systemGroup, snmpGroup }

                  GROUP       interfacesGroup
                  DESCRIPTION
                      "The interfaces group is mandatory for systems
                      with network interfaces."

                  GROUP       ipGroup
                  DESCRIPTION
                      "The ip group is mandatory for systems which
                      implement IP."

                  GROUP       icmpGroup
                  DESCRIPTION
                      "The icmp group is mandatory for systems which
                      implement ICMP."

                  GROUP       tcpGroup
                  DESCRIPTION
                      "The tcp group is mandatory for systems which
                      implement TCP."
                      OBJECT      tcpConnState
                      MIN-ACCESS  read-only
                      DESCRIPTION
                          "A compliant system need not allow
                           write-access to this object."

                  GROUP       udpGroup





          Case, McCloghrie, Rose & Waldbusser                  [Page 17]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


                  DESCRIPTION
                      "The udp group is mandatory for systems which
                      implement UDP."

                  GROUP       egpGroup
                  DESCRIPTION
                      "The egp group is mandatory for systems which
                      implement EGP."

          ::= { mibIICompliances 1 }

          According to this invocation, to claim alignment with the
          compliance statement named

               { mibIICompliances 1 }

          a system must implement RFC1213's systemGroup and snmpGroup
          conformance groups.  If the system implements any network
          interfaces, then RFC1213's interfacesGroup conformance group
          must be implemented.  Further, if the system implements any of
          the IP, ICMP, TCP, UDP, or EGP protocols, then the
          correspondent conformance group in RFC1213 must be
          implemented, if compliance is to be claimed.  Finally,
          although RFC1213 specifies that it makes "protocol sense" for
          the tcpConnState object to be writable, this specification
          allows the system to permit only read-only access and still
          claim compliance.























          Case, McCloghrie, Rose & Waldbusser                  [Page 18]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          5.  Mapping of the AGENT-CAPABILITIES macro

          The AGENT-CAPABILITIES macro is used to convey the
          capabilities present in a SNMPv2 entity acting in an agent
          role.  It should be noted that the expansion of the AGENT-
          CAPABILITIES macro is something which conceptually happens
          during implementation and not during run-time.

          When a MIB module is written, it is divided into units of
          conformance termed groups.  If a SNMPv2 entity acting in an
          agent role claims to implement a group, then it must implement
          each and every object within that group.  Of course, for
          whatever reason, a SNMPv2 entity might implement only a subset
          of the groups within a MIB module.  In addition, the
          definition of some MIB objects leave some aspects of the
          definition to the discretion of an implementor.

          Practical experience has demonstrated a need for concisely
          describing the capabilities of an agent with respect to one or
          more MIB modules.  The AGENT-CAPABILITIES macro allows an
          agent implementor to describe the precise level of support
          which an agent claims in regards to a MIB group, and to bind
          that description to the value of sysObjectID [3] associated
          with the agent, or to the value of an instance of the snmpORID
          object in the snmpORTable [4].  In particular, some objects
          may have restricted or augmented syntax or access-levels.

          If the AGENT-CAPABILITIES invocation is given to a
          management-station implementor, then that implementor can
          build management applications which optimize themselves when
          communicating with a particular agent.  For example, the
          management-station can maintain a database of these
          invocations.  When a management-station interacts with an
          agent, it retrieves the agent's sysObjectID [3].  Based on
          this, it consults the database.  If an entry is found, then
          the management application can optimize its behavior
          accordingly.

          Note that this binding to sysObjectID may not always suffice
          to define all MIB objects to which an agent can provide
          access.  In particular, this situation occurs where the agent
          dynamically learns of the objects it supports.  In these
          cases, the snmpORID column of snmpORTable [4] contains
          information which should be used in addition to sysObjectID.






          Case, McCloghrie, Rose & Waldbusser                  [Page 19]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          Note that the AGENT-CAPABILITIES macro specifies refinements
          or variations with respect to OBJECT-TYPE macros in MIB
          modules, NOT with respect to MODULE-COMPLIANCE macros in
          compliance statements.


          5.1.  Mapping of the PRODUCT-RELEASE clause

          The PRODUCT-RELEASE clause, which must be present, contains a
          textual description of the product release which includes this
          agent.


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


          5.3.  Mapping of the DESCRIPTION clause

          The DESCRIPTION clause, which must be present, contains a
          textual description of this agent.


          5.4.  Mapping of the REFERENCE clause

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


          5.5.  Mapping of the SUPPORTS clause

          The SUPPORTS clause, which need not be present, is repeatedly
          used to name each MIB module for which the agent claims a
          complete or partial implementation.  Each MIB module is named
          by its module name, and optionally, by its associated OBJECT
          IDENTIFIER as well.






          Case, McCloghrie, Rose & Waldbusser                  [Page 20]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          5.5.1.  Mapping of the INCLUDES clause

          The INCLUDES clause, which must be present for each use of the
          SUPPORTS clause, is used to name each MIB group associated
          with the SUPPORT clause, which the agent claims to implement.


          5.5.2.  Mapping of the VARIATION clause

          The VARIATION clause, which need not be present, is repeatedly
          used to name each MIB object which the agent implements in
          some variant or refined fashion with respect to the
          correspondent invocation of the OBJECT-TYPE macro.

          Note that the variation concept is meant for generic
          implementation restrictions, e.g., if the variation for an
          object depends on the values of other objects, then this
          should be noted in the appropriate DESCRIPTION clause.


          5.5.2.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 VARIATION 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 VARIATION clause are read.

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


          5.5.2.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 VARIATION clause when instances of that object
          are written.

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








          Case, McCloghrie, Rose & Waldbusser                  [Page 21]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          5.5.2.3.  Mapping of the ACCESS clause

          The ACCESS clause, which need not be present, is used to
          indicate the agent provides less than the maximal level of
          access to the object named in the correspondent VARIATION
          clause.

          The value "not-implemented" indicates the agent does not
          implement the object, and in the ordering of possible values
          is equivalent to "not-accessible".

          The value "write-only" is provided solely for backward
          compatibility, and shall not be used for newly-defined object
          types.  In the ordering of possible values, "write-only" is
          less than "not-accessible".


          5.5.2.4.  Mapping of the CREATION-REQUIRES clause

          The CREATION-REQUIRES clause, which need not be present, is
          used to name the columnar objects of a conceptual row to which
          values must be explicitly assigned, by a management protocol
          set operation, before the agent will allow the instance of the
          status column of that row to be set to `active'.  (Consult the
          definition of RowStatus [6].)

          If the conceptual row does not have a status column (i.e., the
          objects corresponding to the conceptual table were defined
          using the mechanisms in [7,8]), then the CREATION-REQUIRES
          clause, which need not be present, is used to name the
          columnar objects of a conceptual row to which values must be
          explicitly assigned, by a management protocol set operation,
          before the agent will create new instances of objects in that
          row.

          This clause must not present unless the object named in the
          correspondent VARIATION clause is a conceptual row, i.e., has
          a syntax which resolves to a SEQUENCE containing columnar
          objects.  The objects named in the value of this clause
          usually will refer to columnar objects in that row.  However,
          objects unrelated to the conceptual row may also be specified.

          All objects which are named in the CREATION-REQUIRES clause
          for a conceptual row, and which are columnar objects of that
          row, must have an access level of "read-create".





          Case, McCloghrie, Rose & Waldbusser                  [Page 22]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          5.5.2.5.  Mapping of the DEFVAL clause

          The DEFVAL clause, which need not be present, is used to
          provide a refined DEFVAL value for the object named in the
          correspondent VARIATION clause.  The semantics of this value
          are identical to those of the OBJECT-TYPE macro's DEFVAL
          clause.


          5.5.2.6.  Mapping of the DESCRIPTION clause

          The DESCRIPTION clause, which must be present for each use of
          the VARIATION clause, contains a textual description of the
          variant or refined implementation.


          5.6.  Mapping of the AGENT-CAPABILITIES value

          The value of an invocation of the AGENT-CAPABILITIES macro is
          an OBJECT IDENTIFIER, which names the value of sysObjectID [3]
          or snmpORID [4] for which this capabilities statement is
          valid.




























          Case, McCloghrie, Rose & Waldbusser                  [Page 23]





          RFC 1444      Conformance Statements for SNMPv2     April 1993


          5.7.  Usage Example

          Consider how a capabilities statement for an agent might be
          described:

          exampleAgent AGENT-CAPABILITIES
              PRODUCT-RELEASE      "ACME Agent release 1.1 for 4BSD"
              STATUS               current
              DESCRIPTION          "ACME agent for 4BSD"

              SUPPORTS             RFC1213-MIB
                  INCLUDES         { systemGroup, interfacesGroup,
                                     atGroup, ipGroup, icmpGroup,
                                     tcpGroup, udpGroup, snmpGroup }

                  VARIATION        ifAdminStatus
                      SYNTAX       INTEGER { up(1), down(2) }
                      DESCRIPTION  "Unable to set test mode on 4BSD"

                  VARIATION        ifOperStatus
                      SYNTAX       INTEGER { up(1), down(2) }
                      DESCRIPTION  "Information limited on 4BSD"

                  VARIATION        atEntry
                      CREATION-REQUIRES { atPhysAddress }
                      DESCRIPTION  "Address mappings on 4BSD require
                                   both protocol and media addresses"

                  VARIATION        ipDefaultTTL
                      SYNTAX       INTEGER (255..255)
                      DESCRIPTION  "Hard-wired on 4BSD"

                  VARIATION        ipInAddrErrors
                      ACCESS       not-implemented
                      DESCRIPTION  "Information not available on 4BSD"

                  VARIATION        ipRouteType
                      SYNTAX       INTEGER { direct(3), indirect(4) }
                      WRITE-SYNTAX INTEGER { invalid(2), direct(3),
                                             indirect(4) }
                      DESCRIPTION  "Information limited on 4BSD"