摘要

  • RFC 1095 明确记载：CMOT 与 SNMP 同为 IAB 指定的“Draft Standard”和“Recommended”。更早的 RFC 1052 虽把 SNMP 视为短期方案、CMIS/CMIP 视为长期方向，IAB 仍要求两条路线都接受实现与实验检验。
  • 两组共用约一百个强制 Internet MIB 变量，但共享对象目录不等于共享应用。CMOT 还要通过一份配置剖面，把 CMIS、CMIP、ACSE、ROSE、ASN.1 与轻量表示层准确映射到 TCP 或 UDP。
  • RFC 1095 只覆盖一个管理域，把管理应用留在范围之外，并把访问控制参数设为可选。关联建立与操作返回只能证明协议推进到哪一步，不能单独证明机构授权或设备实际效果。

那时，标准名单容得下两个答案

从结局倒看，网络管理史很容易被压成一句话：SNMP 普及，CMOT 没有。可 RFC 1095 的开头保留了一个尚未封口的时刻。IAB 给两种不同的协议完全相同的标准状态——“Draft Standard”与“Recommended”。具备网络管理能力的 IP/TCP 实现应至少采用其中一种，IAB 还向两边的实现者和使用者征求经验报告。

CMOT 是 “CMIP over TCP/IP”的缩写。它不是把 SNMP 换个编码，而是把 ISO 的 Common Management Information Services/Common Management Information Protocol 带入 TCP/IP 环境。另一边则是刚从实用需求中快速收敛的 SNMP。

同级标签不能被误读成同等部署。一年前的 RFC 1052 已给两条路线安排了不同时间尺度：SNMP 因已有软件运行，被推荐为短期基础；CMIS/CMIP 则承担长期开发、部署与试验任务，希望互联网用真实经验参与国际标准。

这是一种同时押注现实与方向的治理方式。高速增长的网络急需可用工具，标准制定者又不愿放弃更完整的国际管理框架。“Recommended”说明两者都值得实现与验证，不说明两者已有同样数量的产品、同样成熟的操作经验或同样确定的未来。

几个月后的 RFC 1109 正好展示了这种差异。它列出已在网络和产品中出现的 SNMP 实现；对 CMOT，则记载当次会议没有获报公开可用实现，但有厂商计划以及威斯康星大学拟以 ISODE 演示。RFC 1095 所述 Interop ’88 原型证明了可行性与多厂商潜力，却不是生产部署普查。

共用 MIB 是桥，不是整座系统

两条路线最重要的共同点不在传输线上，而在对象目录。RFC 1052 另设 MIB 工作组，并要求其成果同时供给 SNMP 与 Netman 工作组。RFC 1109 随后记下：双方约定了大约一百个公共子树变量，作为 Internet 网络管理的强制对象。

这样做的价值很直接。同一个 IP 计数器、路由条目或接口状态，不必因为查询协议不同就获得两套互不相干的名称与语义。共同 MIB 是语义桥梁，也承载了当时设想的“从短期 SNMP 平滑转向长期 CMIP”。

但双方都说“接口状态”，并不意味着双方以同样方式交谈。实例怎样选择、范围怎样过滤、事件怎样报告、关联怎样建立、错误怎样编码、请求怎样保护，都不是对象名称自己能回答的。两种协议即使读取同一个变量，也可能进入完全不同的操作工具与工作流。

RFC 1109 后来强调，决定管理系统效果的将是运营者真正拿到的工具，而不只是底层协议。它还指出，当时两种服务接口都没有“过去时”：不能直接查询历史信息，也不能表达“30 分钟后在设备 Y 执行 X”这样的指令。

所以 RFC 1095 才会写得如此庞大。共同 MIB 没有消灭配置剖面，反而让剖面必须更精确：怎样让这组 Internet 管理语义，通过一套被选定的 CMIS/CMIP 选项，在两个独立实现之间保真流动。

互操作藏在每一道接缝里

CMOT 不是 TCP 上方一个单独报头。实现者需要 ASN.1 描述抽象数据，需要 ACSE 建立与释放应用关联，需要 ROSE 承载远程操作，需要 CMIS 与 CMIP 定义管理服务及协议，还需要 Internet SMI/MIB 与 RFC 1085 的轻量表示服务。

RFC 1095 因而不是只讲理念。它要决定关联采用哪些功能单元，对象类与实例怎样映射，范围与过滤怎样处理，哪些 PDU 可以出现，以及 ACSE、ROSE、CMIP 数据如何经过轻量表示层序列化。

“轻量”解决的是实现负担。互联网设备可以使用 ISO 应用层协议，而不必连同完整的 ISO 表示层、会话层与传输层一起实现。RFC 1085 保留了表示服务的接口，再把它落到熟悉的 Internet 传输上。

但省去整套栈，不等于一句“支持 CMIP”就足够。互操作要知道应用上下文、功能单元、编码约定、传输映射和 MIB 版本。协议名称只标明一个家族，配置剖面才标明两台机器是否真的选择了相容的那条路径。

因此，剖面首先是一份边界文件。它从庞大选项空间中缩出一个较小交集，让多厂商实现有机会交换有意义的管理操作。它不替厂商证明实现正确，也不替管理应用证明好用，更不替机构证明有权。

TCP 与 UDP 没有承诺同一段旅程

RFC 1085 提供两种传输映射：TCP 对应所谓“高质量”服务，UDP 对应“低质量”服务。文中那句醒目的提醒——低质量就是低质量——是在阻止抽象层偷走事实。UDP 不会因为承载了表示层数据，便自动获得 TCP 的连接、顺序与恢复性质。

RFC 1095 接受这项分岔。轻量表示协议可以跑在 TCP 或 UDP 上，管理者使用 163 端口，代理使用 164 端口。UDP 模式把 CMOT PDU 限制在 484 字节，以便按当时假设装入未分片 IP 数据报。端点发现则可能依赖目录、本地表，甚至尝试建立关联。

所以“CMOT 端点”不是一个放之四海而皆准的坐标。运营者必须知道所用传输、地址、角色、剖面与发现依据。TCP 关联成功和 UDP 数据报抵达，能够证明的路径性质不同；两者都证明不了管理者背后那个人或机构拥有行动授权。

故障也要按层拆开。超时可能来自传输丢失、表示层不匹配、关联拒绝、不支持的 CMIS 功能、访问政策，或被管理对象本身。若统一记成“CMOT 失败”，剖面辛苦划出的因果边界便全部消失。

一个管理域，就是架构画出的圆

RFC 1095 介绍管理者与代理、被管理对象以及 OSI 管理的五个功能领域，却明确不规定实际管理应用怎样完成这些工作。标准追求的是多厂商互操作所需的最低共同架构；应用仍由市场竞争决定。

它也把管理域之间的关系与互动排除在范围之外。架构只覆盖单一管理域。这个限定比子网边界更深。

管理域是一种行政安排：哪些系统扮演管理者，哪些设备接受其操作，双方遵循什么政策，出了问题由谁负责。IP 包可以越过网络边界，机构权力却不能靠路由自动委托。CMOT 给出协议路径，没有凭空创造两个管理机构之间的合同。

因此，标准能说明一个管理者如何向代理请求操作，却不能替另一个组织回答“你是否有资格请求”。它能暴露对象，却不能决定谁承担改变对象的后果。跨域联合需要剖面之上的协议、政策和责任记录。

这也纠正了一种图示错觉。协议角色可以在不同系统上实现，操作格式可以保持一致；机构权力却仍然有方向、有范围、可撤销。技术上的对称并不会自动制造治理上的对等。

建立关联不等于获得授权

CMOT 通过 ACSE 建立应用关联。双方先协商应用上下文与功能单元，再交换管理操作。这一步是真实证据：它说明两个协议实现找到了共同语境。

可它不是任命书、委托书或所有权证明。RFC 1095 把关联级与请求级访问控制参数都设为可选。剖面建议在关联建立时处理访问控制，并期待未来的 TCP/IP 认证工作；接收者却可以忽略逐请求访问控制字段。文中允许的临时简单方法甚至可能只是一段未加密密码。

这些文字要留在 1989 年的能力边界中理解。它们说明作者知道“访问”和“认证”是独立问题，不说明每个符合剖面的关联都强认证了对端，更不说明密码字段已经构成完整授权政策。

RFC 1109 数月后把缺口写得更直接：用户访问控制，以及管理命令与响应的来源认证，都是 CMOT 与 SNMP 规范尚未解决的重要事项。一个剖面可以给访问数据留位置，却未必已经提供完整、部署到位的信任制度。

证据阶梯必须保持顺序：网络可达允许尝试；表示层与关联相容允许交谈；认证在某种方法下把消息归于安全主体；授权在政策中许可某项操作。后一级不能由前一级自动推出。

返回“成功”，还没有抵达机器的后果

CMIS 可以请求信息、修改属性、报告事件，其服务结构比简单取值丰富。但 RFC 1095 并没有许诺每项操作都成为物理世界里的事务。规范要求尽力同步，原子同步只是可选能力。

假设管理者获得已接受关联，并收到一次设置操作的成功响应。它最多证明：符合剖面的协议栈交付并处理了请求，代理按该操作的语义报告了结果。它不能独立证明板卡已经切换模式、流量已经改道、重启后仍保存设置，或用户获得预期服务。

那些结论需要后续观察：读取另一对象、接收事件、检查独立计数器、验证持久配置，或从被管理设备以外测量。当命令状态与确认值都来自同一代理，仍要记录它们共用证据源，不能把两次回答包装成独立佐证。

这不是对协议不信任，而是把功劳和责任放回正确层级。CMOT 规定消息与语义；设备仪表化把语义映射成动作；硬件与网络条件产生最终效果。每层都可能成功，而下一层失败。

RFC 1189 更新了剖面，没有抹平边界

1990 年 10 月，RFC 1189 取代 RFC 1095。CMIS 与 CMIP 已从草案走向最终国际标准。新版删去教程，把 Internet MIB 语义移到独立文件，采用更新后的实现者协议，并修改关联协商，同时保留对早期应用上下文名的识别。

这段修订史正说明剖面为何存在。基础标准发生变化时，Internet 协议必须写清采用哪个版本、哪些选项、哪些上下文还能互通。单独一个协议名称无法携带这些状态。

它也保留了更窄、更耐久的结论。1989 年的互联网可以推荐两种管理协议，让它们共用一套 MIB，却不假装两者已经成为同一个系统。剖面把语法与传输连接到足以尝试互操作；管理域、授权政策、运营应用与设备效果仍在连接之外或之后。

后来哪种协议更常见，并不会让这层架构失去价值。RFC 1095 保存了胜者叙事最容易压掉的四件事：给同一对象命名、把同一语义运过去、有权改变它、证明它真的改变，是四项不同成就。

来源