Summary

  • RFC 2020 treated a configuration write as intent: training stood between desired framing or promiscuous mode and the values that described the interface actually in service.
  • That separation had concrete consequences—current framing selected an MTU of 1,500 or 4,464 bytes, while an opened training state alone made ifOperStatus up.

The write was only the beginning

The tempting reading of a management interface is procedural. A manager writes a value; the agent accepts it; the setting has changed. RFC 2020, published in October 1996, made that sequence deliberately harder to misread for IEEE 802.12 links.

Its configuration table kept a desired framing type beside a current framing type. The desired object selected IEEE 802.3-compatible framing, IEEE 802.5-compatible framing, or either format for the next training attempt. The current object answered a different question: which framing was in use now? If the requested value allowed either, the current value still had to resolve to one actual format.

This was not bookkeeping pedantry. The format in current use set ifMtu. RFC 2020 assigned 1,500 bytes when current framing was the 802.3-compatible form and 4,464 when it was the 802.5-compatible form. Changing dot12DesiredFramingType might therefore change the MTU—but only after the interface next trained. A successful write could establish the request without establishing either the resulting frame format or its MTU.

The distinction is unusually clean because the consequence is observable. Desired value, training transition, current value and dependent MTU form an evidence chain. Remove any link and an operator can report a configuration that the interface has not actually achieved.

Familiar frames did not import a familiar access protocol

IEEE 802.12 could carry frames shaped like Ethernet or Token Ring. It did not use either technology's media-access protocol. Its own Demand Priority Access Method put master devices—repeaters or active controllers such as switches—in charge of deciding when requesting end nodes could transmit. End nodes and passive switches ordinarily operated as slaves.

RFC 2020 therefore rejected an easy category error. An agent should not apply the Ethernet-like MIBs in RFC 1643 or RFC 1650, or the Token Ring MAC MIB in RFC 1748, merely because the interface used the corresponding frame format. Those MIBs instrumented the access protocols that 802.12 did not implement. Only a narrower combination—Token Ring framing plus support for Token Ring source routing—called for RFC 1749.

The management lesson is precise: resemblance at one layer does not transfer the semantics of another. A frame's appearance did not identify who granted transmission, which access algorithm ran, or which MAC counters had meaning.

Training converted a preference into evidence

Training frames were special MAC frames used only during link initialisation. The slave at the lower end initiated them; the master at the upper end responded. RFC 2020 recorded configuration bits from the most recent error-free training frame and described a completion condition of 24 consecutive error-free training frames, intended to prevent marginal links from completing training.

That exchange gave the desired/current split teeth. dot12Status could be closed, opening, opened, open failure or link failure. ifOperStatus was up only for opened; during closed, opening, open failure or link failure it was down. A manager could command an interface to open or reset, and changes to desired framing, desired promiscuous status or control mode could start retraining. None of those triggers was itself an opened result.

Promiscuous mode made the same boundary even more explicit. dot12DesiredPromiscStatus selected the mode requested in the next training packet. The master was not obliged to grant the request. Writing ifPromiscuousMode updated the desired value and caused a retraining attempt; after training, however, ifPromiscuousMode had to report the mode actually in use, not the mode requested. dot12LastTrainingConfig preserved the configuration returned by the last error-free exchange.

In other words, RFC 2020 did not confuse an instruction, a negotiation and a result. It gave each a separate observable place.

“Master” named a protocol role

dot12ControlMode could report master, slave or a learning state used while an interface autosensed the role. Some implementations could expose the object as read-only when a physical control or fixed hardware determined the mode; changing a software-controlled value caused retraining.

The term master is easy to inflate. In this document it meant the link participant that controlled Demand Priority transmission grants. It did not establish ownership of the equipment, administrative sovereignty, successful packet delivery or authority outside that protocol exchange. The object narrowed the claim to the operating role that the interface could report.

Arithmetic was not an outcome

RFC 2020 omitted normal-priority transmit counters because they could be derived. Normal-priority frames were total unicast, multicast and broadcast output minus high-priority output; normal-priority octets were total output octets minus their high-priority counterpart. Receive accounting was less reducible because error frames and unreadable octets changed what the available counters contained.

These formulae are useful, but their evidentiary ceiling is low. They relate specified observations. A derived traffic total does not prove that a packet reached its destination, that an application completed work, or that a service met an obligation. The RFC's Security Considerations section supplies an equally firm boundary: security issues were not discussed. Neither an opened link nor an accepted training configuration is authentication, confidentiality or proof of safe operation.

Two standards lifecycles, not one contradiction

The current RFC Editor and IETF records still list RFC 2020 as a Proposed Standard, and the RFC Editor errata search returned no matching errata when checked on 11 September 2026. Those records do not identify an obsoleting RFC.

IEEE's current record describes a different documentary object. It marks IEEE 802.12-1995 as Inactive-Withdrawn and dates withdrawal to 15 January 2001. IEEE 802 also lists the Demand Priority Working Group among its disbanded activities. This later administrative history does not appear in the 1996 RFC and says nothing by itself about deployment, commercial success or operational performance.

The two records can coexist. One preserves an IETF management specification in its standards category; the other records the lifecycle of the underlying IEEE standard and working group. Treating either label as a measurement would repeat the very mistake RFC 2020 was designed to prevent: substituting an administrative state for evidence about a running system.

Sources