rfc3584.txt

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

      then an error-status of noSuchName SHALL be returned, and the
      error-index SHALL be set to the variable binding that caused this
      error.

   -  Any SNMPv1 request which contains a variable binding with a
      Counter64 value is ill-formed, so the foregoing rules do not
      apply.  If that error is detected, a response SHALL NOT be
      returned, since it would contain a copy of the ill-formed variable
      binding.  Instead, the offending PDU SHALL be discarded and the
      counter snmpInASNParseErrs SHALL be incremented.

4.2.2.2.  Mapping SNMPv2 Exceptions

   SNMPv2 provides a feature called exceptions, which allow an SNMPv2
   Response PDU to return as much management information as possible,
   even when an error occurs.  However, SNMPv1 does not support
   exceptions, and so an SNMPv1 Response PDU cannot return any
   management information, and can only return an error-status and an
   error-index value.

   When an SNMPv1 request is received, a command responder MUST check
   any variable bindings returned using SNMPv2 access to MIB data for
   exception values, and convert these exception values into SNMPv1
   error codes.

   The type of exception that can be returned when accessing MIB data
   and the action taken depends on the type of SNMP request.

   -  For a GetRequest, a noSuchObject or noSuchInstance exception may
      be returned.

   -  For a GetNextRequest, an endOfMibView exception may be returned.

   -  No exceptions will be returned for a SetRequest, and a
      GetBulkRequest should only be received in an SNMPv2c or SNMPv3
      message, so these request types may be ignored when mapping
      exceptions.

   Note that when a response contains multiple exceptions, it is an
   implementation choice as to which variable binding the error-index
   should reference.



Frye, et al.             Best Current Practice                 [Page 17]

RFC 3584           Coexistence between SNMP versions         August 2003


4.2.2.2.1.  Mapping noSuchObject and noSuchInstance

   A noSuchObject or noSuchInstance exception generated by an SNMPv2
   access to MIB data indicates that the requested object instance can
   not be returned.  The SNMPv1 error code for this condition is
   noSuchName, and so the error-status field of the response PDU SHALL
   be set to noSuchName.  Also, the error-index field SHALL be set to
   the index of the variable binding for which an exception occurred (if
   there is more than one then it is an implementation decision as to
   which is used), and the variable binding list from the original
   request SHALL be returned with the response PDU.

4.2.2.2.2.  Mapping endOfMibView

   When an SNMPv2 access to MIB data returns a variable binding
   containing an endOfMibView exception, it indicates that there are no
   object instances available which lexicographically follow the object
   in the request.  In an SNMPv1 agent, this condition normally results
   in a noSuchName error, and so the error-status field of the response
   PDU SHALL be set to noSuchName.  Also, the error-index field SHALL be
   set to the index of the variable binding for which an exception
   occurred (if there is more than one then it is an implementation
   decision as to which is used), and the variable binding list from the
   original request SHALL be returned with the response PDU.

4.2.2.3.  Processing An SNMPv1 GetRequest

   When processing an SNMPv1 GetRequest, the following procedures MUST
   be followed when using an SNMPv2 access to MIB data.

   When such an access to MIB data returns response data using SNMPv2
   syntax and error-status values, then:

   (1)  If the error-status is anything other than noError,

        -   The error status SHALL be translated to an SNMPv1 error-
            status using the table in section 4.4, "Error Status
            Mappings".

        -   The error-index SHALL be set to the position (in the
            original request) of the variable binding that caused the
            error-status.

        -   The variable binding list of the response PDU SHALL be made
            exactly the same as the variable binding list that was
            received in the original request.





Frye, et al.             Best Current Practice                 [Page 18]

RFC 3584           Coexistence between SNMP versions         August 2003


   (2)  If the error-status is noError, the variable bindings SHALL be
        checked for any SNMPv2 exception (noSuchObject or
        noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1
        (Counter64).  If there are any such variable bindings, one of
        those variable bindings SHALL be selected (it is an
        implementation choice as to which is selected), and:

        -   The error-status SHALL be set to noSuchName,

        -   The error-index SHALL be set to the position (in the
            variable binding list of the original request) of the
            selected variable binding, and

        -   The variable binding list of the response PDU SHALL be
            exactly the same as the variable binding list that was
            received in the original request.

   (3)  If there are no such variable bindings, then:

        -   The error-status SHALL be set to noError,

        -   The error-index SHALL be set to zero, and

        -   The variable binding list of the response SHALL be composed
            from the data as it is returned by the access to MIB data.

4.2.2.4.  Processing An SNMPv1 GetNextRequest

   When processing an SNMPv1 GetNextRequest, the following procedures
   MUST be followed when SNMPv2 access to MIB data is used as part of
   processing the request.  There may be repetitive accesses to MIB data
   to try to find the first object which lexicographically follows each
   of the objects in the request.  This is implementation specific.
   These procedures are followed only for data returned when using
   SNMPv2 access to MIB data.  Data returned using SNMPv1 access to MIB
   data may be treated in the normal manner for an SNMPv1 request.

   First, if the access to MIB data returns an error-status of anything
   other than noError:

   (1)  The error status SHALL be translated to an SNMPv1 error-status
        using the table in section 4.4, "Error Status Mappings".

   (2)  The error-index SHALL be set to the position (in the original
        request) of the variable binding that caused the error-status.






Frye, et al.             Best Current Practice                 [Page 19]

RFC 3584           Coexistence between SNMP versions         August 2003


   (3)  The variable binding list of the response PDU SHALL be exactly
        the same as the variable binding list that was received in the
        original request.

   Otherwise, if the access to MIB data returns an error-status of
   noError:

   (1)  Any variable bindings containing an SNMPv2 syntax of Counter64
        SHALL be considered to be not in view, and MIB data SHALL be
        accessed as many times as is required until either a value other
        than Counter64 is returned, or an error or endOfMibView
        exception occurs.

   (2)  If there is any variable binding that contains an SNMPv2
        exception endOfMibView (if there is more than one then it is an
        implementation decision as to which is chosen):

        -   The error-status SHALL be set to noSuchName,

        -   The error-index SHALL be set to the position (in the
            variable binding list of the original request) of the
            variable binding that returned such an SNMPv2 exception, and

        -   The variable binding list of the response PDU SHALL be
            exactly the same as the variable binding list that was
            received in the original request.

   (3)  If there are no such variable bindings, then:

        -   The error-status SHALL be set to noError,

        -   The error-index SHALL be set to zero, and

        -   The variable binding list of the response SHALL be composed
            from the data as it is returned by the access to MIB data.

4.2.2.5.  Processing An SNMPv1 SetRequest

   When processing an SNMPv1 SetRequest, the following procedures MUST
   be followed when using SNMPv2 access to MIB data.

   When such MIB access returns response data using SNMPv2 syntax and
   error-status values, and the error-status is anything other than
   noError, then:

   -  The error status SHALL be translated to an SNMPv1 error-status
      using the table in section 4.4, "Error Status Mappings".




Frye, et al.             Best Current Practice                 [Page 20]

RFC 3584           Coexistence between SNMP versions         August 2003


   -  The error-index SHALL be set to the position (in the original
      request) of the variable binding that caused the error-status.

   -  The variable binding list of the response PDU SHALL be made
      exactly the same as the variable binding list that was received in
      the original request.

4.2.3.  Notification Originator

   A notification originator must be able to translate between SNMPv1
   notification parameters and SNMPv2 notification parameters in order
   to send a notification using a particular SNMP message version.  If a
   notification is generated using SNMPv1 notification parameters, and
   configuration information specifies that notifications be sent using
   SNMPv2c or SNMPv3, the notification parameters must be translated to
   SNMPv2 notification parameters.  Likewise, if a notification is
   generated using SNMPv2 notification parameters, and configuration
   information specifies that notifications be sent using SNMPv1, the
   notification parameters must be translated to SNMPv1 notification
   parameters.  In this case, if the notification cannot be translated
   (due to the presence of a Counter64 type), it will not be sent using
   SNMPv1.

   When a notification originator generates a notification, using
   parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION-
   MIB, if the SNMP version used to generate the notification is SNMPv1,
   the PDU type used will always be a TrapPDU, regardless of whether the
   value of snmpNotifyType is trap(1) or inform(2).

   Note also that access control and notification filtering are
   performed in the usual manner for notifications, regardless of the
   SNMP message version to be used when sending a notification.  The
   parameters for performing access control are found in the usual
   manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP-
   NOTIFICATION-MIB).  In particular, when generating an SNMPv1 Trap, in
   order to perform the access check specified in [RFC3413], section
   3.3, bullet (3), the notification originator may need to generate a
   value for snmpTrapOID.0 as described in section 3.1, bullets (2) and
   (3) of this document.  If the SNMPv1 notification parameters being
   used were previously translated from a set of SNMPv2 notification
   parameters, this value may already be known, in which case it need
   not be generated.

4.2.4.  Notification Receiver

   There are no special requirements of a notification receiver.
   However, an implementation may find it useful to allow a higher level
   application to request whether notifications should be delivered to a



Frye, et al.             Best Current Practice                 [Page 21]

RFC 3584           Coexistence between SNMP versions         August 2003


   higher level application using SNMPv1 notification parameter or
   SNMPv2 notification parameters.  The notification receiver would then
   translate notification parameters when required in order to present a
   notification using the desired set of parameters.

4.3.  Proxy Implementations

   A proxy implementation may be used to enable communication between
   entities which support different SNMP message versions.  This is
   accomplished in a proxy forwarder application by performing
   translations on PDUs.  These translations depend on the PDU type, the
   SNMP version of the packet containing a received PDU, and the SNMP
   version to be used to forward a received PDU.  The following sections
   describe these translations.  In all cases other than those described
   below, the proxy SHALL forward a received PDU without change, subject
   to size constraints as defined in section 5.3 (Community MIB) of this
   document.  Note that in the following sections, the 'Upstream
   Version' refers to the version used between the command generator or
   notification receiver and the proxy, and the 'Downstream Version'
   refers to the version used between the proxy and the command
   responder or notification originator, regardless of the PDU type or
   direction.

4.3.1.  Upstream Version Greater Than Downstream Version

   -  If a GetBulkRequest-PDU is received and must be forwarded using
      the SNMPv1 message version, the proxy forwarder SHALL act as if
      the non-repeaters and max-repetitions fields were both set to 0,
      and SHALL set the tag of the PDU to GetNextRequest-PDU.