rfc3416.txt

开发snmp的开发包有两个开放的SNMP开发库

Presuhn, et al.             Standards Track                    [Page 17]

RFC 3416              Protocol Operations for SNMP         December 2002


   The SNMP entity supporting the command generator application
   continues with:

     GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
                     ( sysUpTime,
                       ipNetToMediaPhysAddress.1.10.0.0.51,
                       ipNetToMediaType.1.10.0.0.51 )

   The SNMP entity supporting the command responder application responds
   with:

    Response (( sysUpTime.0 =  "123466" ),
               ( ipNetToMediaPhysAddress.2.10.0.0.15 = "000010987654" ),
               ( ipNetToMediaType.2.10.0.0.15 = "dynamic" ),
               ( ipNetToMediaNetAddress.1.9.2.3.4 = "9.2.3.4" ),
            ( ipRoutingDiscards.0 =  "2" ))

   Note how, as in the first example, the variable bindings in the
   response indicate that the end of the table has been reached.  The
   fourth variable binding does so by returning information from the
   next available column; the fifth variable binding does so by
   returning information from the first available object
   lexicographically following the table.  This response signals the end
   of the table to the command generator application.

4.2.4.  The Response-PDU

   The Response-PDU is generated by an SNMP entity only upon receipt of
   a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU,
   SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this
   document.

   If the error-status field of the Response-PDU is non-zero, the value
   fields of the variable bindings in the variable binding list are
   ignored.

   If both the error-status field and the error-index field of the
   Response-PDU are non-zero, then the value of the error-index field is
   the index of the variable binding (in the variable-binding list of
   the corresponding request) for which the request failed.  The first
   variable binding in a request's variable-binding list is index one,
   the second is index two, etc.

   A compliant SNMP entity supporting a command generator application
   must be able to properly receive and handle a Response-PDU with an
   error-status field equal to "noSuchName", "badValue", or "readOnly".
   (See sections 1.3 and 4.3 of [RFC2576].)




Presuhn, et al.             Standards Track                    [Page 18]

RFC 3416              Protocol Operations for SNMP         December 2002


   Upon receipt of a Response-PDU, the receiving SNMP entity presents
   its contents to the application which generated the request with the
   same request-id value.  For more details, see [RFC3412].

4.2.5.  The SetRequest-PDU

   A SetRequest-PDU is generated and transmitted at the request of an
   application.

   Upon receipt of a SetRequest-PDU, the receiving SNMP entity
   determines the size of a message encapsulating a Response-PDU having
   the same values in its request-id and variable-bindings fields as the
   received SetRequest-PDU, and the largest possible sizes of the
   error-status and error-index fields.  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 SetRequest-PDU, and processing
   of the SetRequest-PDU terminates immediately thereafter.  This
   alternate Response-PDU is formatted with the same values in its
   request-id field as the received SetRequest-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 SetRequest-PDU.  Otherwise, the
   snmpSilentDrops [RFC3418] counter is incremented and the resultant
   message is discarded.  Regardless, processing of the SetRequest-PDU
   terminates.

   Otherwise, the receiving SNMP entity processes each variable binding
   in the variable-binding list to produce a Response-PDU.  All fields
   of the Response-PDU have the same values as the corresponding fields
   of the received request except as indicated below.

   The variable bindings are conceptually processed as a two phase
   operation.  In the first phase, each variable binding is validated;
   if all validations are successful, then each variable is altered in
   the second phase.  Of course, implementors are at liberty to
   implement either the first, or second, or both, of these conceptual
   phases as multiple implementation phases.  Indeed, such multiple
   implementation phases may be necessary in some cases to ensure
   consistency.








Presuhn, et al.             Standards Track                    [Page 19]

RFC 3416              Protocol Operations for SNMP         December 2002


   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.





Presuhn, et al.             Standards Track                    [Page 20]

RFC 3416              Protocol Operations for SNMP         December 2002


   (7)   Otherwise, if the variable binding's name specifies a variable
         which does not exist and could not ever be created (even though
         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.






Presuhn, et al.             Standards Track                    [Page 21]

RFC 3416              Protocol Operations for SNMP         December 2002


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

   An SNMPv2-Trap-PDU is generated and transmitted by an SNMP entity on
   behalf of a notification originator application.  The SNMPv2-Trap-PDU
   is often used to notify a notification receiver application at a
   logically remote SNMP entity that an event has occurred or that a
   condition is present.  There is no confirmation associated with this
   notification delivery mechanism.

   The destination(s) to which an SNMPv2-Trap-PDU is sent is determined
   in an implementation-dependent fashion by the SNMP entity.  The first
   two variable bindings in the variable binding list of an SNMPv2-
   Trap-PDU are sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418]
   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,





Presuhn, et al.             Standards Track                    [Page 22]

RFC 3416              Protocol Operations for SNMP         December 2002


   to the variable-bindings field.  If any additional variables are
   being included (at the option of the generating SNMP entity), then
   each is copied to the variable-bindings field.

4.2.7.  The InformRequest-PDU

   An InformRequest-PDU is generated and transmitted by an SNMP entity
   on behalf of a notification originator application.  The
   InformRequest-PDU is often used to notify a notification receiver
   application that an event has occurred or that a condition is
   present.  This is a confirmed notification delivery mechanism,
   although there is, of course, no guarantee of delivery.

   The destination(s) to which an InformRequest-PDU is sent is specified
   by the notification originator application.  The first two variable
   bindings in the variable binding list of an InformRequest-PDU are
   sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418] 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 SNMP entity), then each is
   copied to the variable-bindings field.

   Upon receipt of an InformRequest-PDU, the receiving SNMP 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