rfc2273.txt

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

       -  The messageProcessingModel is the value from the processPdu
          call.

       -  The securityModel is the value from the processPdu call.

       -  The securityName is the value from the processPdu call.




Levi, et. al.               Standards Track                    [Page 12]

RFC 2273                  SNMPv3 Applications               January 1998


       -  The securityLevel is the value from the processPdu call.

       -  The contextEngineID is the value from the processPdu call.

       -  The contextName is the value from the processPdu call.

       -  The pduVersion indicates the version of the PDU to be
          returned.  If no result PDU was generated, the pduVersion is
          an undefined value.

       -  The PDU is the result generated in step (5) above.  If no
          result PDU was generated, the PDU is an undefined value.

       -  The maxSizeResponseScopedPDU is a local value indicating the
          maximum size of a ScopedPDU that the application can accept.

       -  The stateReference is the value from the processPdu call.

       -  The statusInformation either contains an indication that no
          error occurred and that a response should be generated, or
          contains an indication that an error occurred along with the
          OID and counter value of the appropriate error counter object.

   Note that a command responder application should always call the
   returnResponsePdu abstract service interface, even in the event of an
   error such as a resource allocation error.  In the event of such an
   error, the PDU value passed to returnResponsePdu should contain
   appropriate values for errorStatus and errorIndex.

3.3.  Notification Originator Applications

   A notification originator application generates SNMP notification
   messages.  A notification message may, for example, contain an
   SNMPv2-Trap PDU or an Inform PDU.  However, a particular
   implementation is not required to be capable of generating both types
   of messages.

   Notification originator applications require a mechanism for
   identifying the management targets to which notifications should be
   sent.  The particular mechanism used is implementation dependent.
   However, if an implementation makes the configuration of management
   targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module
   described in this document.

   When a notification originator wishes to generate a notification, it
   must first determine in which context the information to be conveyed
   in the notification exists, i.e., it must determine the
   contextEngineID and contextName.  It must then determine the set of



Levi, et. al.               Standards Track                    [Page 13]

RFC 2273                  SNMPv3 Applications               January 1998


   management targets to which the notification should be sent.  The
   application must also determine, for each management target, whether
   the notification message should contain an SNMPv2-Trap PDU or Inform
   PDU, and if it is to contain an Inform PDU, the number of retries and
   retransmission algorithm.

   The mechanism by which a notification originator determines this
   information is implementation dependent.  Once the application has
   determined this information, the following procedure is performed for
   each management target:

(1)  Any appropriate filtering mechanisms are applied to determine
     whether the notification should be sent to the management target.
     If such filtering mechanisms determine that the notification should
     not be sent, processing continues with the next management target.
     Otherwise,

(2)  The appropriate set of variable-bindings is retrieved from local
     MIB instrumentation within the relevant MIB view.  The relevant MIB
     view is determined by the securityLevel, securityModel,
     contextName, and securityName of the management target.  To
     determine whether a particular object instance is within the
     relevant MIB view, the isAccessAllowed abstract service interface
     is used, in the same manner as described in the preceding section.
     If the statusInformation returned by isAccessAllowed does not
     indicate accessAllowed, the notification is not sent to the
     management target.

(3)  A PDU is constructed using a locally unique request-id value, an
     operation type of SNMPv2-Trap or Inform, an error-status and
     error-index value of 0, and the variable-bindings supplied
     previously in step (2).

(4)  If the notification contains an SNMPv2-Trap PDU, the Dispatcher is
     called using the following abstract service interface:

         statusInformation =              -- sendPduHandle if success
                                          -- errorIndication if failure
           sendPdu(
           IN   transportDomain           -- transport domain to be used
           IN   transportAddress          -- destination network address
           IN   messageProcessingModel    -- typically, SNMP version
           IN   securityModel             -- Security Model to use
           IN   securityName              -- on behalf of this principal
           IN   securityLevel             -- Level of Security requested
           IN   contextEngineID           -- data from/at this entity
           IN   contextName               -- data from/in this context
           IN   pduVersion                -- the version of the PDU



Levi, et. al.               Standards Track                    [Page 14]

RFC 2273                  SNMPv3 Applications               January 1998


           IN   PDU                       -- SNMP Protocol Data Unit
           IN   expectResponse            -- TRUE or FALSE
                )

     Where:

       -  The transportDomain is that of the management target.

       -  The transportAddress is that of the management target.

       -  The messageProcessingModel is that of the management target.

       -  The securityModel is that of the management target.

       -  The securityName is that of the management target.

       -  The securityLevel is that of the management target.

       -  The contextEngineID is the value originally determined for the
          notification.

       -  The contextName is the value originally determined for the
          notification.

       -  The pduVersion is the version of the PDU to be sent.

       -  The PDU is the value constructed in step (3) above.

       -  The expectResponse argument indicates that no response is
          expected.

     Otherwise,

(5)  If the notification contains an Inform PDU, then:

      a)  The Dispatcher is called using the sendPdu abstract service
          interface as described in step (4) above, except that the
          expectResponse argument indicates that a response is expected.

      b)   The application caches information about the management
          target.

      c)  If a response is received within an appropriate time interval
          from the transport endpoint of the management target, the
          notification is considered acknowledged and the cached
          information is deleted.  Otherwise,





Levi, et. al.               Standards Track                    [Page 15]

RFC 2273                  SNMPv3 Applications               January 1998


      d)  If a response is not received within an appropriate time
          period, or if a report indication is received, information
          about the management target is retrieved from the cache, and
          steps a) through d) are repeated.  The number of times these
          steps are repeated is equal to the previously determined retry
          count.  If this retry count is exceeded, the acknowledgement
          of the notification is considered to have failed, and
          processing of the notification for this management target is
          halted.

   Responses to Inform PDU notifications will be received via the
   processResponsePDU abstract service interface.

3.4.  Notification Receiver Applications

   Notification receiver applications receive SNMP Notification messages
   from the Dispatcher.  Before any messages can be received, the
   notification receiver must register with the Dispatcher using the
   registerContextEngineID abstract service interface.  The parameters
   used are:

       -  The contextEngineID is an undefined 'wildcard' value.
          Notifications are delivered to a registered notification
          receiver regardless of the contextEngineID contained in the
          notification message.

       -  The pduType indicates the type of notifications that the
          application wishes to receive (for example, SNMPv2-Trap PDUs
          or Inform PDUs).

   Once the notification receiver has registered with the Dispatcher,
   messages are received using the processPdu abstract service
   interface.  Parameters are:

       -  The messageProcessingModel indicates which Message Processing
          Model received and processed the message.

       -  The securityModel is the value from the received message.

       -  The securityName is the value from the received message.

       -  The securityLevel is the value from the received message.

       -  The contextEngineID is the value from the received message.

       -  The contextName is the value from the received message.





Levi, et. al.               Standards Track                    [Page 16]

RFC 2273                  SNMPv3 Applications               January 1998


       -  The pduVersion indicates the version of the PDU in the
          received message.

       -  The PDU is the value from the received message.

       -  The maxSizeResponseScopedPDU is the maximum allowable size of
          a ScopedPDU containing a Response PDU (based on the maximum
          message size that the originator of the message can accept).

       -  If the message contains an SNMPv2-Trap PDU, the stateReference
          is undefined and unused.  Otherwise, the stateReference is a
          value which references cached information about the
          notification.  This value must be returned to the Dispatcher
          in order to generate a response.

   When an SNMPv2-Trap PDU is delivered to a notification receiver
   application, it first extracts the SNMP operation type, request-id,
   error-status, error-index, and variable-bindings from the PDU.  After
   this, processing depends on the particular implementation.

   When an Inform PDU is received, the notification receiver application
   follows the following procedure:

(1)  The SNMPv2 operation type, request-id, error-status, error-index,
     and variable-bindings are extracted from the PDU.

(2)  A Response PDU is constructed using the extracted request-id and
     variable-bindings, and with error-status and error-index both set
     to 0.

(3)  The Dispatcher is called to generate a response message using the
     returnResponsePdu abstract service interface.  Parameters are:

       -  The messageProcessingModel is the value from the processPdu
          call.

       -  The securityModel is the value from the processPdu call.

       -  The securityName is the value from the processPdu call.

       -  The securityLevel is the value from the processPdu call.

       -  The contextEngineID is the value from the processPdu call.

       -  The contextName is the value from the processPdu call.

       -  The pduVersion indicates the version of the PDU to be
          returned.



Levi, et. al.               Standards Track                    [Page 17]

RFC 2273                  SNMPv3 Applications               January 1998


       -  The PDU is the result generated in step (2) above.

       -  The maxSizeResponseScopedPDU is a local value indicating the
          maximum size of a ScopedPDU that the application can accept.

       -  The stateReference is the value from the processPdu call.

       -  The statusInformation indicates that no error occurred and
          that a response should be generated.

3.5.  Proxy Forwarder Applications

   A proxy forwarder application deals with forwarding SNMP messages.
   There are four basic types of messages which a proxy forwarder
   application may need to forward.  These are grouped according to the
   PDU type contained in a message, or according to whether a report
   indication is contained in the message.  The four basic types of
   messages are:

       -  Those containing PDU types which were generated by a command
          generator application (for example, Get, GetNext, GetBulk, and
          Set PDU types).  These deal with requesting or modifying
          information located within a particular context.

       -  Those containing PDU types which were generated by a
          notification originator application (for example, SNMPv2-Trap
          and Inform PDU types).  These deal with notifications
          concerning information located within a particular context.

       -  Those containing a Response PDU type.  Forwarding of Response
          PDUs always occurs as a result of receiving a response to a
          previously forwarded message.

       -  Those containing a report indication.  Forwarding of report
          indications always occurs as a result of receiving a report