rfc2576.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

4.1.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
   (there may be more than one and 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.1.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 (there may be more than one and 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.




Frye, et al.                Standards Track                    [Page 17]

RFC 2576           Coexistence between SNMP versions          March 2000


4.1.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.3, "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.

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






Frye, et al.                Standards Track                    [Page 18]

RFC 2576           Coexistence between SNMP versions          March 2000


4.1.2.4.  Processing An SNMPv1 GetNextRequest

   When processing an SNMPv1 GetNextRequest, the following procedures
   MUST be followed when an SNMPv2 access to MIB data is called 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.3, "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.

   (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 occurs.

   (2)  If there is any variable binding that contains an SNMPv2
        exception endOfMibView (there may be more than one, 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:




Frye, et al.                Standards Track                    [Page 19]

RFC 2576           Coexistence between SNMP versions          March 2000


      -  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.1.2.5.  Processing An SNMPv1 SetRequest

   When processing an SNMPv1 SetRequest, the following procedures MUST
   be followed when calling SNMPv2 MIB access routines.

   When such MIB access routines return 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.3, "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.

4.1.3.  Notification Originator

   A notification originator must be able to translate between SNMPv1
   notifications 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).




Frye, et al.                Standards Track                    [Page 20]

RFC 2576           Coexistence between SNMP versions          March 2000


   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 [18], 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.1.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
   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.2.  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 and
   the proxy, and the 'Downstream Version' refers to the version used
   between the proxy and the command responder, regardless of the PDU
   type or direction.

4.2.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 set the
      non-repeaters and max-repetitions fields to 0, and SHALL set the
      tag of the PDU to GetNextRequest-PDU.




Frye, et al.                Standards Track                    [Page 21]

RFC 2576           Coexistence between SNMP versions          March 2000


   -  If a GetResponse-PDU is received whose error-status field has a
      value of 'tooBig', the message will be forwarded using the SNMPv2c
      or SNMPv3 message version, and the original request received by
      the proxy was not a GetBulkRequest-PDU, the proxy forwarder SHALL
      remove the contents of the variable-bindings field before
      forwarding the response.

   -  If a GetResponse-PDU is received whose error-status field has a
      value of 'tooBig,' and the message will be forwarded using the
      SNMPv2c or SNMPv3 message version, and the original request
      received by the proxy was a GetBulkRequest-PDU, the proxy
      forwarder SHALL re-send the forwarded request (which would have
      been altered to be a GetNextRequest-PDU) with all but the first
      variable-binding removed.  The proxy forwarder SHALL only re-send
      such a request a single time.  If the resulting GetResponse-PDU
      also contains an error-status field with a value of 'tooBig,' then
      the proxy forwarder SHALL remove the contents of the variable-
      bindings field, and change the error-status field to 'noError'
      before forwarding the response.  Note that if the original request
      only contained a single variable-binding, the proxy may skip re-
      sending the request and simply remove the variable-bindings and
      change the error-status to 'noError.'

   -  If a Trap-PDU is received, and will be forwarded using the SNMPv2c
      or SNMPv3 message version, the proxy SHALL apply the translation
      rules described in section 3, and SHALL forward the notification
      as an SNMPv2-Trap-PDU.

      Note that when an SNMPv1 agent generates a message containing a
      Trap-PDU which is subsequently forwarded by one or more proxy
      forwarders using SNMP versions other than SNMPv1, the community
      string and agent-addr fields from the original message generated
      by the SNMPv1 agent will be preserved through the use of the
      snmpTrapAddress and snmpTrapCommunity nobjects.

4.2.2.  Upstream Version Less Than Downstream Version

   -  If a GetResponse-PDU is received in response to a GetRequest-PDU