SNMP INFORM
INFORM does the same basic job as a TRAP - an unsolicited notification sent when something happens, rather than in response to a request - with one significant difference: it's acknowledged. The receiving manager sends back a confirmation, and if the sender doesn't get that confirmation within a timeout, it retries, the same way a GET request would. A trap, by contrast, is sent once and forgotten regardless of whether it actually arrived.
INFORM was introduced alongside GETBULK in SNMPv2c, and is also available in SNMPv3. SNMPv1 has no equivalent at all - only the older trap mechanism.
Why the acknowledgment matters
Because SNMP runs over UDP, delivery was never guaranteed to begin with - see what is SNMP for why that tradeoff was made in the first place. A trap sent during a brief network blip, or while the manager happens to be restarting, is simply gone, with the sender having no idea it never arrived. INFORM closes that specific gap: the sender knows whether the notification actually got through, and if it didn't, it tries again - the same reliability guarantee a normal request/response exchange already has.
The real cost: it isn't free
That reliability comes at a genuine resource cost on the sending side. Sending an INFORM means holding onto it - tracking that it's still awaiting acknowledgment, re-sending it on a timer, eventually giving up after some number of attempts - rather than simply firing a UDP packet and moving on immediately. On a device already under load, or one sending a large volume of notifications, that bookkeeping is a meaningfully bigger ask than a plain trap.
When to actually use INFORM instead of TRAP
The practical rule of thumb: if losing this specific notification would genuinely matter - a security event, a hardware failure, anything you'd actively want to know even if the network briefly hiccuped at the exact wrong moment - INFORM is worth the extra overhead. For high-frequency, lower-stakes notifications where an occasional missed message isn't a real problem (and where the next one will likely arrive soon regardless), a plain trap is usually the more sensible, lighter-weight choice. Many real deployments use both, choosing per notification type based on how much a missed delivery would actually cost.
Manager-to-manager INFORM
Although the most common case is a device (technically acting as an SNMP entity capable of sending, even though it's not a full manager) sending an INFORM to a monitoring platform, the mechanism itself is general: it's really designed for one SNMP entity notifying another, which is also how a distributed, multi-tier monitoring setup can have one management station reliably forward an event up to another.