rfc2580.txt

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

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.





McCloghrie, et al.          Standards Track                    [Page 22]





RFC 2580            Conformance Statements for SMIv2          April 1999


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

       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


McCloghrie, et al.          Standards Track                    [Page 23]





RFC 2580            Conformance Statements for SMIv2          April 1999


               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, evalStatus }
               DESCRIPTION  "Conceptual row creation is supported."

       ::= { acmeAgents 1 }


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

        { acmeAgents 1 }

   supports objects defined in 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.

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

   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, and requires both of the objects:  evalString and
   evalStatus, to be assigned a value.








McCloghrie, et al.          Standards Track                    [Page 24]





RFC 2580            Conformance Statements for SMIv2          April 1999


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

   It may be desirable to revise the definition of a conformance group
   (an OBJECT-GROUP or a NOTIFICATION-GROUP) after experience is gained
   with it.  However, conformance groups can be referenced by compliance
   and/or capabilities definitions.  Therefore, a change to a
   conformance group is not allowed if it has the potential to cause a
   reference to the group's original definition to be different from a
   reference to the updated definition.  Such changes can only be
   accommodated by defining a new conformance group with a new
   descriptor and a new OBJECT IDENTIFIER value.

   The following revisions are allowed:

(1)  A STATUS clause value of "current" may be revised as "deprecated"
     or "obsolete".  Similarly, a STATUS clause value of "deprecated"
     may be revised as "obsolete".  When making such a change, the
     DESCRIPTION clause should be updated to explain the rationale.

(2)  A REFERENCE clause may be added or updated.

(3)  Clarifications and additional information may be included in the
     DESCRIPTION clause.

(4)  Any editorial change.

   It is not necessary to change the STATUS value of a conformance group
   when the status of a member of the group is changed.

7.2.  Compliance Definitions

   It may be desirable to revise the definition of a compliance
   definition (MODULE-COMPLIANCE) after experience is gained with it.
   However, changes are not allowed if they cause the requirements
   specified by the original definition to be different from the
   requirements of the updated definition.  Such changes can only be
   accommodated by defining a new compliance definition with a new



McCloghrie, et al.          Standards Track                    [Page 25]





RFC 2580            Conformance Statements for SMIv2          April 1999


   descriptor and a new OBJECT IDENTIFIER value.

   The following revisions are allowed:

(1)  A STATUS clause value of "current" may be revised as "deprecated"
     or "obsolete".  Similarly, a STATUS clause value of "deprecated"
     may be revised as "obsolete".  When making such a change, the
     DESCRIPTION clause should be updated to explain the rationale.

(2)  A REFERENCE clause may be added or updated.

(3)  Clarifications and additional information may be included in the
     DESCRIPTION clause(s).

(4)  Any editorial change.

   It is not necessary to change the STATUS value of a compliance
   definition due to a change in the STATUS value of a definition it
   references.

7.3.  Capabilities Definitions

   It may be desirable to revise the definition of a capabilities
   definition (AGENT-CAPABILITIES) after experience is gained with it.
   However, changes are not allowed if they cause the capabilities
   specified by the original specification to be different from the
   capabilities of the updated specification.  Such changes can only be
   accommodated by defining a new capabilities definition with a new
   descriptor and a new OBJECT IDENTIFIER value.

   The following revisions are allowed:

(1)  A STATUS clause value of "current" may be revised as "obsolete".
     When making such a change, the DESCRIPTION clause should be updated
     to explain the rationale.

(2)  A REFERENCE clause may be added or updated.

(3)  Clarifications and additional information may be included in the
     DESCRIPTION clause(s).

(4)  Any editorial change.

   It is not necessary to change the STATUS value of a capabilities
   definition due to a change in the STATUS value of a definition it
   references.




McCloghrie, et al.          Standards Track                    [Page 26]





RFC 2580            Conformance Statements for SMIv2          April 1999


8.  Security Considerations

   This document defines the means to define conformance requirements
   for implementing on documents describing management information.
   This method of defining conformance requirements has no security
   impact on the Internet.


9.  Editors' Addresses

   Keith McCloghrie
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   USA
   Phone: [phone]
   EMail: [e-mail]

   David Perkins
   SNMPinfo
   3763 Benton Street
   Santa Clara, CA 95051
   USA
   Phone: [phone]
   Email: [e-mail]

   Juergen Schoenwaelder
   TU Braunschweig
   Bueltenweg 74/75
   38106 Braunschweig
   Germany
   Phone: [phone]
   EMail: [e-mail]

















McCloghrie, et al.          Standards Track                    [Page 27]





RFC 2580            Conformance Statements for SMIv2          April 1999


10.  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]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
     and S. Waldbusser, "Structure of Management Information Version 2
     (SMIv2)", STD 58, RFC 2578, April 1999.

[3]  The 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]  The 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]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
     and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
     RFC 2579, April 1999.

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




















McCloghrie, et al.          Standards Track                    [Page 28]





RFC 2580            Conformance Statements for SMIv2          April 1999


11.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."























McCloghrie, et al.          Standards Track                    [Page 29]