摘要

  • RFC 1442 要求每个信息模块只有一个 MODULE-IDENTITY，用来固定模块 OID、维护组织、联系信息、最后编辑时间与修订说明；它证明的是规范文件的来历。
  • 该 RFC 明说，这个宏在概念上于实现期间展开，而不是在运行期间展开。因此，最新模块文件不能证明某台设备包含哪些对象、允许谁访问，也不能证明实际行为符合定义。
  • RFC 1902 与 RFC 2578 延续并收紧了这套纪律：兼容修订沿用模块名，不兼容语义必须换描述符和 OID，废弃定义也不能删除或把 OID 分给新含义。

同一个屏幕上，放着两只不同的钟

设想一次故障排查。资产页显示，采集器今天刚从交换机读到计数器；旁边的 MIB 浏览器又显示，相关模块在某年完成了最新修订。后一个日期形式严谨，还来自标准化字段，于是很容易被当作设备版本：既然平台认识这次修订，设备大概也已经实现了它。

这里悄悄合并了两只钟。模块里的时间回答“这份定义最后何时被编辑”；采集时间回答“某个端点何时返回了这些字节”。它们之间没有自动传递关系。监控服务器可以装着新 MIB 去解释旧代理，厂商也可能导入新模块却只实现其中一部分；访问视图会遮住已经存在的对象，代理转发还可能让响应来自另一套代码。

RFC 1442 的价值，恰恰在于把第一只钟做得可靠。若把它拿去回答第二只钟的问题，就会把规范溯源误写成现场证明。

模块本身终于有了身份证

1993 年的 SMIv2 把定义分成三类。OBJECT-TYPE 说明管理对象，NOTIFICATION-TYPE 说明通知，MODULE-IDENTITY 则说明承载这些定义的信息模块。过去容易被当作文件外壳的模块，由此成为需要被明确识别和维护的对象。

每个模块必须在 imports 或 exports 之后出现且只出现一次 MODULE-IDENTITY。其中记录负责组织、联系地址、模块最后修改时间，以及按时间倒序排列的修订及其说明。模块因此能持续回答：谁对这片命名空间负责，当前文本从何而来，历次修改改变了什么。

这是互联网标准工程里很实际的一步。若没有稳定模块身份，溯源往往散落在文件名、邮件、实现者记忆与厂商包中。引入关系也容易因随意改名而断裂。有了身份和履历，工具可以辨认输入，审阅者可以追踪变化，后来的编辑者也不必为一次兼容性修正另造一座命名空间。

不过，“身份证”不是“在线心跳”。RFC 1442 特意指出，MODULE-IDENTITY 的展开从概念上发生在实现时，而非运行时。它长得像一组数据，也确实包含时间和 OID，但它不是要求代理开放查询的活对象。它约束的是模块怎样声明，而非设备必须怎样自证。

LAST-UPDATED 没有说固件刚升级

字段名最容易制造越权解释。LAST-UPDATED 不是设备最近升级时间，不是软件包安装时间，不是进程启动时间，也不是配置最后改变的时间。它只表示信息模块最后一次被编辑的时刻。

REVISION 同样如此。时间戳与描述组成一条模块修订记录。RFC 1442 要求新记录在前，但在当时仍允许模块不写修订项。它是一份人工维护的规范履历，不是一份由现场设备自动生成的部署日志。

运维系统常把四类时间压在同一个“版本”栏里：MIB 文件时间、厂商软件版本日期、采集器载入时间和设备响应时间。压缩之后，最晚的日期看上去最可信，实际却可能距离所问问题最远。新 MIB 只能说明解码器掌握了新语义；它不能倒推出被测代码也更新了。

可信证据应保留各自的主语。定义文件要有来源、散列和获取时间；固件要有包或供应商声明；在线响应要记录端点、身份、上下文、请求与原始结果；对象行为还要靠独立状态观察来核对。把它们连接起来可以形成证据链，把它们合成一个日期只会丢掉边界。

为什么修订时反而不应改模块名

稳定名称并不意味着文本永远不动。模块会纠错，会补充描述和参考，也会在兼容规则内增加定义。若每次修改都换模块名，其他模块的 imports 会不断断裂，工具和实现将被迫追逐没有必要的新身份。

RFC 1442 允许一组受约束的修改继续留在原名下，例如澄清描述、修正参考，以及在不破坏旧实现的方向上调整部分属性。模块名承担的是一条兼容谱系，而不是一份冻结快照。

真正的边界在语义。当改动超出允许范围，新定义就必须获得新的描述符和新的对象标识符。旧 OID 不能在原地换一种含义。因为其他模块会按描述符导入，现场协议又依赖 OID，这两层身份共同防止“看起来还是同一个对象，实际上契约已经被替换”。

这套安排体现出一种克制：允许演进，却要求把不兼容变化显式化。名字之所以能长期存在，不是因为变化被忽略，而是因为变化被分类、记账并限制。

被取代的 RFC 留下了没有过时的边界

1996 年，RFC 1902 取代 RFC 1442。它仍然把 SMI 分为模块、对象与通知三类定义，也继续要求唯一的模块身份，并保留“实现时而非运行时”的界线。文档编号退场，不等于设计判断失效。

1999 年，RFC 2578 又取代 RFC 1902，成为现行的 SMIv2 Internet Standard。它把修订纪律说得更明确：同一模块可以存在不同版本而保持模块名不变；修订不应制造线上互操作问题；模块一旦改变，就应在 MODULE-IDENTITY 中留下对应记录；定义也不应随意从一个模块搬到另一个模块。

尤其重要的是，obsolete 定义不能从模块里删除，其 OID 永远不能重新分配。被淘汰的语义仍占着原坐标，正是为了防止后来者借用旧地址欺骗旧软件。命名空间不仅保存当前事物，也保存不能再被重新解释的历史空位。

current、deprecated、obsolete 描述的是定义在规范中的状态，并非实现探针。一台旧设备可以继续暴露 obsolete 对象，新产品可能没有某个 current 对象，被 deprecated 的对象也可能因兼容需要而长期存在。标准建议与运行存在必须分别观察。

对设备提出主张，需要设备层证据

MODULE-IDENTITY 当然应该进入证据系统。它可以锚定模块 OID、维护者、联系信息和编辑履历；再配合文件散列，它还能证明采集器具体使用了哪份语法和文本约定。若一个原始值被显示成枚举名称或带单位数字，这份模式文件正是解释过程的一部分。

但它不能单独证明五件事：代理含有此模块；模块中的对象全部被测量；当前身份有权访问这些对象；实现遵循文字所写的行为；一次成功操作造成并保存了预期外部状态。

要回答这些问题，必须回到运行面。选择性探测能够区分对象不存在、实例不存在和访问被拒；一致性声明可以提供待验证的能力边界；安全主体、上下文与 view 决定可见范围；受控实验与设备外部观察用来检验语义；重启或切换后的再次观测才能谈持久性。

因此，一条严谨记录不应写成“设备 A 运行模块修订 B”，而应展开为：采集器 C 载入了散列确定的模式 B，在时间 T 以主体 P 和上下文 V 请求端点 E，对象 O 返回结果 R，独立观测 Q 是否支持预期效果。每个连接处都可以被验证，也可以诚实地标为未知。

这不是否定注册表，而是限定注册表

RFC 1442 所解决的问题是真问题：互联网管理定义必须在变化中保有身份。没有模块名、责任人和修订记忆，标准生态无法可靠复用。后续 RFC 对这套制度的延续，说明它经受住了文档更替。

危险来自另一种愿望：希望一份整理良好的记录自动创造现场现实。目录能告诉我们规范如何定义，构建记录能告诉我们实现使用了哪些输入，数据包能告诉我们接口上发生了什么，事后核验能告诉我们动作是否生效。它们彼此相关，却没有谁能替别人发言。

所以，固定的模块名牌值得保留。它让历史可查，让 imports 稳定，也让不兼容变化不得偷偷占用旧身份。唯一不该做的，是让这块名牌替玻璃后的机器宣誓。

来源