Summary

  • RFC 1516 let an agent delay a requested repeater reset just long enough to transmit the SNMP response; that response identified the management exchange, not completed physical action.
  • The disruptive self-test left packet transfer uncertain, while management counters and port administrative state explicitly survived.
  • Health updates and a reset-event notification followed later. Even those records did not prove that traffic or a dependent service had recovered.

The last reply before uncertainty

Imagine a management station writing reset(2) to a repeater. A green response arrives. The tempting story is short: the reset succeeded. RFC 1516 described a more careful sequence. The agent was allowed to postpone the reset briefly so the response could be transmitted, and the response had to be transmitted “in any event.” The device could answer precisely because the disruptive part had not yet happened.

That order placed an evidentiary seam inside one familiar operation. The response could correlate with the outstanding SNMP request. It could show that the agent accepted and processed the Set operation without a protocol error. It could not already report the end of an action that followed it.

The difference mattered because the reset included a disruptive self-test. Its method was not standardized. It was not to inject packets or interfere with management functions, but packets arriving during the test might or might not be transferred. A clean management exchange could therefore coexist with an indeterminate data-plane interval.

A command that never stayed set

RFC 1516 defined managed objects for 10 Mb/s IEEE 802.3 repeaters, often sold as hubs. It chose the narrower name “Repeater MIB” because a commercial hub or concentrator could contain Token Ring, FDDI, bridging, routing and terminal-server functions beyond the document’s scope.

The rptrReset object also resisted being treated as a workflow flag. Writing reset(2) caused a transition to the repeater START state. Writing noReset(1) did nothing. Reading the object always returned noReset(1). A later read could not tell a manager whether no reset had been requested, whether one was under way or whether one had finished.

This was not a defect in a status field. It was a command surface presented through a managed object. A collector that stored its readback as “reset false” would be recording the object’s defined resting value, not reconstructing the action.

What the reset was forbidden to erase

RFC 1516 made two continuity rules explicit. The reset did not reset the management counters defined in the MIB, and it did not change portAdminStatus. The self-test reset the repeater without changing its management information.

Those clauses protected history and policy from being mistaken for disposable hardware state. A disabled port was not silently re-enabled because the repeater restarted. A counter did not acquire a new epoch merely because a disruptive command ran. Conversely, a post-reset counter value did not prove that every packet observed during the test had been transferred.

The distinction is operationally useful. Hardware state can restart while administrative intent persists. Measurement history can persist while the forwarding interval remains uncertain. Treating “reset” as “erase everything” would destroy exactly the evidence needed to compare the system before and after intervention.

Completion arrived on another channel

After the self-test, the agent was to update rptrOperStatus and the agent-specific rptrHealthText, then send a health trap. RFC 1516 separately defined rptrResetEvent, sent on completion of a management-triggered reset and carrying operational status. A response to the Set request and a reset-completion notification were thus different records with different times and purposes.

Even the later record had limits. Consecutive reset-event traps had to be at least five seconds apart; throttled traps were dropped, not queued. An agent restart used coldStart or warmStart rather than rptrResetEvent. Missing the completion trap could reflect notification policy or a different kind of restart, not a universal proof that nothing happened.

Health was bounded too. rptrHealthText was explicitly agent-specific. The non-disruptive test could report “okay” after a trivial test. An operational status could describe what the agent knew about repeater health without proving end-station reachability, application success or the absence of loss during the reset window.

The clarification survived its replacement

The earlier RFC 1368 already said the reset preserved counters and port administrative settings. RFC 1516’s change list called out two clarifications: the agent could briefly delay the reset, and the post-reset/self-test behavior was more precisely stated. The ordering rule was therefore not incidental prose; it was an explicit correction to the management contract.

RFC 2108 later replaced RFC 1516 with an SMIv2 superset for multiple repeaters and 100 Mb/s equipment. It deprecated the old single-repeater scalar but retained the same rule in rptrInfoReset: the response had to be transmitted before the disruptive action, management state survived, and a separate rptrInfoResetEvent represented completion. The model grew without collapsing receipt into outcome.

At the protocol layer, RFC 1157 explains how a request ID correlates a response with an outstanding request and how a successful Set produces a no-error response. RFC 1215 supplies the trap-definition convention used by RFC 1516. Together they identify the messages. They do not give one message authority over facts produced later by the physical and service layers.

A reset record that can be audited

A defensible record keeps the requested object and value, request ID, agent identity, response code and receive time. It separately stores when disruptive action began, which management counters and port settings remained continuous, when health changed, which completion notification was emitted and received, and which independent traffic or service check followed.

The language then becomes precise. “The agent returned noError for the reset Set” is one claim. “The repeater emitted a reset-completion notification” is another. “The same administrative port state survived” is testable. “Users could exchange traffic again” needs a separate observation.

Heng Lu’s essays on Running-Code Primacy, Minimum Initial Specification and reality layers make the older MIB legible as a governance design. The shared standard fixed a narrow, testable exchange. Implementations still owned the self-test, operators owned the authority to invoke it, and running traffic supplied the evidence of consequence.

Sources and evidence boundary

The RFC Editor’s record for RFC 1516, RFC 1516, RFC 1368, RFC 1157, RFC 1215 and RFC 2108 establish the document history and management semantics. The three Heng Lu essays provide the editorial discipline for keeping symbolic, implemented and observed facts separate.

The sources do not establish a named product, deployed repeater, executed reset, response delivery, test duration, trap capture, packet result, outage, recovery or current prevalence. The opening is a standards-derived reconstruction, not a reported incident.