Summary

  • RFC 1215 supplied a TRAP-TYPE convention for mapping a registration authority, ordered variables, textual meaning and an integer into an SNMPv1 Trap-PDU. The definition was assembled during implementation, not when an event occurred.
  • A trap described what a sending application or protocol entity recognised. That source-side assertion did not independently prove a physical fault, root cause, customer impact or authenticated identity.
  • SNMPv1 used an unreliable datagram service, and destinations were implementation-specific. Definition, recognition, generation, transmission, receipt, confirmation, operator action and recovery were separate records.

The alert existed before the incident

The most useful sentence in RFC 1215 appears before its examples: expansion of the TRAP-TYPE macro happens conceptually during implementation, not at runtime.

That timing changes the meaning of the artefact. An implementer can define myLinkDown, assign an enterprise, choose an ordered variable and write a description before any link fails. A compiler or management tool can understand the shape. A receiver can prepare a display rule. None of that work is a sensor observation.

The distinction was easy to lose because a trap definition uses event-like language. Its description might say that a sending entity recognises a link failure. Its integer might resemble a code in an incident stream. Its variable list might look like a ready-made evidence bundle. Yet the definition is closer to a blank form than a completed report. It describes which fields would carry meaning if an instance were generated.

The RFC Editor record dates the memo to March 1991 and classifies it as Informational. The IETF Datatracker record preserves the same identity. The text itself says traps were controversial in the Internet-standard management framework and strongly discourages their use. The convention was meant to describe existing traps concisely, not to stimulate a new crop of them.

That caution is not evidence that traps were absent or useless. It is evidence about the document’s ambition. RFC 1215 supplied a shared descriptive surface while refusing to turn that surface into a general endorsement or an Internet Standard.

Four clauses built a type

The TRAP-TYPE macro joined four different kinds of information.

ENTERPRISE was required. It named the management enterprise under whose registration authority the trap was defined and mapped into the enterprise field of the SNMPv1 Trap-PDU. Registration authority answered “whose namespace contains this definition?” It did not answer “which natural person sent this datagram?” or “who currently owns this device?” An object identifier was not a signature, a credential or permission to act.

VARIABLES was optional. When present, it specified an ordered sequence of MIB objects expected in every instance of that trap type. The order mattered because the objects were copied into the variable-bindings field in order. The agent could also append more variables.

That made the list a minimum shape, not a claim that the eventual notification was complete in every operational sense. It did not contain the values of a future instance. It did not say that every appended object would be interpreted identically by every manager. It did not convert an interface index into proof that a cable, port, circuit or customer service had failed.

DESCRIPTION gave the type a textual meaning. If the MIB module defined no equivalent text elsewhere, the clause had to be present. But prose inside a module was still specification prose. It did not become an independent witness merely because a runtime PDU later referred to that type.

REFERENCE could point to a related trap, event or alarm defined elsewhere. A cross-reference connected definitions. It did not prove that the referenced alarm existed in a particular deployment, that two events were the same, or that either one had happened.

Finally, the macro’s integer value mapped into the PDU. For an enterprise-specific trap it became specific-trap, while generic-trap became enterpriseSpecific(6). Under the special snmp convention, the value went into generic-trap and specific-trap became zero.

The number therefore occupied a namespace. It was not severity, confidence, frequency, chronology, incident count or an acknowledgement status. Treating it as any of those would add semantics the source did not assign.

A registry name did not authenticate a sender

The enterprise field invited a familiar institutional shortcut. If a trap carried an enterprise object identifier associated with an organisation, an operator might read the organisation’s identity directly into the packet.

RFC 1215 supports a narrower claim. The field identifies the registration authority under which the trap is defined. In the convention for standard SNMP traps, the agent’s sysObjectID is placed in the enterprise field. Both are useful for interpretation. Neither is cryptographic proof of origin.

Several records can diverge. A vendor can register a definition. A later company can acquire a product. An integrator can deploy the agent. A local administrator can configure destinations. A process can emit a packet using a community and object identifiers. The object identifier alone does not collapse those parties into one authenticated actor.

RFC 1215’s security section says only that security issues are not discussed. Silence there cannot be upgraded into authentication, integrity, confidentiality or replay protection. A management system needs separate evidence for those properties.

The example reported recognition, not physical truth

RFC 1215 demonstrates an enterprise-specific myLinkDown trap. Its description says the sending SNMP application entity recognises a failure in one of the communication links represented in the agent’s configuration.

The grammatical subject matters. The sending application recognises. The trap does not claim that an independent tester measured the physical path, that a carrier accepted responsibility, or that users lost service. The configured object might represent an interface whose lower layer changed. A local threshold, driver state, polling result or implementation rule could have produced the recognition. Root cause and impact remained open.

The generic link-down example in RFC 1157 uses the same boundary: the sending protocol entity recognises a failure. Its first variable binding identifies the affected ifIndex instance. That identifier locates the configured interface record. It is not the entire fault tree.

The Trap-PDU timestamp has a similar limit. It measures time elapsed between the network entity’s last reinitialisation and generation of the trap. It is not necessarily the wall-clock time at which a cable failed, the first instant a user noticed degradation, or the moment a manager received the packet.

A useful incident chronology would therefore keep at least four clocks: the suspected condition’s first observation, the application’s recognition, PDU generation and receiver arrival. RFC 1215 defined none of them as interchangeable.

Generation required another actor

A type definition could sit unused forever. RFC 1157 placed the next action with the SNMP application entity. The protocol entity generated a Trap-PDU only at the application entity’s request.

This separated the event-detection policy from the wire format. The application decided that something merited notification. The protocol entity constructed and sent the PDU. Destination addresses were chosen in an implementation-specific way.

Configuration therefore intervened between definition and audience. A perfectly defined trap could go nowhere because no destination was configured. It could go to an obsolete manager. It could be suppressed. It could be routed to a receiver that parsed the PDU but had no rule for its enterprise-specific meaning.

RFC 1215’s authentication-failure example makes suppression explicit. Implementations had to be capable of generating that trap and also capable of suppressing its emission through an implementation-specific mechanism. No trap could mean “no authentication failures”, but it could equally mean “not recognised”, “not requested”, “suppressed”, “misaddressed”, “lost” or “not processed”.

The absence was an unknown state with several mechanisms behind it. It was not a clean negative fact.

The network carried a datagram, not a promise

SNMPv1 deliberately required only an unreliable datagram service. RFC 1157 represented each message in one transport datagram and specified UDP for the exchange. Messages reporting traps were to be received on UDP port 162 for further processing.

“Should be received” named a service convention. It did not establish that a listener existed, a firewall admitted the packet, buffers held it, the receiver parsed it, storage persisted it or an operator saw it. UDP carried an attempt without a built-in delivery acknowledgement.

RFC 1157 does describe what happens upon receipt: the receiving protocol entity presents the Trap-PDU contents to its SNMP application entity. Receipt therefore had a protocol meaning. It still stopped before human interpretation or corrective work.

Later SNMP documents made the transport distinction explicit without rewriting the 1991 evidence. RFC 2578 treats RFC 1215 as part of SMIv1 and defines NOTIFICATION-TYPE in SMIv2 as a concise description of notification syntax and semantics. A newer macro still describes a notification type; it is not the occurrence.

RFC 3416 says an SNMPv2-Trap has no confirmation associated with its notification-delivery mechanism. It also defines InformRequest as confirmed, while warning that confirmation offers no guarantee of delivery. On receipt, the receiver presents the contents and sends a Response-PDU.

That response is stronger evidence than silence. It supports a protocol exchange with a receiver. It does not independently validate the original condition, prove that an operator agreed with the interpretation, or show that remediation succeeded. Confirmation narrows one gap. It does not erase the chain.

A notification pipeline is a chain of custody

The durable lesson of RFC 1215 is not that alerts are weak. It is that every useful alert has a custody trail.

The definition author controls the type’s syntax and prose. A registration authority controls the namespace. An application controls recognition policy. A protocol entity constructs the PDU. Local configuration controls destinations and suppression. A network offers transport. A receiving entity controls protocol acceptance. A management application controls correlation and presentation. An operator or automation system controls action. Later measurements control the evidence of recovery.

Compress those roles and a clean-looking code becomes an incident verdict. Preserve them and a trap becomes what it should be: a bounded assertion whose value increases as independent evidence joins it.

Sources