Appendix A. Disambiguating snmpTargetAddrTimeout and snmpTargetAddrRetryCount

The semantics of the snmpTargetAddrTimeout and snmpTargetAddrRetryCount objects need to be understood clearly to avoid confusion.

When used for generating a command request or an inform request:

• snmpTargetAddrTimeout specifies the maximum amount of time (in hundredths of a second) to wait for a response before considering the request as having timed out.

• snmpTargetAddrRetryCount specifies the number of times to retry a request before giving up.

For example, suppose an application sends an inform-request to a target with snmpTargetAddrTimeout = 1500 (15 seconds) and snmpTargetAddrRetryCount = 3. If no response is received within 15 seconds, the request is retried. This process continues until either a response is received or the request has been tried a total of 4 times (the initial try plus 3 retries). Thus, the maximum time to wait for a response would be 60 seconds (4 * 15 seconds), assuming no network delays.

When used for generating a notification (a trap or an unconfirmed inform):

• snmpTargetAddrTimeout is not used, since there is no response expected.

• snmpTargetAddrRetryCount is also not used, since notifications are sent once and are not retried.

It is important to note that these parameters only apply to the sending of messages that expect responses (command requests and inform requests). They do not apply to trap notifications, which are unconfirmed.

Additionally, implementations should be aware that these timeout and retry values interact with the reliability characteristics of the underlying transport protocol. For unreliable transports (such as UDP), these parameters provide the retry mechanism. For reliable transports (such as TCP), the transport protocol itself may handle retries, and these parameters may have different or limited applicability.

The key points to remember are:

1. Timeout value: The amount of time to wait for a single response attempt.
2. Retry count: The number of additional attempts after the initial attempt fails.
3. Total attempts: Always one more than the retry count (initial attempt + retries).
4. Scope: Only applies to operations expecting responses (command requests, inform requests).
5. Not applicable: Does not apply to trap notifications or operations over reliable transports where the transport handles retries.

By understanding these semantics, applications can properly configure target parameters for reliable and efficient SNMP operations.