registration OIDs: do the values matter?

[Andy Bierman <abierman@cisco.com>]

Hi,

Attached is the list of OID assignments used by the RMON MIBs.
It's not nearly as orderly as it could be.  The question I'm
asking this group is should it be?  SHOULD (not MUST) all of 
OID assignments within a module be children of the MODULE-IDENTITY?
I actually don't know if it helps application developers or
not.  I think it would help management of the { rmon } number
space.

thanks,
Andy
  document      descriptor     assign type    value
=======================================================
rfc2819.txt:  rmonEventsV2 (notif. root)    { rmon 0 }
rfc2819.txt:  statistics            OID     { rmon 1 }
rfc2819.txt:  history               OID     { rmon 2 }
rfc2819.txt:  alarm                 OID     { rmon 3 }
rfc2819.txt:  hosts                 OID     { rmon 4 }
rfc2819.txt:  hostTopN              OID     { rmon 5 }
rfc2819.txt:  matrix                OID     { rmon 6 }
rfc2819.txt:  filter                OID     { rmon 7 }
rfc2819.txt:  capture               OID     { rmon 8 }
rfc2819.txt:  event                 OID     { rmon 9 }
rfc1513.txt:  tokenRing             OID     { rmon 10 }
rfc2021.txt:  protocolDir           OID     { rmon 11 }
rfc2021.txt:  protocolDist          OID     { rmon 12 }
rfc2021.txt:  addressMap            OID     { rmon 13 }
rfc2021.txt:  nlHost                OID     { rmon 14 }
rfc2021.txt:  nlMatrix              OID     { rmon 15 }
rfc2021.txt:  alHost                OID     { rmon 16 }
rfc2021.txt:  alMatrix              OID     { rmon 17 }
rfc2021.txt:  usrHistory            OID     { rmon 18 }
rfc2021.txt:  probeConfig           OID     { rmon 19 }
rfc2021.txt:  rmonConformance       OID     { rmon 20 }
rfc3273.txt:  mediaIndependentStats OID     { rmon 21 }
rfc2613.txt:  switchRMON            M-I     { rmon 22 }
APM-MIB:      apm                   M-I     { rmon 23 }
??? (not used)                              { rmon 24 }
PMCAPS:       pmCapsMIB             M-I     { rmon 25 } (defunct)
rfc3287.txt:  dsmonMIB              M-I     { rmon 26 }
rfc3144.txt:  interfaceTopNMIB      M-I     { rmon 27 }
??? (should be sspmMIB M-I)                 { rmon 28 }
rfc3434.txt:  hcAlarmMIB            M-I     { rmon 29 }
TPM-MIB:      tpmMIB                M-I     { rmon 30 }
SSPM-MIB:     sspmMIB               M-I     { mib-2 777 }
RAQMON-MIB:   raqmon                M-I     { mib-2 6889 }

rfc2021.txt:  rmon2MIBCompliances   OID     { rmonConformance 1 }
rfc2021.txt:  rmon2MIBGroups        OID     { rmonConformance 2 }
rfc2613.txt:  smonMIBCompliances    OID     { rmonConformance 3 }
rfc2613.txt:  smonMIBGroups         OID     { rmonConformance 4 }
rfc3273.txt:  hcRMON                M-I     { rmonConformance 5 }
rfc3273.txt:  hcRmonMIBCompliances  OID     { rmonConformance 6 }
rfc3273.txt:  hcRmonMIBGroups       OID     { rmonConformance 7 }
rfc2819.txt:  rmonMibModule         M-I     { rmonConformance 8 }
rfc2819.txt:  rmonCompliances       OID     { rmonConformance 9 }
rfc2819.txt:  rmonGroups            OID     { rmonConformance 10 }
APM-MIB:      apmCompliances        OID     { rmonConformance 11 }
APM-MIB:      apmGroups             OID     { rmonConformance 12 }

------------------------------------------------------------------

Comments:

1) The RMON numbering conventions (if any) are not consistent.
   Sometimes a MODULE-IDENTITY is defined as { rmon x } and
   other times as { rmonConformance x }. Sometimes conformace
   information is defined under the mib root for that module
   and other times it is under 'rmonConformance'. I think
   all M-Is should be { rmon x } and conformance OIDs for
   that module should be contained in that subtree.  This is the
   convention used by other MIBs under mib-2.

2) Some RMON modules contain duplicate assignments
   for rmonConformance instead of importing it.