摘要

  • RFC 1239 把五个 MIB 根节点从 1.3.6.1.3 下的实验编号，迁到标准的 mib-2 与 transmission 分支。
  • 这项调整针对真实的兼容性成本：晚期改号会迫使厂商修改实现，可能把问题带到现场，也会让厂商不愿在标准成熟前试做。
  • 新旧编号证明的是标准机构作出的映射决定；它们不能证明某台代理、管理器或历史数据库何时完成迁移。

两页文件写下了一个部署教训

RFC 1239 很短，主体只有一段政策说明和两张编号表。过去的做法是：MIB 在开发初期先进入实验命名空间，直到 Full Standard 才获得标准 MIB 编号。文件晋级时，厂商可能不得不修改实现，即便对象定义“很可能没有实质技术变化”。

问题出在 OID 不是注脚。RFC 1155 的 SMI 把对象标识符定义为对象类型的行政分配名称。管理器用它发问，代理用它定位对象，采集器把它写进存储，界面再给它套上易读标签。根节点一换，下面所有对象的数值地址都会跟着变化。

旧办法还扭曲了激励。厂商如果预见到以后一定要改号，可能索性等到 Full Standard 再实现；标准制定者却因此失去早期实现带来的反馈。RFC 1239 主张在标准化早期就分配标准分支，并在文件继续演进时保留该分配。

RFC Editor 记录和 Datatracker 记录今天把这份文件列为 Historic、Legacy。那是文件当前身份，不是任何一台设备采用新旧 OID 的证据。

五次迁址，各自留下两条观察线

RFC 1229 原来把通用接口扩展放在 1.3.6.1.3.6，RFC 1239 将其改为 1.3.6.1.2.1.12。也就是从 experimental 6 移到 mib-2 12。

另外四组进入 transmission。 RFC 1230 的 IEEE 802.4 Token Bus 从实验编号 7 改为 8；RFC 1231 的 Token Ring 从 4 改为 9；RFC 1232 的 DS1 从 2 改为 18；RFC 1233 的 DS3 从 15 改为 30。新根分别位于 1.3.6.1.2.1.10 之下。

这张表很精确，却不是迁移协议。RFC 1239 没有规定截止日期、别名、双栈响应期、能力协商、采集器转换步骤，也没有说明历史时序数据该如何拼接。标准文件确定了目的地；每套现场系统怎样抵达，仍取决于本地版本、配置和发布过程。

注册表可以确定权威，不能替设备作答

今天的 IANA SMI 注册表仍列出 GenericIF 12，以及 transmission 8、9、18、30。部分条目的现行引用已经换成后来的 RFC，因为对象定义在 1991 年后继续变化。当前注册表回答“现在什么编号具有权威”；RFC 1239 回答“当年发生了什么重新分配”。

两者都不能单独回答“这台代理当时返回了什么”。查询新 OID 失败，可能是旧软件、对象未实现、访问控制、代理失联或查询错误。旧 OID 返回成功，只能证明那个观察点确实收到响应，不能证明标准编号在其他地方没有部署。一个分支上的缺失，不等于另一个分支上的存在或缺失。

历史数据同样需要谨慎。采集器可以保持相同中文标签，却把底层数值键换掉，从而把一条时序线切成两段。它也可能把两段强行合并，掩盖同时发生的代理升级或语义变化。RFC 1239 没有证明这些事故曾经发生；它说明为什么迁移证据必须保存。

一份可核验的记录应包含确切 OID、代理与管理器版本、变更时间、请求与响应、访问上下文、存储键，以及合并或分离历史数据的规则。如果观察到新旧 OID 同时受支持，也要分别留存响应，不能从编号映射反推“双支持”。

稳定编号也不等于语义永远不变。后续标准完全可能沿用同一根节点，却调整状态、访问方式或解释。RFC 1239 要避免的是行政晋级造成的无谓改号；编号连续性和语义连续性，始终是两项证据命题。

来源