摘要

  • RFC 2051 的 Admin 表只读呈现默认或期望配置，Oper 表呈现当前或协商后的运行值；规范明确允许模式的 Admin 行被删除，而使用该模式的活动会话及 Oper 行继续存在。
  • 活动 session、单次 conversation、可选统计和异常历史各有独立的生成、删除与保留条件；任何一张表都不能单独证明配置、对端同意、业务成功、记录完整或系统安全。

RFC 2051 最有力量的例子不是某个计数器，而是一行已经不存在的记录。规范说，appcModeAdminEntry 可以在某个活动会话仍使用该 mode 时被删除，appcModeOperEntry 仍然存在。管理者看到的并非矛盾数据：上层配置模板已经撤去，下层运行事实尚未结束。

这正是 Admin 与 Oper 的职责边界。Admin 表展示默认值或期望值，但 MIB 本身不负责创建、修改这些配置，对象因此是只读的。Oper 表则展示当前值或协商值。动态对象可能以 Admin 行为模板诞生，此后却拥有自己的生命周期。配置变了，不等于已经运行的对象立刻回滚。

于是，“配置过”“发出请求”“agent 接受”“双方协商”“会话活跃”成了五种不同陈述。删除 Admin 行，只能证明管理表不再呈现那份模板；它不能证明活动会话已断开。反过来，Oper 行仍在，也不能证明原来的配置仍被批准用于下一次建立会话。

RFC 2051 涵盖全局、逻辑单元、事务程序、session、conversation 和 CPI-C 等组，看上去像一套完整的 APPC 遥控器。但规范特意划窄了边界：它通常不能创建或删除 partner LU、mode、事务程序或 CPI-C 条目，也不负责激活 LU、启动 conversation 或激活 session。

可写控制对象确实存在，却只覆盖特定动作，例如开启或关闭统计与 tracing、发出 CNOS 命令、请求停用 session。一个写操作首先证明“请求被提交”，不证明“结果已经发生”。

CNOS 尤其适合观察这条断层。Admin 对象表示期望的会话数量，Oper 对象表示协商后实际得到的值。IBM 关于启动会话的当前说明 把 CNOS 展开为 Change Number Of Sessions，并说明按 mode 协商允许数和激活数。它只为术语提供背景，不能证明某台系统实现了 RFC 2051，更不能证明某次协商成功。

活动 session 表还有自己的时钟。状态包括 unbound、pendingBind、bound 和 pendingUnbind，agent 按规范所列条件创建或移除表行。对一个已 bound 的 session 写入 unbound 可以启动停用动作；但这次写入是控制请求，后续 Oper 状态才是 agent 是否推进的证据。

即使 bound 也只说明 session 的状态。它不说明 conversation 已分配，不说明事务程序完成，不说明对端返回了正确数据，更不说明业务目标达成。对端状态与应用结果仍需要各自的证据。

conversation 的生命更短。conversation 开始时 agent 创建活动行，结束时移除。它依附于 session，却不等同于 session。一个 session 可以先后承载多次 conversation，自己的生命周期跨越这些单次交互。

统计又是另一层，而且是可选层。启用采集后，agent 才会为每个活动 session 创建统计行。计数器采用 RFC 1902 定义的 Counter32，并配有 appcSessStatsCtrUpTime 说明计数周期。脱离周期、回绕和采集开关去读一个数字，不能得到完整历史。

规范还写明：把统计采集的 Admin 状态设为 inactive，会移除 session 统计表的全部行。它没有说活动 session 会一并终止。因此，“统计表为空”可能只表示采集被关掉，而不是运行已经停止。

历史表同样有选择性。session 历史只保留异常终止，conversation 历史只保留以错误结束的交互；保留多少行、保存多久由实现决定。空历史既不能证明没有正常活动，也不能证明过去所有异常仍可查到。

RFC 1666 提供了相邻的 SNA 管理模型背景。它能解释 APPC MIB 所在的规范谱系，却不能把对象定义变成部署事实。一份标准可以精确说明表与状态，而完全不证明运营者是否安装、启用、保护或正确解释了它们。

正式状态也必须按证据写。IETF Datatracker 与 RFC Editor 信息页 都显示：RFC 2051 于 1996 年 10 月发布，属于 Standards Track 的 Proposed Standard。冻结的 RFC 状态变更索引 没有列出它，官方记录也没有标明更新或废止它的 RFC。它很旧，所述技术也具有遗产性质，但现有官方证据不支持把其正式状态写成 Historic。

RFC Editor 勘误查询 返回没有匹配项。这只能缩小文档勘误这一类不确定性，不能为实现、互通、完整性或现实适用性背书。

安全边界更直接：RFC 2051 明说没有讨论安全问题。Standards Track 身份不能被转换成访问控制、管理写入安全或计数可信的证明。一个 session 可以处于运行态而并不安全；一个管理对象存在，也不说明谁有权改变底层系统。

正确的读法，是把每张表当成权限有限的证人。Admin 说明所呈现的配置；可写控制说明所请求的动作；agent 的状态变化说明接受与执行；CNOS Oper 值说明协商结果；session 行说明运行关系；conversation 行说明一次应用交互；统计说明采集期间的计量；历史说明被保留的异常结束。对端与应用仍需自行作证。

这也是那行“消失的配置”今天仍值得读的原因。配置容易被误当成权威，运行状态容易被误当成合规。RFC 2051 用生命周期拆掉了这两个捷径：session 可以比创建它的模板活得更久，运行事实也可以比统计它的证据活得更久。

来源