rfc1904.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

RFC 1904           Conformance Statements for SNMPv2        January 1996


6.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 or
   notification named in the correspondent VARIATION clause.

   The only value applicable to notifications is "not-implemented".

   The value "not-implemented" indicates the agent does not implement
   the object or notification, 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".

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

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








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


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

6.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 of the object or notification.

6.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 sysORID [3] for which
   this capabilities statement is valid.

6.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             SNMPv2-MIB
        INCLUDES         { systemGroup, snmpGroup, snmpSetGroup,
                           snmpBasicNotificationsGroup }

        VARIATION        coldStart
            DESCRIPTION  "A coldStart trap is generated on all
                         reboots."

    SUPPORTS             IF-MIB
        INCLUDES         { ifGeneralGroup, ifPacketGroup }

        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"




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


    SUPPORTS             IP-MIB
        INCLUDES         { ipGroup, icmpGroup }

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

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

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

    SUPPORTS             TCP-MIB
        INCLUDES         { tcpGroup }
        VARIATION        tcpConnState
            ACCESS       read-only
            DESCRIPTION  "Unable to set this on 4BSD"

    SUPPORTS             UDP-MIB
        INCLUDES         { udpGroup }

    SUPPORTS             EVAL-MIB
        INCLUDES         { functionsGroup, expressionsGroup }
        VARIATION        exprEntry
            CREATION-REQUIRES { evalString }
            DESCRIPTION "Conceptual row creation supported"

    ::= { acmeAgents 1 }

   According to this invocation, an agent with a sysORID value of

     { acmeAgents 1 }

   supports six MIB modules.

   From SNMPv2-MIB, five conformance groups are supported.

   From IF-MIB, the ifGeneralGroup and ifPacketGroup groups are
   supported.  However, the objects ifAdminStatus and ifOperStatus have
   a restricted syntax.







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


   From IP-MIB, all objects in the ipGroup and icmpGroup are supported
   except ipInAddrErrors, while ipDefaultTTL has a restricted range, and
   when creating a new instance in the ipNetToMediaTable, the set-
   request must create an instance of atPhysAddress.

   From TCP-MIB, the tcpGroup is supported except that tcpConnState is
   available only for reading.

   From UDP-MIB, the udpGroup is fully supported.

   From the EVAL-MIB, all the objects contained in the functionsGroup
   and expressionsGroup conformance groups are supported, without
   variation.  In addition, creation of new instances in the expr table
   is supported.

7.  Extending an Information Module

   As experience is gained with a published information module, it may
   be desirable to revise that information module.

   Section 10 of [2] defines the rules for extending an information
   module.  The remainder of this section defines how conformance
   groups, compliance statements, and capabilities statements may be
   extended.

7.1.  Conformance Groups

   If any non-editorial change is made to any clause of an object group
   then the OBJECT IDENTIFIER value associated with that object group
   must also be changed, along with its associated descriptor.

7.2.  Compliance Definitions

   If any non-editorial change is made to any clause of a compliance
   definition, then the OBJECT IDENTIFIER value associated with that
   compliance definition must also be changed, along with its associated
   descriptor.

7.3.  Capabilities Definitions

   If any non-editorial change is made to any clause of a capabilities
   definition, then the OBJECT IDENTIFIER value associated with that
   capabilities definition must also be changed, along with its
   associated descriptor.







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


8.  Security Considerations

   Security issues are not discussed in this memo.

9.  Editor's Address

   Keith McCloghrie
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   US

   Phone: [phone]
   EMail: [e-mail]

10.  Acknowledgements

   This document is the result of significant work by the four major
   contributors:

   Jeffrey D. Case (SNMP Research, [e-mail])
   Keith McCloghrie (Cisco Systems, [e-mail])
   Marshall T. Rose (Dover Beach Consulting, [e-mail])
   Steven Waldbusser (International Network Services, [e-mail])

   In addition, the contributions of the SNMPv2 Working Group are
   acknowledged.  In particular, a special thanks is extended for the
   contributions of:

     Alexander I. Alten (Novell)
     Dave Arneson (Cabletron)
     Uri Blumenthal (IBM)
     Doug Book (Chipcom)
     Kim Curran (Bell-Northern Research)
     Jim Galvin (Trusted Information Systems)
     Maria Greene (Ascom Timeplex)
     Iain Hanson (Digital)
     Dave Harrington (Cabletron)
     Nguyen Hien (IBM)
     Jeff Johnson (Cisco Systems)
     Michael Kornegay (Object Quest)
     Deirdre Kostick (AT&T Bell Labs)
     David Levi (SNMP Research)
     Daniel Mahoney (Cabletron)
     Bob Natale (ACE*COMM)
     Brian O'Keefe (Hewlett Packard)
     Andrew Pearson (SNMP Research)
     Dave Perkins (Peer Networks)



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


     Randy Presuhn (Peer Networks)
     Aleksey Romanov (Quality Quorum)
     Shawn Routhier (Epilogue)
     Jon Saperia (BGS Systems)
     Bob Stewart (Cisco Systems, [e-mail]), chair
     Kaj Tesink (Bellcore)
     Glenn Waters (Bell-Northern Research)
     Bert Wijnen (IBM)

11.  References

[1]  Information processing systems - Open Systems Interconnection -
     Specification of Abstract Syntax Notation One (ASN.1),
     International Organization for Standardization.  International
     Standard 8824, (December, 1987).

[2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Structure of Management Information for Version 2
     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
     January 1996.

[3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Management Information Base for Version 2 of the
     Simple Network Management Protocol (SNMPv2)", RFC 1907,
     January 1996.

[4]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

[5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Textual Conventions for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1903, January 1996.

[6]  Rose, M., and K. McCloghrie, "Structure and Identification of
     Management Information for TCP/IP-based internets", STD 16, RFC
     1155, May 1990.

[7]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
     RFC 1212, March 1991.











SNMPv2 Working Group        Standards Track                    [Page 24]