Summary
- RFC 3434 paired every high-capacity magnitude with a validity-and-sign status, so zero plus
valueNotAvailable(1)meant retrieval failed, not that the monitored quantity equalled zero. - The specification preserved the alarm row, counted failed attempts, invalidated a delta whose previous sample was missing, and kept threshold transition, event association, notification delivery and operational response as separate evidence.
A zero with an alibi
Imagine a graph that drops to zero at 02:00. The line looks decisive. Traffic stopped, the interface went idle, the counter reset—or so the picture invites the reader to conclude. But the agent never obtained the counter. Its storage model needed something in the magnitude slot, so it wrote zero and placed the actual fact in a companion status: unavailable.
That distinction is the center of RFC 3434, the December 2002 High Capacity Alarm MIB. The document did not merely widen a number. It built a record in which magnitude and epistemic condition had to travel together. hcAlarmAbsValue carried an unsigned magnitude. hcAlarmValueStatus said whether that magnitude represented a positive value, a negative value, or no obtainable value at all. A consumer that copied only the number destroyed the meaning of the record.
The plain-text edition of RFC 3434, its RFC Editor record, the IETF document page, history and reference graph establish what was standardized and when. They do not establish that any named product implemented it, that any operator deployed it, or that a particular zero ever caused a false incident.
Why the old alarm table ran out of room
The earlier RMON MIB in RFC 2819 provided periodic sampling, rising and falling thresholds, and associations with an event table. Its alarm objects were designed around 32-bit values. By 2002, the mismatch was operationally obvious. RFC 2863 explained that a 32-bit octet counter could wrap in a little over 57 minutes at 10 Mbit/s, about 5.7 minutes at 100 Mbit/s, and roughly 34 seconds at 1 Gbit/s under the stated traffic model. Polling fast enough to disambiguate every wrap was becoming an increasingly fragile requirement.
RFC 3434 therefore defined a separate high-capacity alarm table for Counter64 and the CounterBasedGauge64 convention from RFC 2856. It did not silently reinterpret the old table. The two mechanisms were independent, although both could refer to the existing RMON event table. That architecture matters: compatibility was achieved by reusing a downstream event surface, not by pretending a 32-bit record could safely contain a 64-bit fact.
Magnitude was not enough
SNMP's data model could carry a large nonnegative counter, but delta sampling can produce a negative result. RFC 3434 represented a signed high-capacity quantity as absolute magnitude plus HcValueStatus. Positive and negative were explicit states. Unavailable was a third state, not a special numerical value that a graph could safely plot.
The same pattern governed thresholds. Rising and falling magnitudes were each split into a low 32-bit word, a high 32-bit word and a sign/status field. The absolute value was reconstructed as the low word plus the high word multiplied by two to the thirty-second power. A threshold could be positive or negative; unavailable was not permitted for an active threshold. Three objects were conceptually one value.
This is a useful historical rebuke to schema flattening. Export the low word without the high word and the threshold shrinks. Export the magnitude without the sign and a negative delta becomes positive. Export zero without validity and absence becomes activity. Every one of those failures leaves syntactically legal data behind.
The row survived the missed observation
RFC 3434 departed from the older alarm table in an important way: failure to retrieve the monitored instance during one interval did not destroy the alarm entry. The row could remain active. hcAlarmValueFailedAttempts accumulated how many polls made on behalf of that row returned no value.
This was continuity without fabrication. The configuration survived; the observation did not. A durable row proves that someone or something configured a monitoring rule and that the agent retained it. It does not prove that each interval produced a sample. The failure counter proves repeated retrieval failures occurred while active, but it does not identify whether access control, a missing object, an internal error, load, timing or another cause was responsible.
A missing sample also removed the next delta
The table supported absoluteValue(1) and deltaValue(2) sampling. Absolute mode compared the current retrieved value directly with thresholds. Delta mode subtracted the previous sample from the current one. That subtraction made the previous observation part of the current evidence.
If the prior instance could not be obtained, no honest delta existed. RFC 3434 required the result status to be unavailable for that interval. The later poll might succeed, but success could not manufacture the absent baseline retroactively. One missing observation therefore affected more than one point: it occupied its own interval with an unavailable record and denied the following interval a valid change calculation.
The sampling interval carried another boundary. For delta mode, it had to be short enough that the quantity was very unlikely to change by more than two to the sixty-third power minus one in one interval. A 64-bit field enlarged the range; it did not abolish sampling design.
Crossing, event and receipt were different facts
RFC 3434 retained the RMON pattern of rising and falling thresholds. A rising event occurred on a crossing from below to at-or-above the rising threshold. Another rising event was suppressed until the value passed through the opposite side and reached the falling threshold. The falling rule was symmetrical. This hysteresis prevented a noisy value near one threshold from producing an event on every poll.
Startup policy could generate one rising or falling event when the first valid sample already lay beyond a configured threshold. But even a qualifying transition did not guarantee a public event. A rising or falling event index of zero meant no associated event. A nonzero index with no corresponding event-table row also meant no association existed.
The chain was therefore conditional: retrieve a value; validate it; compute the selected sample; compare it with the correct signed threshold; determine a transition against the prior valid state; resolve an event-table association; execute that event's configured action; transport any notification; receive it; interpret it; respond. RFC 3434 specified important early links. It did not collapse the chain into “alarm handled.”
The variable pointer widened the trust surface
The monitored object was identified by a variable pointer and could be an integer-like MIB object beyond RMON itself. RFC 3434 identified a subtle access-control problem: SNMP views could control MIB access, but there was no satisfactory mechanism to constrain the pointer's value so that it named only objects in a particular view. The specification therefore warned that write access to the pointer should be granted only in views that could read every object on the probe.
The management framework in RFC 3410, the User-based Security Model in RFC 3414, and View-based Access Control in RFC 3415 supply the surrounding architecture. Their citation does not attest that a device configured authentication, privacy or views correctly. The definition machinery in RFC 2578, RFC 2579, RFC 2580, and the requirement vocabulary in RFC 2119 define how the module speaks, not whether an operator's deployment is safe.
The IANA SMI registry records the module's identifier context. The RFC 3434 errata search bounds known corrections at the time of capture. Neither is a telemetry feed about present use.
The durable lesson
The easiest dashboard stores one number per interval. RFC 3434 demanded a more honest object: number, validity, sign, sampling mode, baseline continuity, row identity and retrieval-failure history. The apparent complexity was not bureaucratic decoration. It prevented an unknown from borrowing the visual authority of zero.
The analytical discipline matches Heng Lu's account of reality layers and symbolic power: a displayed symbol gains institutional force when the machinery that qualified it disappears. It also matches the emphasis on running code and bounded claims: a standards object is valuable because implementations can preserve distinctions, not because the label alone guarantees their preservation.
RFC 3434's lasting contribution was not that it made alarms bigger. It made a failed observation representable without pretending that nothing happened—or that zero did.
Sources
- RFC 3434 — HTML
- RFC 3434 — plain text
- RFC Editor information record
- IETF Datatracker document
- IETF Datatracker history
- IETF Datatracker references
- RFC 3434 errata search
- RFC 2119
- RFC 2578
- RFC 2579
- RFC 2580
- RFC 2819
- RFC 2856
- RFC 2863
- RFC 3410
- RFC 3414
- RFC 3415
- IANA SMI numbers
- Heng Lu — reality layers
- Heng Lu — running code
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
