Summary

  • RFC 1224 limited aggregate alerts from one agent with maxAlertsPerTime, windowTime and an alertsEnabled switch.
  • Crossing the pin sent one alertsDisabled notice and stopped further asynchronous reports, but that notice could itself disappear in the network.
  • A separate polled log retained numbered alert copies; retrieval or deletion of a row still did not prove human acknowledgement, remediation or service recovery.

The missing alarm was already part of the model

RFC 1224 appeared in May 1991. Its RFC Editor record classifies it as Experimental, while the IETF Datatracker preserves its Alert-Man working-group history. The memo did not define which conditions deserved an alarm. It addressed the management-information flow after an alert was generated.

That boundary mattered because asynchronous alerting failed in two opposite directions. A damaged machine or isolated network could not be trusted to announce its own failure. At the same time, a flapping link could generate so many unsolicited reports that the manager and the path to it became less capable precisely when they were most needed. The memo required both overload restraint and a way to detect or reconstruct missing information. Either mechanism alone left half the problem intact.

The contemporary transport context sharpened the point. RFC 1157 built SNMP messages on an unreliable datagram service and defined Trap-PDUs whose destinations were implementation-specific. RFC 1215 offered a convention for defining traps while strongly discouraging the creation of new ones. A trap definition described a message form. It did not manufacture delivery evidence.

The pin made silence a deliberate state

RFC 1224's first device was a sliding-window “pin.” Two values bounded the aggregate stream: maxAlertsPerTime and windowTime. The count applied across every alert type generated by an agent. It was not a separate allowance for each alarm category.

At startup, alertsEnabled was true. When an alert was generated, the agent checked the flag. If false, it sent nothing. If true, it sent the alert and retained its time for the window calculation. Once enough alerts fell inside the configured interval, the agent emitted one alertsDisabled notice and changed the flag to false.

The transition protected scarce CPU, manager capacity and network bandwidth. It also created a new ambiguity. The last notice—the one announcing that future notices had stopped—could be lost. RFC 1224 therefore advised managers to poll alertsEnabled during ordinary cycles. Discovering false state allowed a manager to re-enable the stream and record that traps might have vanished during the quiet period.

Silence was no longer negative evidence. It could be the output of a rate-control decision.

A log supplied custody, not a verdict

The second mechanism was “polled, logged alerts.” Each locally generated alert produced a row with an incrementing alertId and an OPAQUE alertData copy. A manager could ask for the next row or a named identifier, retrieve the encapsulated alert, and optionally remove it through an SNMP SET or the equivalent CMOT operation. RFC 1189 provides the contemporary CMOT/CMIP operation context used by those examples.

This was a custody path distinct from unsolicited delivery. If an agent became isolated, retained rows could still be polled after connectivity returned. But the history was finite. When a new row exceeded the table limit, the oldest row was replaced. Reading the oldest entry first reduced overwrite risk; it did not guarantee that every event survived until collection.

The identifier also carried only bounded meaning. A row proved that the described agent mechanism assigned an identifier and kept alert data at that moment. It did not prove that an asynchronous copy left the host, that the manager collected the row before wrap or overwrite, that the alert accurately described reality, or that anyone acted on it.

Deletion was another easily compressed event. Removing a row could mean that one manager had copied it. It could not establish acknowledgement by a person, ticket creation, remediation, fault clearance or restored service. In a multiple-manager environment, different communities could see different enable states and log views. One manager's reset or deletion need not settle another's record.

What reliable history would have to preserve

RFC 1224 divided one apparent “alarm” into a longer chain: condition, local rule, generated record, enable-state test, pin calculation, send attempt, network delivery, manager receipt, log insertion, manager poll, row return, deletion, operator decision and changed service state. Later systems may package these stages behind one interface. The evidence obligations do not disappear with the interface.

The memo also states that security issues are not discussed. Its examples of GET, SET and DELETE cannot support claims about authenticated identity or authorized action. Those would need their own records.

Sources