Summary

  • RFC 1515 gave an Ethernet MAU a current jabber-state object, a counter of entries into jabber state and a trap for attracting a manager's attention.
  • Consecutive traps had to be separated by at least five seconds. The notification path was therefore deliberately pressure-limited and could not be treated as a complete count of transitions.
  • A later noJabber value did not erase the counter, while a counter increase did not prove that the fault remained present. Instance identity, applicability and the sender's observation epoch had to remain attached.

One quiet interval, three records

Consider an attachment unit that enters jabber state, returns to normal, then enters it again four seconds later. The example is hypothetical; the standards logic is not. The current-state object can follow the latest condition. The entry counter can advance on both transitions. The notification rule, however, forbids consecutive jabber traps less than five seconds apart.

A console fed only by traps may see one event. A poll taken after both transitions may see noJabber. A counter comparison may reveal two entries. None of the three records is defective. Each was designed to answer a different question.

This is the most interesting part of RFC 1515. It did not solve notification pressure by pretending that an alert channel could also be a forensic transcript. It retained a fast signal, a live state and an accumulated measure side by side.

The MAU became a named management object

Published in September 1993, RFC 1515 defined managed objects for IEEE 802.3 Medium Attachment Units. A MAU was the attachment function between an Ethernet-like interface or repeater port and the medium. The document provided one basic group for MAUs attached to repeaters and another for MAUs attached to interfaces.

Identity mattered before any alarm did. A repeater MAU row used a group index, port index and MAU index. An interface MAU row used the same interface index as MIB-II. A value without those coordinates could not say which physical attachment had changed.

The MIB also separated several properties that a dashboard might be tempted to flatten. Administrative status could be operational, standby, shutdown or reset where software control was supported. Media availability could report link loss, low light, missing loopback, remote fault or invalid signal depending on MAU type. Jabber had its own state and history. These were related observations, not aliases for a universal “port health” bit.

State answered “now”

For both repeater and interface MAUs, the jabber-state object offered four values: other, unknown, noJabber and jabbering. unknown was legitimate when the true state could not yet be known, such as during initialization. noJabber was the normal state. jabbering meant that the MAU was currently in jabber state.

The vocabulary was intentionally bounded. It did not name a defective board, cable or transmitter. It did not report duration, traffic loss or customer effect. It did not say that an operator had received an alert or that recovery had succeeded. It exposed the state that the agent could represent for that MAU instance.

There was also an applicability boundary. For an AUI view, the agent had to return other, and the associated entry counter remained zero. A clean-looking zero could therefore be a rule about the object, not evidence that every relevant physical problem was absent.

The counter remembered transitions

rpMauJabberingStateEnters and ifMauJabberingStateEnters counted entries into jabbering. That verb matters. A long episode could add one. Several short episodes could add several. The counter did not measure seconds, frames, users, bytes or emitted messages.

Its value also needed an observation history. The 2003 successor, RFC 3636, explicitly described discontinuities at management-system reinitialization and linked interface counters to ifCounterDiscontinuityTime. A manager that stored only the latest integer could mistake a reset for improvement or combine values from different epochs.

The counter did not replace state. If it increased and the current state was later normal, the proper record was “one or more transitions occurred in this epoch; this poll does not observe jabber now.” History and presence could be true in different directions.

The trap was allowed to be lossy by design

RFC 1515 defined one jabber trap for repeater MAUs and another for interface MAUs. Each carried the corresponding state object. The agent was to send the trap when a managed MAU entered jabber state, then throttle consecutive traps so that at least five seconds lay between them.

The requirement protected the management path from a burst of notifications. It also imposed a hard evidentiary limit. If multiple entries occurred inside the protected interval, a sequence of received traps could not be assumed to equal the transition count. “One alert” meant one alert was emitted and observed in the available record. It did not authorize “one underlying occurrence.”

The SNMPv1 specification, RFC 1157, defined a Trap-PDU separately from request and response operations. It carried the generating enterprise, agent address, trap identifiers, a timestamp since the network entity's last initialization and variable bindings. RFC 1215 supplied the convention used to define enterprise-specific traps. Those fields made a notification interpretable; they did not turn it into a complete incident journal.

The distinction survived faster Ethernet

The three-record design was not discarded as a quirk of 10 Mb/s hardware. RFC 2239 replaced RFC 1515 with a superset that added 100 Mb/s support, auto-negotiation and jack management. RFC 2668 extended the MIB again. RFC 3636 then added 10 Gb/s management and obsoleted both RFC 2668 and RFC 1515.

Across that lineage, the jabber state, entry counters and five-second notification gap remained. Applicability became more explicit: the later specification required zero for several faster MAU types. Evolution added types and capabilities without inflating the old object into a universal verdict.

This is running-code restraint in a small form. The common layer named what agents and managers could exchange deterministically. It did not dictate a global escalation policy, polling frequency or incident threshold. Those decisions stayed with implementations and operators.

Reconstructing without inventing

A defensible record preserves the MAU instance, its type, the current state, the transition counter, the counter epoch, notification timestamp, receive time and any known polling interval. It stores a trap as an observation from the sending agent, not as an assurance of end-to-end delivery. It also keeps media-availability and interface evidence distinct rather than using them to backfill a missing cause.

The resulting language is less dramatic but more useful. “The counter advanced by two while one trap was recorded” is supportable. “The port failed twice” may not be. “The current state is normal” is supportable. “The device recovered” needs a recovery definition and another receipt.

Lu Heng's essays on Running-Code Primacy, Minimum Initial Specification and reality layers sharpen this reading. The standard's labels are useful only while they remain attached to implemented observation. A notification may summon action, but it cannot acquire authority over facts its own transport and throttle were never built to preserve.

Sources and evidence boundary

The technical account rests on the RFC Editor's record for RFC 1515, RFC 1515, RFC 1157, RFC 1215, RFC 2239, RFC 2668 and RFC 3636. They establish object semantics, notification structure and standards lineage. The Lu Heng essays provide editorial discipline about layers, verifiability and local operational choice.

The source packet does not establish current product conformance, deployment prevalence, a named outage, notification delivery rates, packet loss, hardware damage or successful remediation. The two-transition opening is a logical demonstration of the throttle, not a reported incident.