IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules
Extracted elements (8)
Earlier OID assignments under rmon were not logically organized: initially normal MIB OIDs were assigned directly, but later the WG used the rmon root to create new MIB modules. The document acknowledges this cannot be changed but constrains all future assignments to MODULE-IDENTITY (MIB root) only.
Internet-draft authors needing a new rmon OID assignment should use the placeholder '{ rmon nnn }' with a comment requesting IANA assignment; the RFC Editor replaces nnn with the IANA-assigned number upon publication.
From the point of RFC 3737 publication onward, only MODULE-IDENTITY macro (MIB root) assignments will be made by IANA under the rmon node. Plain OID sub-assignments within a MIB module are handled by the working group authors.
New assignments under the rmon OID node can only be made via Standards Action as described in RFC 2434. IANA assigns the number as part of the RFC publication process.
The rmon OID subtree (1.3.6.1.2.1.16) contains 33 assigned or reserved entries (nnn 0–32), including notifications root, statistics, history, alarm, and various MIB module roots such as switchRMON, apm, dsmonMIB, hcAlarmMIB, and others.
The rmonConformance subtree (1.3.6.1.2.1.16.20) contains 10 assigned entries covering compliance and group OIDs for RMON2, SMON, hcRMON, and the base RMON MIB module.
IANA maintains the OID registry under the rmon root (1.3.6.1.2.1.16), integrated into the smi-numbers registry. The registry covers assignments 0–32 under rmon, including MODULE-IDENTITY (MIB root) and plain OID assignments.
This document describes procedures for IANA assignment of OBJECT IDENTIFIER values only and has no impact on the security of the Internet.