【正文】 and counter value of the appropriate error counter object.Note that a mand responder application should always call thereturnResponsePdu abstract service interface, even in the event of anerror such as a resource allocation error. In the event of such anerror, the PDU value passed to returnResponsePdu should containappropriate values for errorStatus and errorIndex.. Notification Originator ApplicationsA notification originator application generates SNMP notificationmessages. A notification message may, for example, contain anSNMPv2Trap PDU or an Inform PDU. However, a particularimplementation is not required to be capable of generating both typesof messages.Notification originator applications require a mechanism foridentifying the management targets to which notifications should besent. The particular mechanism used is implementation dependent.However, if an implementation makes the configuration of managementtargets SNMP manageable, it MUST use the SNMPTARGETMIB moduledescribed in this document.When a notification originator wishes to generate a notification, itmust first determine in which context the information to be conveyedin the notification exists, ., it must determine thecontextEngineID and contextName. It must then determine the set ofmanagement targets to which the notification should be sent. Theapplication must also determine, for each management target, whetherthe notification message should contain an SNMPv2Trap PDU or InformPDU, and if it is to contain an Inform PDU, the number of retries andretransmission algorithm.The mechanism by which a notification originator determines thisinformation is implementation dependent. Once the application hasdetermined this information, the following procedure is performed foreach management target:(1) Any appropriate filtering mechanisms are applied to determinewhether the notification should be sent to the management target.If such filtering mechanisms determine that the notification shouldnot be sent, processing continues with the next management target.Otherwise,(2) The appropriate set of variablebindings is retrieved from localMIB instrumentation within the relevant MIB view. The relevant MIBview is determined by the securityLevel, securityModel,contextName, and securityName of the management target. Todetermine whether a particular object instance is within therelevant MIB view, the isAccessAllowed abstract service interfaceis used, in the same manner as described in the preceding section.If the statusInformation returned by isAccessAllowed does notindicate accessAllowed, the notification is not sent to themanagement target.(3) A PDU is constructed using a locally unique requestid value, anoperation type of SNMPv2Trap or Inform, an errorstatus anderrorindex value of 0, and the variablebindings suppliedpreviously in step (2).(4) If the notification contains an SNMPv2Trap PDU, the Dispatcher iscalled using the following abstract service interface:statusInformation = sendPduHandle if success errorIndication if failuresendPdu(IN transportDomain transport domain to be usedIN transportAddress destination network addressIN messageProcessingModel typically, SNMP versionIN securityModel Security Model to useIN securityName on behalf of this principalIN securityLevel Level of Security requestedIN contextEngineID data from/at this entityIN contextName data from/in this contextIN pduVersion the version of the PDUIN PDU SNMP Protocol Data UnitIN 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 thenotification. The contextName is the value originally determined for thenotification. 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 isexpected.Otherwise,(5) If the notification contains an Inform PDU, then:a) The Dispatcher is called using the sendPdu abstract serviceinterface as described in step (4) above, except that theexpectResponse argument indicates that a response is expected.b) The application caches information about the managementtarget.c) If a response is received within an appropriate time intervalfrom the transport endpoint of the management target, thenotification is considered acknowledged and the cachedinformation is deleted. Otherwise,d) If a response is not received within an appropriate timeperiod, or if a report indication is received, informationabout the management target is retrieved from the cache, andsteps a) through d) are repeated. The number of times thesesteps are repeated is equal to the previously determined retrycount. If this retry count is exceeded, the acknowledgementof the notification is considered to have failed, andprocessing of the notification for this management target ishalted.Responses to Inform PDU notifications will be received via theprocessResponsePDU abstract service interface.. Notification Receiver ApplicationsNotification receiver applications receive SNMP Notification messagesfrom the Dispatcher. Before any messages can be received, thenotification receiver must register with the Dispatcher using theregisterContextEngineID abstract service interface. The parametersused are: The contextEngineID is an undefined 39。wildcard39。 value.Notifications are delivered to a registered notific