rfc1448.txt

gnu 的radius服务器很好用的

               specifies, according to the ASN.1 language, a length
               which is inconsistent with that required for the
               variable, 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.

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

          (7)  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





          Case, McCloghrie, Rose & Waldbusser                  [Page 24]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


               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.

          (8)  Otherwise, if the variable binding's name specifies a
               variable which does not exist but can not be created not
               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 value field
               specifies a value that could under other circumstances be
               assigned to the variable, but is presently inconsistent,
               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.

          (10) Otherwise, if 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.

          (11) 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.

          (12) 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.

          For each variable binding in the request, the named variable
          is created if necessary, and the specified value is assigned





          Case, McCloghrie, Rose & Waldbusser                  [Page 25]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


          to it.  Each of these variable assignments occurs as if
          simultaneously with 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 by consulting the aclTable [5] to find all entries
          satisfying the following conditions:

          (1)  The value of aclSubject refers to the SNMPv2 entity.

          (2)  The value of aclPrivileges allows for the SNMPv2-Trap-
               PDU.

          (3)  aclResources refers to a SNMPv2 context denoting local
               object resources, and the notification's administratively
               assigned name is present in the corresponding MIB view.





          Case, McCloghrie, Rose & Waldbusser                  [Page 26]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


               (That is, the set of entries in the viewTable [5] for
               which the instance of viewIndex has the same value as the
               aclResources's contextViewIndex, define a MIB view which
               contains the notification's administratively assigned
               name.)

          (4)  If the OBJECTS clause is present in the invocation of the
               corresponding NOTIFICATION-TYPE macro, then the
               correspondent variables are all present in the MIB view
               corresponding to aclResource.

          Then, for each entry satisfying these conditions, a SNMPv2-
          Trap-PDU is sent from aclSubject with context aclResources to
          aclTarget.  The instance of snmpTrapNumbers [11] corresponding
          to aclTarget is incremented, and is used as the request-id
          field of the SNMPv2-Trap-PDU.  Then, the variable-bindings
          field are constructed as:

          (1)  The first variable is sysUpTime.0 [9].

          (2)  The second variable is snmpTrapOID.0 [11], which contains
               the administratively assigned name of the notification.

          (3)  If the OBJECTS clause is present in the invocation of the
               corresponding NOTIFICATION-TYPE macro, then each
               corresponding variable is copied, in order, to the
               variable-bindings field.

          (4)  At the option of the SNMPv2 entity acting in an agent
               role, additional variables may follow in the variable-
               bindings field.


          4.2.7.  The InformRequest-PDU

          An InformRequest-PDU is generated and transmitted at the
          request 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 the
          MIB View of a party local to the sending application.

          The destination(s) to which an InformRequest-PDU is sent is
          determined by inspecting the snmpEventNotifyTable [12], or as
          specified by the requesting application.  The first two
          variable bindings in the variable binding list of an





          Case, McCloghrie, Rose & Waldbusser                  [Page 27]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


          InformRequest-PDU are sysUpTime.0 [9] and snmpEventID.i [12]
          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 request's source party, 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 request's source party, it is transmitted to the
          originator of the InformRequest-PDU.  Otherwise, 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.








          Case, McCloghrie, Rose & Waldbusser                  [Page 28]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


          5.  Acknowledgements

          This document is based, in part, on RFC 1157.  The mechanism
          for bulk retrieval is influenced by many experiments,
          including RFC1187 and also Greg Satz's work on SNMP over TCP.

          Finally, the comments of the SNMP version 2 working group are
          gratefully acknowledged:

               Beth Adams, Network Management Forum
               Steve Alexander, INTERACTIVE Systems Corporation
               David Arneson, Cabletron Systems
               Toshiya Asaba
               Fred Baker, ACC
               Jim Barnes, Xylogics, Inc.
               Brian Bataille
               Andy Bierman, SynOptics Communications, Inc.
               Uri Blumenthal, IBM Corporation
               Fred Bohle, Interlink
               Jack Brown
               Theodore Brunner, Bellcore
               Stephen F. Bush, GE Information Services
               Jeffrey D. Case, University of Tennessee, Knoxville
               John Chang, IBM Corporation
               Szusin Chen, Sun Microsystems
               Robert Ching
               Chris Chiotasso, Ungermann-Bass
               Bobby A. Clay, NASA/Boeing
               John Cooke, Chipcom
               Tracy Cox, Bellcore
               Juan Cruz, Datability, Inc.
               David Cullerot, Cabletron Systems
               Cathy Cunningham, Microcom
               James R. (Chuck) Davin, Bellcore
               Michael Davis, Clearpoint
               Mike Davison, FiberCom
               Cynthia DellaTorre, MITRE
               Taso N. Devetzis, Bellcore
               Manual Diaz, DAVID Systems, Inc.
               Jon Dreyer, Sun Microsystems
               David Engel, Optical Data Systems
               Mike Erlinger, Lexcel
               Roger Fajman, NIH
               Daniel Fauvarque, Sun Microsystems
               Karen Frisa, CMU





          Case, McCloghrie, Rose & Waldbusser                  [Page 29]





          RFC 1448        Protocol Operations for SNMPv2      April 1993


               Shari Galitzer, MITRE
               Shawn Gallagher, Digital Equipment Corporation
               Richard Graveman, Bellcore
               Maria Greene, Xyplex, Inc.
               Michel Guittet, Apple
               Robert Gutierrez, NASA
               Bill Hagerty, Cabletron Systems
               Gary W. Haney, Martin Marietta Energy Systems
               Patrick Hanil, Nokia Telecommunications
               Matt Hecht, SNMP Research, Inc.
               Edward A. Heiner, Jr., Synernetics Inc.
               Susan E. Hicks, Martin Marietta Energy Systems
               Geral Holzhauer, Apple
               John Hopprich, DAVID Systems, Inc.
               Jeff Hughes, Hewlett-Packard
               Robin Iddon, Axon Networks, Inc.
               David Itusak
               Kevin M. Jackson, Concord Communications, Inc.
               Ole J. Jacobsen, Interop Company
               Ronald Jacoby, Silicon Graphics, Inc.
               Satish Joshi, SynOptics Communications, Inc.
               Frank Kastenholz, FTP Software
               Mark Kepke, Hewlett-Packard
               Ken Key, SNMP Research, Inc.
               Zbiginew Kielczewski, Eicon
               Jongyeoi Kim
               Andrew Knutsen, The Santa Cruz Operation
               Michael L. Kornegay, VisiSoft
               Deirdre C. Kostik, Bellcore
               Cheryl Krupczak, Georgia Tech
               Mark S. Lewis, Telebit
               David Lin
               David Lindemulder, AT&T/NCR