Summary

  • RFC 3737 transferred responsibility for future RMON MIB module-root assignments from a working-group-maintained list to IANA, but left existing OIDs in place.
  • It drew a narrow boundary: IANA assigns a module’s MODULE-IDENTITY root beneath rmon; module authors and editors assign the ordinary object identifiers inside that module.

A registry that worked, until the late corrections

Remote Monitoring MIBs had accumulated beneath the rmon node in the MIB-II tree, 1.3.6.1.2.1.16. The RMONMIB Working Group had maintained its own list of new module assignments. RFC 3737 did not describe that arrangement as a failure: it says it had worked reasonably well. But errors had needed correction late in the process, and a few assignments had become defunct. The practice also differed from the usual path in which a standards-track MIB module receives its root as the RFC is published.

The RFC’s table makes the inherited structure visible. Early entries name object groups such as statistics, history, alarm and capture; later numbers identify MODULE-IDENTITY roots, available space, reserved values and a defunct assignment. The tree was not a clean sequence of one kind of object. RFC 3737 says plainly that some early choices are not logical and cannot be changed. Its solution was a change in custody for future decisions, not a renumbering project.

IANA receives the root, not the whole module

RFC 3737 moved the existing assignment record into the SMI Numbers registry and asked IANA to maintain it. Going forward, IANA assigns only MODULE-IDENTITY roots under rmon. Inside a module, its authors or editors continue to assign the ordinary OIDs according to the normal MIB procedures. New roots required Standards Action under the then-current RFC 2434; IANA assigned the number during RFC publication.

That boundary matters. A root is a shared namespace point where two modules could collide. Once a module has its own root, its internal structure can be organized within that module without asking the top-level RMON registry to allocate each object. RFC 3737 centralizes the collision-sensitive boundary while leaving module design local to the specification.

The later IANA SMI Numbers page still shows the rmon tree, including entries whose references now point to RFC 4502, an available value, a defunct module entry and reserved assignments. That is a dated registry record, not evidence that a particular module is implemented or deployed. A listed root, an implemented MIB and an actual monitoring observation are different receipts. RFC 3737 changed who records the next root; it did not turn registry presence into proof of running code.

Sources