摘要

  • RFC 2366 把 marsMIB 放在 { snmpModules 17 } 之下。两个月后发布的 RFC 2417 指出这是登记编号的文书错误，并将它改为 { mib-2 57 }。
  • 展开这两条符号路径，得到不同的数字根：1.3.6.1.6.3.17 与 1.3.6.1.2.1.57。定义在 MIB 之下的对象也会继承新的数值前缀。
  • 这套 MIB 描述 MARS 客户端、服务器和多播服务器的管理对象。名称改变本身并不意味着代理、管理站、组成员关系、虚电路或分组转发发生了变化。

改正一条分支，后代名称随之移动

对象标识符（OID）是一条层级路径，不是贴在固定数字上的标签。每个弧段都以父节点为基准命名一个子节点。1998 年 7 月，RFC 2366 将 MARS 管理模块定义为 marsMIB ::= { snmpModules 17 }。同年 9 月，RFC 2417 取代了该备忘录。它给 IANA 的说明称早先分配属于文书错误；修订说明要求把这套 MIB 从 snmpModules 重新置于 mib-2 之下，模块标识于是成为 marsMIB ::= { mib-2 57 }。

展开路径，便能看出修正的范围。RFC 1902 将 snmpModules 置于 snmpV2 下，而后者又位于 internet 之下；MIB-II（RFC 1213） 则把 mib-2 放在 mgmt 与 internet 之下。旧根因此是 1.3.6.1.6.3.17，新根是 1.3.6.1.2.1.57。模块的后代对象相对于 marsMIB 定义，所以它们的数字路径也会带上新的前缀。

这是管理命名空间中的真实身份变化，却不等于 MARS 的运行方式发生变化。RFC 2022 描述了 MARS 如何让 ATM 网络端点登记或查询多播组成员关系，再通过虚电路网状结构或多播服务器分发流量。RFC 2417 的表项则提供客户端、服务器、组、映射、虚电路、状态、计时器和统计信息的管理视图。它们描述代理可以报告什么，不负责执行成员关系分发，也不证明分组实际走过哪条电路。

这一区分很重要，因为“ MIB 变了”可能指多个层次：标准文档、符号 OID、代理编译进程序的数字名称、管理站轮询的对象，以及运营人员观察到的网络行为。RFC 2417 能证明前两个层次。它没有点名任何厂商或已升级代理，没有记录管理系统转换、兼容桥接、故障或全网迁移。后继 RFC 确认标准记录采用哪一种分配，却没有说明运行中的设备多快跟上。

当前的 IANA SMI Numbers 登记表 将 mib-2 的 57 号弧登记为 marsMIB，引用 RFC 2417，并把旧 snmpModules 的 17 号条目标为废弃。这是今天登记状态的有用凭据，不是对历史部署情况的追溯普查。RFC 2417 还说明，该模块与 RFC 1695 的 ATM-MIB、RFC 1213 的 MIB-II，以及可选的 RFC 1573 IF-MIB 配合使用；这是管理模型之间的依赖，并不能证明某个特定代理导出了它们。

证据边界就是这段历史

很容易想象运营人员看到所有 MARS 对象从一条分支消失、再在另一条分支出现。但这些文档没有记录这样的过程。若管理站仍按旧数字子树配置，或许需要更新查询视图；若代理按修正后的子树编译，或许会对相同查询给出不同响应。这些是命名变化可能带来的后果，并非文献记载的历史事件。系统是否同时接受新旧名称、是否改过配置、轮询是否失败，都需要这里没有提供的实现或运维证据。

Heng Lu 关于运行代码优先与现实层次的论述提供了一个分析视角：符号分配、具体实现、管理站的解释和观察到的服务是不同主张。这个视角本身不是 1998 年部署情况的证据。

因此，更可靠的教训不是讲一个无从证实的迁移故事：登记修正可能改变管理软件查找信息时使用的身份，并带动每个后代名称一起改变；但被观察的网络行为仍是另一个问题。移动的是文档树。RFC 并没有说 MARS 本身也移动了。

来源