Summary

  • RFC 2155 defined DisplayableDlcAddress as an ASCII value for a management station to display, while directing operators toward a DLC-specific MIB for the real bytes carried in a data-link header.
  • APPN kept operational state, XID-derived peer identity, local configuration fallbacks, history rows and session evidence in separate objects; none could be inferred safely from a readable address.
  • A defensible record therefore joins the presentation label to a scoped DLC object, exact wire bytes, state and time, peer-observation provenance, and an independently observed session result.

A label designed not to carry authority

A network operator opens a late-1990s management station and finds a reassuring line: a local address, rendered in plain characters, beside a named link station. It looks like a key. It sorts neatly, fits in a ticket and can be pasted into an inventory. But the specification has already refused the inference the screen invites.

RFC 2155, published in June 1997 as a Proposed Standard, defined managed objects for Advanced Peer-to-Peer Networking, or APPN. Its DisplayableDlcAddress textual convention allowed zero to 64 ASCII characters. The management station was told to use the value only for display. The “real” DLC address—the bytes flowing in the data-link header—was often available from a DLC-specific MIB.

The word “often” matters. RFC 2155 did not promise that every agent could resolve the lower layer, and it did not say the display value was necessarily false. It made a narrower, more useful point: the display value did not carry the authority of the header bytes. An empty string meant the address was unknown to the agent. A non-empty string removed that one condition, but did not create uniqueness, freshness, adjacency or a successful session.

The pointer was a change of jurisdiction

The APPN port row exposed a local display address and also an appnPortSpecific RowPointer. A link-station row likewise exposed local and remote display addresses alongside appnLsSpecific. Those pointers could lead to an object in the appropriate data-link MIB. If the agent could not identify the object, the pointer was 0.0.

That arrangement is more than schema housekeeping. It says that APPN's presentation layer knows how to name what an operator should see, while the DLC-specific layer owns the form and scope needed to interpret what actually travels. The correct join is not “same characters, therefore same endpoint.” It is APPN instance, DLC type, specific-object pointer, lower-layer address, interface scope and collection time.

RFC 1747 makes the division concrete for SDLC. Its link-station address is a poll address from 1 through 255, unique within the defined SDLC scope, while contact state is held separately. RFC 2024 shows different DLSw forms, including six-byte MAC addresses and four-byte IP addresses in network byte order. One pleasant display string cannot, by itself, preserve the encoding and scope of every such transport.

A familiar name might have come from the local machine

Readable identifiers create a second trap. appnLsAdjCpName could report the adjacent control-point name received in an exchange identification, or XID. If no XID had arrived, however, the agent could return a locally defined value. If neither existed, it returned an empty string.

The same screen can therefore show an observed peer name or an operator's expectation of that peer. Both can be useful; they answer different questions. An incident record that stores only the text destroys the provenance distinction at the moment it is most needed.

The partner-node identifier had its own cautions. RFC 2155 derived it from bytes two through five of XID and used the ASCII value 00000000 when unavailable. Its node-identification convention also described a form ending in five zeroes to indicate an identifier that was not unique on that node. A familiar-looking node ID was not a universal identity certificate. The transmission-group number likewise used 256 to mean not negotiated or unknown.

State, history and success were different records

A link station could be inactive, pending active, active or pending inactive. RFC 2155 exposed that operational state separately from the display addresses. It also exposed good- and bad-XID counters, activation time and time in the current state. These objects can support a live-adjacency claim only when read together, with their collection window and counter continuity.

The link-station status table was not a catalogue of everything currently connected. It recorded exceptional or potentially exceptional activation, XID and termination events. Normal operation created no row, and products could choose how many rows to retain and for how long. A non-empty row may be valuable history; it cannot be promoted into a current-state assertion merely because it still exists.

The boundary continues above the link. RFC 2155 explicitly did not support monitoring or controlling endpoint sessions. Even an active link station with good XIDs does not, on that evidence alone, prove that an APPN session was established or that an application transaction succeeded.

The boundary survived its replacement

The RFC Editor record and Datatracker history place RFC 2155 in its standards history. RFC 2455 obsoleted it in November 1998 after APPN architectural additions and implementation experience. Yet the replacement retained the same display-only language and the same direction toward DLC-specific managed objects for header bytes. The distinction was not an incidental wording choice erased by revision.

Heng Lu's Running-Code Primacy offers a disclosed editorial lens: a management description matters when it can be joined to what a system actually executed. Minimum Initial Specification supports keeping deterministic claims small and locally verifiable. Reality Layers helps explain why a symbolic label should not inherit the authority of executable state. These are editorial interpretations, not requirements written into RFC 2155.

Sources