摘要

  • RFC 1052 把 SNMP 选为互联网短期管理基础，也记下 Craig Partridge 为促成全网共识而建议 HEMS 退出；同一文件又把 HEMS 的 RFC 1024 列为公共 MIB 工作的输入。
  • 在退场决定之后发布的 RFC 1076，保存了 HEMS 的另一种执行思路：小型解释器一边接收 ASN.1 对象，一边沿层级数据树运行查询、筛选表项，并输出读取或修改后的表示状态。
  • 协议入选、语义复用、请求获准、代理返回数值和设备真正产生外部效果，是五层证据。任何一层都不能冒充整条链。

管理难题先从厂商数量上暴露出来

RFC 1021 描述的起点很朴素：当关键网关主要来自少数厂商时，经验丰富的管理员尚可记住各家的私有工具。随着网络规模和设备来源同时增加，人的记忆不再是一种可扩展的互操作机制。

HEMS，也就是 High-Level Entity Management System，试图把责任拆开。可寻址设备上放一个尽量小的查询处理器和事件生成器；管理中心的应用负责提出更聪明的问题、理解返回数据，必要时识别厂商扩展。复杂性没有消失，而是被放到更适合承受它的一端。

这套设计一开始就区分监测和控制。监测提取数据，用来观察网络怎样运行；控制试图实时改变行为。RFC 1021 特别强调，不能观察效果的控制没有意义。因此 HEMS 首先把监测做深，同时承认通用控制动作和强访问控制尚未完全定义。

到了 1988 年春天，问题不再只是哪个数据结构更漂亮。RFC 1052 记录了 IAB 对 HEMS、SNMP 和 CMIP/CMIS 三路工作的评审。IAB 建议短期采用 SNMP，理由带有强烈的运营色彩：软件已经可用且正在运行，互联网需要尽快收敛到公共方案。

这份文件还记下一个决定共识能否形成的动作。Craig Partridge 建议 HEMS 退出候选，以便全互联网达成协议。退场并未让 HEMS 的全部成果作废。紧接着，RFC 1052 称 HEMS 对监测元素的整理周全且经过广泛讨论，并要求 MIB 工作组把 RFC 1024 与 SNMP、CMIP/CMIS 材料一起作为起点。

协议竞争结束了一条路，信息定义却继续参与下一场讨论。

退场七个月后，查询语言仍被完整写下

RFC 1076 发布于 1988 年 11 月，并取代 RFC 1023。它没有推翻 4 月的选择，也没有宣称 HEMS 重新成为互联网公共协议。它做的是把实验性 HEMS 查询语言讲清楚。

一次查询不是单独的远程过程调用，而是一串 ASN.1 对象。普通数据对象到达就压入有限深度的栈，操作码到达便立即执行。处理器甚至可以在后半段请求尚未收完时，开始发送前半段结果。

这是一项面向关键网关的取舍。代理不必缓存整份请求，也不必为多个小问题反复往返；但流式输出意味着，后面的错误发生时，前面的结果可能已经上网。响应因此是一份按执行顺序形成的记录，而不是同一瞬间冻结的万能快照。

解释器只有八种动作：BEGIN、END、GET、GET-ATTRIBUTES、GET-RANGE、SET、CREATE 和 DELETE。它不保存程序，没有子程序，也没有通用控制流。表达能力来自路径、模板、数值和筛选器与这八种动作的组合。

被管理的信息呈现为一棵树。内部字典组织子树，从根到节点的路径就是名字，叶子携带实际数值。解释器访问一段树结构时，响应会把这段结构连同完整上下文一起复制出来。小小的 ASN.1 标签只有在所属字典中才有含义，所以返回值必须保留它的路径外壳。

与其记住第三项，不如说明为什么它是目标

接口表、路由表和 TCP 连接表都会变化。重启前排在第三的接口，重启后未必仍在第三。RFC 1076 没有把通用位置编号当作稳定身份，而是允许筛选器检查表项内部的值。

筛选器可判断字段是否存在，比较相等、上界或下界，并用 AND、OR、NOT 组合。一条查询可以找到持有某个 IP 地址的接口，只取它的计数；也可以进入该接口的 ARP 表，再寻找一个地址；还可以让 SET 作用于所有满足条件的表项。

规范没有掩饰筛选的歧义。如果带筛选器的 BEGIN 找到多个字典，处理器可以任选一个。RFC 1076 直说，还要靠实践决定多重匹配是否应当报错。因此，“查询合法”不能证明“目标唯一”；写操作前仍要验证筛选条件的排他性。

GET-RANGE 可读取 OctetString 的一段，甚至访问依赖机器架构的内存表示。但对整个字典做 GET 时，内存默认不会被带回。数据树可浏览，并不等于广义发现请求获准取走一切昂贵或敏感内容。

返回树值以后，机器还可能处在另一层状态

SET 和 CREATE 会返回操作后的相关树片段；DELETE 正常情况下不返回数据，未能删除的匹配项则可能出现在响应里。尝试修改只读字段也不一定生成错误，代理可以返回它原来的值，让调用方自行比较请求与结果。

对于现实控制，RFC 1076 提出“虚拟命令与状态寄存器”。向某个树节点写入命令码，可以触发实现自定的副作用，例如让接口下线；再读取该节点，可能得到当前状态。

这里的“可能”必须保留。响应中出现请求值，能证明 HEMS 管理接口在处理后怎样表示该节点，却不能独立证明物理载波已断、路由已收敛、邻居已察觉、状态会跨重启保留，或数据包已改走备用路径。控制面回执与运营结果分别需要证据。

这个界限并不过时。现代 API 也会准确地告诉调用者“请求已接受”，而底层动作仍在排队、部分完成、随后被覆盖，或只能从另一套遥测中验证。RFC 1076 把这种差异直接写进了返回模型。

一个空值故意容纳了三种原因

RFC 1022 定义 HEMP 外壳，承载请求、响应、事件和错误，并为认证、加密、回复加密预留位置。但存在字段不等于某条消息实际受到保护；1987 年文本甚至尚未分配加密类型。

RFC 1076 也不指定具体授权系统。查询从 HEMS 环境获得等级或能力，每个数据项再做本地检查。授权可限制 GET、SET、CREATE、DELETE，却不能通过隐藏字典让 BEGIN 失败，否则一个无权读取的分支会终止整个复合查询。

这种安排产生一个有意的模糊：标签不存在、可选字段未实现、调用者无权读取，都会得到同样的零长度空对象。好处是通用查询可穿过不同设备，不会遇到每个缺项都中止；代价是单凭响应无法判断沉默原因。

真正终止处理的错误则带有错误码、实现实例、请求字节偏移、正在执行的操作和说明。如果响应已经打开多层 ASN.1 对象，处理器会在每个未闭合层级写入一份错误，最后再写一次。这样已流出的结构仍可解析，但它不会自动回滚此前已经发生的读取或副作用。

入选方案更简单，继承关系却不能随意补画

到 1989 年 8 月，RFC 1109 已记录 SNMP 在多个网络运行，厂商和公共参考实现都已出现。报告同时指出，规模化性能监测、配置管理、用户访问控制和命令认证仍是未完工作。公共选择解决了紧迫协调，并没有结束管理工程。

后来的 RFC 1155 描述标准化 SMI：层级 OBJECT IDENTIFIER、受限 ASN.1 类型和虚拟信息库。RFC 1157 则用更小的 Get、GetNext、Set、Trap 操作面定义 SNMP，并记录其推荐运营地位。

这些相似元素不能自动组成一条从 HEMS 到每个 OID 的直线。RFC 1052 能证明的是：RFC 1024 被正式列为 MIB 工作输入。它没有给出逐字段复制表，也没有说 RFC 1076 与 SNMP 在线路上兼容。架构相似是背景，明确交接才是证据。

互联网当时做出的制度设计因而比“赢家淘汰输家”更成熟。一个协议候选可以退出，让公共部署尽快形成；已经完成的语义工作可以带着来源进入新流程；落选方案的完整说明仍可保留，供后来者理解没有选择的代价与边界。

来源与证明限度

RFC 1021 说明系统范围，RFC 1022 说明消息外壳，RFC 1024 提供被点名的对象定义，RFC 1052 记录选择与退出，RFC 1076 说明查询语言，RFC 1109 记录运营后续，RFC 1155 说明后来 SMI，RFC 1157 说明后来 SNMP。它们不提供 HEMS 部署数量、RFC 1076 生产抓包、逐对象迁移图或某次设备动作的现场结果。

可靠结论只有三层：HEMS 没有成为公共管理协议；它的信息工作没有随之被抹掉；它返回的表示状态也没有替运营结果完成证明。