rfc1905.txt

radius服务器

RFC 1905             Protocol Operations for SNMPv2         January 1996


   The following validations are performed in the first phase on each
   variable binding until they are all successful, or until one fails:

(1)  If the variable binding's name specifies an existing or non-
     existent variable to which this request is/would be denied access
     because it is/would not be in the appropriate MIB view, then the
     value of the Response-PDU's error-status field is set to
     `noAccess', and the value of its error-index field is set to the
     index of the failed variable binding.

(2)  Otherwise, if there are no variables which share the same OBJECT
     IDENTIFIER prefix as the variable binding's name, and which are
     able to be created or modified no matter what new value is
     specified, then the value of the Response-PDU's error-status field
     is set to `notWritable', and the value of its error-index field is
     set to the index of the failed variable binding.

(3)  Otherwise, if the variable binding's value field specifies,
     according to the ASN.1 language, a type which is inconsistent with
     that required for all variables which share the same OBJECT
     IDENTIFIER prefix as the variable binding's name, then the value of
     the Response-PDU's error-status field is set to `wrongType', and
     the value of its error-index field is set to the index of the
     failed variable binding.

(4)  Otherwise, if the variable binding's value field specifies,
     according to the ASN.1 language, a length which is inconsistent
     with that required for all variables which share the same OBJECT
     IDENTIFIER prefix as the variable binding's name, then the value of
     the Response-PDU's error-status field is set to `wrongLength', and
     the value of its error-index field is set to the index of the
     failed variable binding.

(5)  Otherwise, if the variable binding's value field contains an ASN.1
     encoding which is inconsistent with that field's ASN.1 tag, then
     the value of the Response-PDU's error-status field is set to
     `wrongEncoding', and the value of its error-index field is set to
     the index of the failed variable binding.  (Note that not all
     implementation strategies will generate this error.)

(6)  Otherwise, if the variable binding's value field specifies a value
     which could under no circumstances be assigned to the variable,
     then the value of the Response-PDU's error-status field is set to
     `wrongValue', and the value of its error-index field is set to the
     index of the failed variable binding.

(7)  Otherwise, if the variable binding's name specifies a variable
     which does not exist and could not ever be created (even though



SNMPv2 Working Group        Standards Track                    [Page 19]

RFC 1905             Protocol Operations for SNMPv2         January 1996


     some variables sharing the same OBJECT IDENTIFIER prefix might
     under some circumstances be able to be created), then the value of
     the Response-PDU's error-status field is set to `noCreation', and
     the value of its error-index field is set to the index of the
     failed variable binding.

(8)  Otherwise, if the variable binding's name specifies a variable
     which does not exist but can not be created under the present
     circumstances (even though it could be created under other
     circumstances), then the value of the Response-PDU's error-status
     field is set to `inconsistentName', and the value of its error-
     index field is set to the index of the failed variable binding.

(9)  Otherwise, if the variable binding's name specifies a variable
     which exists but can not be modified no matter what new value is
     specified, then the value of the Response-PDU's error-status field
     is set to `notWritable', and the value of its error-index field is
     set to the index of the failed variable binding.

(10) Otherwise, if the variable binding's value field specifies a value
     that could under other circumstances be held by the variable, but
     is presently inconsistent or otherwise unable to be assigned to the
     variable, then the value of the Response-PDU's error-status field
     is set to `inconsistentValue', and the value of its error-index
     field is set to the index of the failed variable binding.

(11) When, during the above steps, the assignment of the value specified
     by the variable binding's value field to the specified variable
     requires the allocation of a resource which is presently
     unavailable, then the value of the Response-PDU's error-status
     field is set to `resourceUnavailable', and the value of its error-
     index field is set to the index of the failed variable binding.

(12) If the processing of the variable binding fails for a reason other
     than listed above, then the value of the Response-PDU's error-
     status field is set to `genErr', and the value of its error-index
     field is set to the index of the failed variable binding.

(13) Otherwise, the validation of the variable binding succeeds.

   At the end of the first phase, if the validation of all variable
   bindings succeeded, then the value of the Response-PDU's error-status
   field is set to `noError' and the value of its error-index field is
   zero, and processing continues as follows.

   For each variable binding in the request, the named variable is
   created if necessary, and the specified value is assigned to it.
   Each of these variable assignments occurs as if simultaneously with



SNMPv2 Working Group        Standards Track                    [Page 20]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   respect to all other assignments specified in the same request.
   However, if the same variable is named more than once in a single
   request, with different associated values, then the actual assignment
   made to that variable is implementation-specific.

   If any of these assignments fail (even after all the previous
   validations), then all other assignments are undone, and the
   Response-PDU is modified to have the value of its error-status field
   set to `commitFailed', and the value of its error-index field set to
   the index of the failed variable binding.

   If and only if it is not possible to undo all the assignments, then
   the Response-PDU is modified to have the value of its error-status
   field set to `undoFailed', and the value of its error-index field is
   set to zero.  Note that implementations are strongly encouraged to
   take all possible measures to avoid use of either `commitFailed' or
   `undoFailed' - these two error-status codes are not to be taken as
   license to take the easy way out in an implementation.

   Finally, the generated Response-PDU is encapsulated into a message,
   and transmitted to the originator of the SetRequest-PDU.

4.2.6.  The SNMPv2-Trap-PDU

   A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity
   acting in an agent role when an exceptional situation occurs.

   The destination(s) to which a SNMPv2-Trap-PDU is sent is determined
   in an implementation-dependent fashion by the SNMPv2 entity.  The
   first two variable bindings in the variable binding list of an
   SNMPv2-Trap-PDU are sysUpTime.0 [9] and snmpTrapOID.0 [9]
   respectively.  If the OBJECTS clause is present in the invocation of
   the corresponding NOTIFICATION-TYPE macro, then each corresponding
   variable, as instantiated by this notification, is copied, in order,
   to the variable-bindings field.  If any additional variables are
   being included (at the option of the generating SNMPv2 entity), then
   each is copied to the variable-bindings field.

4.2.7.  The InformRequest-PDU

   An InformRequest-PDU is generated and transmitted at the request of
   an application in a SNMPv2 entity acting in a manager role, that
   wishes to notify another application (in a SNMPv2 entity also acting
   in a manager role) of information in a MIB view which is remote to
   the receiving application.

   The destination(s) to which an InformRequest-PDU is sent is specified
   by the requesting application.  The first two variable bindings in



SNMPv2 Working Group        Standards Track                    [Page 21]

RFC 1905             Protocol Operations for SNMPv2         January 1996


   the variable binding list of an InformRequest-PDU are sysUpTime.0 [9]
   and snmpTrapOID.0 [9] respectively.  If the OBJECTS clause is present
   in the invocation of the corresponding NOTIFICATION-TYPE macro, then
   each corresponding variable, as instantiated by this notification, is
   copied, in order, to the variable-bindings field.

   Upon receipt of an InformRequest-PDU, the receiving SNMPv2 entity
   determines the size of a message encapsulating a Response-PDU with
   the same values in its request-id, error-status, error-index and
   variable-bindings fields as the received InformRequest-PDU.  If the
   determined message size is greater than either a local constraint or
   the maximum message size of the originator, then an alternate
   Response-PDU is generated, transmitted to the originator of the
   InformRequest-PDU, and processing of the InformRequest-PDU terminates
   immediately thereafter.  This alternate Response-PDU is formatted
   with the same values in its request-id field as the received
   InformRequest-PDU, with the value of its error-status field set to
   `tooBig', the value of its error-index field set to zero, and an
   empty variable-bindings field.  This alternate Response-PDU is then
   encapsulated into a message.  If the size of the resultant message is
   less than or equal to both a local constraint and the maximum message
   size of the originator, it is transmitted to the originator of the
   InformRequest-PDU.  Otherwise, the snmpSilentDrops [9] counter is
   incremented and the resultant message is discarded.  Regardless,
   processing of the InformRequest-PDU terminates.

   Otherwise, the receiving SNMPv2 entity:

(1)  presents its contents to the appropriate SNMPv2 application;

(2)  generates a Response-PDU with the same values in its request-id and
     variable-bindings fields as the received InformRequest-PDU, with
     the value of its error-status field is set to `noError' and the
     value of its error-index field is zero; and

(3)  transmits the generated Response-PDU to the originator of the
     InformRequest-PDU.

5.  Security Considerations

   Security issues are not discussed in this memo.










SNMPv2 Working Group        Standards Track                    [Page 22]

RFC 1905             Protocol Operations for SNMPv2         January 1996


6.  Editor's Address

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

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

7.  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)
     Randy Presuhn (Peer Networks)
     Aleksey Romanov (Quality Quorum)
     Shawn Routhier (Epilogue)
     Jon Saperia (BGS Systems)



SNMPv2 Working Group        Standards Track                    [Page 23]

RFC 1905             Protocol Operations for SNMPv2         January 1996


     Bob Stewart (Cisco Systems, [e-mail]), chair
     Kaj Tesink (Bellcore)
     Glenn Waters (Bell-Northern Research)
     Bert Wijnen (IBM)

8.  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, "Textual Conventions for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1903, January 1996.

[4]  Kent, C., and J. Mogul, Fragmentation Considered Harmful,
     Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).

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

[6]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
     USC/Information Sciences Institute, August 1980.

[7]  McCloghrie, K., and M. Rose, Editors, "Management Information
     Base for Network Management of TCP/IP-based internets:
     MIB-II", STD 17, RFC 1213, March 1991.

[8]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Coexistence between Version 1 and Version 2
     of the Internet-standard Network Management Framework", RFC 1908,
     January 1996.

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







SNMPv2 Working Group        Standards Track                    [Page 24]