摘要

  • RFC 3737 将未来 RMON MIB 模块根的分配责任从工作组自管清单转交给 IANA，但没有移动既有 OID。
  • 它划定了窄边界：IANA 在 rmon 节点下分配 MODULE-IDENTITY 根；模块作者和编辑继续分配模块内部的普通对象标识符。

一份曾经运转、却出现过迟来纠错的清单

远程监控 MIB 累积在 MIB-II 树中的 rmon 节点下，路径为 1.3.6.1.2.1.16。RMONMIB 工作组此前自行维护新增模块的编号清单。RFC 3737 没把这种方式描述为失败：它说这套做法总体上运转得还可以。但过去有些错误要到流程后期才能纠正，也有少数分配后来不再使用。这种做法也不同于常见流程：标准轨 MIB 模块通常在 RFC 发布时获得根编号。

RFC 的表格把历史结构摊开来：较早编号对应 statistics、history、alarm、capture 等对象组；后续编号则包括 MODULE-IDENTITY 根、可用编号、保留编号和一个已废弃分配。这棵树并非整齐地按一种对象类型递增。RFC 3737 明确承认，部分早期安排不够合理，但历史不能重写。解决办法是更换未来决策的保管者，而不是给旧树重新编号。

IANA 取得的是根，不是整个模块

RFC 3737 将既有分配纳入 SMI Numbers 登记表，并请 IANA 维护。此后，IANA 只在 rmon 下分配 MODULE-IDENTITY 模块根。模块内部的普通 OID 仍由作者或编辑按通常的 MIB 程序安排。依照当时有效的 RFC 2434，新根需要经过 Standards Action；IANA 在 RFC 发布流程中分配编号。

这条边界很关键。模块根是共享命名空间中的接合点，两个模块可能在此冲突；根确定后，模块内部结构可由规范作者组织，无需让顶层 RMON 登记表逐个分配每个对象。这样，易发生冲突的边界由集中流程管理，模块内部仍留给具体规范设计。

后来的 IANA SMI Numbers 页面仍保留 rmon 树：一些条目的引用已指向 RFC 4502，同时还能看到可用编号、废弃模块项和保留分配。这只是带日期的登记记录，不能证明模块已实现或部署。根编号已登记、MIB 已实现、监控观测已产生，是三种不同凭据。RFC 3737 改变的是下一项根编号由谁登记；登记表里有条目，并不等于系统已有运行代码。

来源