Summary

  • RFC 2051 made its Admin tables read-only views of configured defaults and its Oper tables witnesses of current or negotiated state; it explicitly allowed an administrative mode row to be deleted while an active session and its operational row survived.
  • Sessions, conversations, optional counters and abnormal-history rows followed different creation and deletion rules. None alone proved configuration, peer agreement, application success, completeness or security.

The most revealing object in RFC 2051 is an absent row. The 1996 APPC MIB says an appcModeAdminEntry may be deleted even though an active session is still using that mode. The corresponding appcModeOperEntry continues to exist. A management screen can therefore show no administrative template and still truthfully show a running relationship below it.

That was not a database accident. It was the architecture. Administrative tables represented default or expected configuration, but the MIB did not create or modify that configuration. Their objects were read-only. Operational tables represented what existed now or what two systems had negotiated. A dynamic object could begin with an Admin row as its template, then acquire a lifecycle of its own.

The separation matters because “configured”, “requested”, “accepted”, “negotiated” and “running” are different claims. A removed configuration record says that a template is no longer presented at the administrative surface. It does not rewind an already established session. Conversely, a surviving operational row does not prove that the old template is still approved for future use.

RFC 2051 organised the model into global, logical-unit, transaction-program, session, conversation and CPI-C groups. This breadth can tempt a reader to treat the MIB as a remote control for APPC. The RFC drew a narrower boundary. It did not generally create or delete partner LUs, modes or transaction programs; activate or deactivate LUs and programs; start conversations; or activate sessions. Those operations remained outside the instrumented surface.

Some control did exist, but it was specific. Managers could choose statistics or tracing states, issue Change Number of Sessions commands and request that a session be deactivated. Those writable objects were requests at a control surface. They were not receipts for the result.

CNOS makes the distinction concrete. Administrative CNOS objects carried desired values. Operational objects carried actual values after negotiation. IBM's current explanation of starting sessions still expands CNOS as Change Number Of Sessions and describes negotiation per mode. That page supplies terminology, not evidence that a particular product implemented the RFC or that any negotiation succeeded.

The active-session table had its own clock. A row could be unbound, pendingBind, bound or pendingUnbind. The agent created and removed it according to the lifecycle in the specification. Writing unbound against a bound session could initiate deactivation. The write proved an instruction was submitted; the later operational state was needed to show what the agent did.

Even “bound” has a limited meaning. It records a session state. It does not say that a conversation was allocated, that a transaction program completed, that its peer returned correct data or that a business process succeeded. Peer state and application result sit beyond the session row.

Conversations were shorter-lived witnesses. The agent created an active-conversation row when a conversation began and removed it when the conversation ended. An active conversation was associated with a session, but it was not the session. Several conversations could pass through a session whose own lifetime continued before and after them.

Statistics formed another optional layer. When collection was active, the agent created a statistics row for each active session. The counters used the SNMPv2 Counter32 type defined in RFC 1902 and were paired with an uptime for the counting interval. A number without its interval, wrap behaviour and collection state cannot be promoted into a complete history.

The RFC made the fragility unusually visible: setting the administrative statistics state to inactive removed all rows from the session-statistics table. It did not say that active sessions were thereby terminated. Empty counters could mean collection was switched off, not that activity ceased.

History was selective too. The historical session table retained abnormally terminated sessions, while the historical conversation table retained conversations that ended with errors. How many entries remained, or for how long, depended on the implementation. Absence from those tables could not prove that no normal activity occurred, or even that every earlier abnormality remained available.

The larger lineage is documented in the referenced SNA management model, RFC 1666. It helps locate the APPC MIB in a family of management instruments; it does not turn a definition into deployment evidence. A standards document can specify objects precisely while saying nothing about whether an operator installed, enabled, secured or interpreted them correctly.

The status needs equal care. The IETF Datatracker record and RFC Editor information page identify RFC 2051 as a Standards Track Proposed Standard published in October 1996. The captured RFC status-change index does not list a later status change for it, and the official record shows no updating or obsoleting RFC. It is old and describes legacy technology, but the frozen official evidence does not support calling its formal status Historic.

The RFC Editor errata search returned no matching errata. That narrows one kind of documentary uncertainty. It does not certify implementations, interoperability, completeness or current relevance.

Security is the sharpest limit. RFC 2051 says security issues are not discussed. Its Standards Track label therefore cannot be converted into evidence of access control, safe management writes or trustworthy counters. A session can be operational without being secure, and a management object can exist without revealing who was authorised to change the underlying system.

Read correctly, the MIB is a set of witnesses with different jurisdictions. Admin tells what configuration was presented. A writable control tells what was requested. The agent's next state tells what it accepted. CNOS operational values tell what negotiation produced. A session row tells whether a transport relationship is active. A conversation row tells whether one unit of application interaction exists. Counters tell what was measured while collection ran. History records selected abnormal endings. The peer and application must provide their own receipts.

That chain explains why the missing row matters. Configuration often looks like authority because it is easy to edit and archive. Runtime state looks like compliance because it is visible after the edit. RFC 2051 refused both shortcuts. Once a session exists, its truth can outlive the template that helped create it; once a counter table is cleared, the running session can outlive its evidence.

Sources