Summary

  • RFC 1317 defined managed objects for RS-232-like physical links beneath higher-level Character and PPP MIBs, with separate records for port parameters, error counters and control signals.
  • Its autobaud object explicitly allowed a management system to observe speed, parity or character-size values temporarily different from what had previously been set.
  • A configuration/observation mismatch therefore did not by itself prove a management write, an operator decision, a durable change, a peer identity, a formed session, transferred content or a successful result.

The console was not contradicting itself

In the mythology of administration, configuration is a command and telemetry is its obedient reflection. Set a value; read the same value back. If the two differ, look for the person or process that changed it. That mental model is attractive because it turns a discrepancy into a small detective story.

RFC 1317 made the story harder, and more accurate. Published in April 1992, it defined a Management Information Base for RS-232-like hardware devices: not only RS-232, but RS-422, RS-423, V.35 and related asynchronous or synchronous serial links with similar control signals. It placed this MIB at the physical layer, below services represented by a Character MIB or a PPP MIB. A hardware port could support a terminal-like application or a network connection, but the physical MIB did not inherit either application's claims.

That architecture matters before any object is read. A physical port record can describe the connector-facing layer truthfully while saying nothing about a user, a session or a packet path. A higher layer may depend on it, yet dependence is not identity. The port's observed condition is not the session's state. A session's state is not proof of a message or business result.

RFC 1317's most revealing sentence appears inside a seemingly modest control: autobaud. When the feature is enabled, the port may adapt to input and produce values different from the configured speed, parity and character size. A management system may temporarily observe those different values. In other words, the console can report something other than the setting without either record being false.

One port, several kinds of record

The MIB begins with a count of RS-232-like ports and a general port table. Each port has a local index, a hardware type, counts of represented input and output signals, and input and output speed values. The index is intended to remain stable across at least one management-agent re-initialization to the next. It identifies a table entry and, where possible, maps to an external connector. It does not identify a remote person, modem subscriber, terminal user or organization.

Separate tables carry attributes that apply to asynchronous or synchronous ports. An asynchronous entry has character width, stop-bit policy, parity policy, autobaud control and counters for parity, framing and overrun errors. A synchronous entry has clock-source policy and counters for frame-check errors, transmit underruns, receive overruns, interrupted frames and aborted frames. Input and output signal tables separately record named physical control lines, their current state and their transition counts.

This is not redundant bookkeeping. It prevents one kind of observation from swallowing another. Port type answers what hardware family the entry describes. A set parameter records administrative intent at that object. Autobaud records whether the port may sense incoming timing. A temporarily observed parameter records what the port currently exposes. An error counter records classified occurrences inside a stated window. A control-signal row records a particular line and direction.

If all of those are collapsed into “serial port status,” the dashboard becomes easy to read and difficult to trust. The phrase offers no way to tell whether a value was configured, sensed, counted or asserted. RFC 1317's tables are useful because they keep those verbs apart.

Autobaud broke the simple mirror

rs232AsyncPortAutobaud is a read-write control with enabled and disabled states. Its purpose is to let the port sense input speed automatically. The important consequence is not merely that a device can find a baud rate. The RFC says that the port may autobaud to values different from the set speed, parity and character size, so a management system may temporarily observe values different from what was previously set.

That sentence separates at least four records. There is a prior management setting. There is an autobaud policy that permits adaptation. There is a temporarily observed value. There is a later decision about whether the observation requires intervention. None can be inferred wholly from another.

Suppose a management view shows a different character width from the stored setting. The view establishes the value exposed through the MIB at that observation time, subject to the implementation and collection path. If autobaud is enabled, the RFC supplies an allowed mechanism for the difference. It does not identify which incoming sequence drove adaptation, how long the value persisted, whether an authenticated operator wrote anything or whether the port later returned to the earlier setting.

The difference also does not identify a peer. Physical timing can be evidence relevant to a connection, but it is not an identity credential. It does not prove which device sits beyond the cable, who controls it, whether a Character-layer session was formed or whether PPP negotiation completed. A physical-layer adaptation is a bounded event at its own surface.

This is why “configuration drift” is too large a label for the raw observation. Drift implies a relationship across time and often implies an unwanted change. RFC 1317 offers a narrower description: prior set value, autobaud enabled, temporarily observed different value. A drift conclusion requires additional evidence about persistence, desired state and change authority.

Error totals did not supply a cause

The asynchronous table's error counters look more conclusive because they count things with names: parity errors, framing errors and overrun errors. The RFC bounds them carefully. Each counter covers characters input since system re-initialization while the port state was up or test.

That scope is valuable. A counter increase can show that the agent classified more input characters under a named error condition during the relevant lifetime. It may support investigation of mismatched parameters, timing, cabling, equipment or load. It does not select one cause. A parity-error total cannot, on its own, prove that parity configuration was wrong. A framing-error total cannot prove which device sent the input. An overrun counter cannot say which application failed to consume data or whether any application-visible loss followed.

Counters also lose sequence. A total does not preserve when each occurrence happened, which observed parameter was active, which signal changed first or how long a condition lasted. Comparing two samples can bound a delta in a time interval, but it still does not manufacture a remote identity or a causal chain.

The synchronous counters are equally bounded. A frame-check error, underrun, overrun, interruption associated with loss of modem signals or received abort sequence is a classified lower-layer record. It is not automatically an outage ticket, a failed customer transaction or proof of negligence. The path from counter to cause requires correlation; the path from cause to outcome requires still more evidence.

Signals described a line, not an actor

RFC 1317 also defined separate input and output signal tables. Their names include Request to Send, Clear to Send, Data Set Ready, Data Terminal Ready, Ring Indicator and Received Line Signal Detector. A row records the signal name, a current state of none/on/off and a count of on/off transitions.

The familiar names tempt narrative expansion. Ring Indicator sounds like a caller. Data Terminal Ready sounds like a ready terminal. Clear to Send sounds like permission. Yet each is a hardware convention at a particular physical interface and direction. An input signal is one the software can detect. An output signal is one the software can assert. A detected line does not authenticate the remote actor; an asserted line does not prove the far side honored it.

The transition counter likewise counts line changes, not calls, users, sessions or messages. A DCD change may be useful for correlating a physical-carrier event, but it does not tell a complete communications story. The evidence record needs port index, signal direction, signal name, sampled state, counter value, collection time and agent identity before it can even be aligned with higher-layer evidence.

The 1994 revision kept the distinction

RFC 1659 obsoleted RFC 1317 in July 1994 and expressed the RS-232-like MIB in SMIv2. It retained the physical-layer placement and the substantive autobaud caveat: an enabled port may adapt to values different from the set speed, parity and character size, and management may temporarily observe values different from those previously set.

That continuity is historically useful. The distinction was not an accidental phrasing around one old object. It survived the MIB's revision because the physical mechanism still defeated the simplistic idea that configuration and observation must always be identical. The successor record does not prove how widely either RFC was implemented. It proves only that the model's authors carried the boundary forward.

A discrepancy needs a tuple, not a verdict

A defensible operational record for this situation is a tuple. It names the port index and hardware type; set speed, parity and character size; autobaud state; observed values; sampling time; agent re-initialization boundary; relevant error-counter samples; input/output signal state; and any higher-layer session or interface identifiers available elsewhere.

Only after those records are aligned should an operator ask whether there was an authenticated management write, an unauthorized change, a peer-specific adaptation, a persistent incompatibility or an application impact. A change log can establish who or what wrote configuration. A session log can establish higher-layer establishment. Traffic or application records can establish transferred content and outcome. RFC 1317 supplies none of those by merely showing a different value.

This is the historical lesson hiding in a vintage serial-port MIB. Telemetry is not a confession by an operator. A configured value is not guaranteed to be the only value a physical mechanism can truthfully expose. When the setting says one thing and the port reports another, the first duty is to preserve both records and identify the mechanism between them—not to invent the person, session or result that the MIB never observed.

Sources and evidence limits

This article relies on RFC 1317, Definitions of Managed Objects for RS-232-like Hardware Devices (April 1992), and RFC 1659, its July 1994 SMIv2 successor. They support the physical-layer scope, table separation, autobaud observation caveat, bounded error counters, control-signal states and successor relationship. They do not establish an actual device, setting, management write, operator, peer, session, payload, deployment, delivery or application result.