vdslMIB OID tree

OK, while review mcm and scm MIB documents, I see

- RFC3728 has:
    vdslMIB MODULE-IDENTITY
       ... snip ...
       ::= { transmission 97 }

    vdslLineMib    OBJECT IDENTIFIER ::= { vdslMIB 1 }

- mcm mib document has:
       ::= { vdslMIB XX }   -- To be assigned by IANA
    -- RFC Ed.: we suggest to put it under { vdslMIB 3 } because
    --          vdslMIB 1 is the VDSL-LINE-MIB, vdslMIB 2 is the SCM
    --          extension MIB, while vdslMIB 3 is this MCM extension MIB.

- scm mib document has:
       ::= { vdslMIB XX }   -- To be assigned by IANA
    -- RFC Ed.: we suggest to put it under { vdslMIB 2 } because
    --          vdslMIB 1 is the VDSL-LINE-MIB, vdslMIB 2 is this SCM
    --          extension MIB, while vdslMIB 3 is the MCM extension MIB.

So I have a few questions:

- the latest mib review guidelines (I know they were published
  at same time as your MIB document, so I understand you might not
  have seen this) as in draft-ietf-ops-mib-review-guidelines-03.txt
  state on page 13, sect 4.5, 3rd bullet:

   - The value assigned to the MODULE-IDENTITY descriptor MUST be unique
     and (for IETF standards-track MIB modules) SHOULD reside under the
     mgmt subtree [RFC2578].  Most often it will be an IANA-assigned
     value directly under mib-2 [RFC2578], although for media-specific
     MIB modules that extend the IF-MIB [RFC2863] it is customary to use
     an IANA-assigned value under transmission [RFC2578].  In the past
     some IETF working groups have made their own assignments from
     subtrees delegated to them by IANA, but that practice has proven
     problematic and is NOT RECOMMENDED.

  So your approach is certainly not recommended anymore.

- If you do want to stick to it, then I can see this as problematic for
  the IANA. How are they going to keep track of which values have been 
  assigned? And what are the rules for them to assign new branches
  underneath vdslMIB ??
  So if you do want to stick to this, we need to ask IANA to create the
  vdslMIB OID namespace and ask them to administer it. We then also need
  to document IANA instructions as to how/when new assignments can be 
  made (probably only as a "Standards Action" (one of the options
  described in RFC2434).

- The currently suggested assignments would end up in:

    OID tree
    1.3.6.1.2.1.10.97  vdslMIB  [VDSL-LINE-MIB]: module-identity
    1.3.6.1.2.1.10.97.1  vdslLineMib  [VDSL-LINE-MIB]: oid-value-assignment
    1.3.6.1.2.1.10.97.1.0  vdslNotifications  [VDSL-LINE-MIB]: oid-value-assignmentOID tree
    1.3.6.1.2.1.10.97.1.1  vdslMibObjects  [VDSL-LINE-MIB]: oid-value-assignment
    1.3.6.1.2.1.10.97.2  vdslExtSCMMIB  [VDSL-LINE-EXT-SCM-MIB]: module-identity
    1.3.6.1.2.1.10.97.2.1  vdslLineExtSCMMib  [VDSL-LINE-EXT-SCM-MIB]: oid-value-assignment
    1.3.6.1.2.1.10.97.2.1.1  vdslLineExtSCMMibObjects  [VDSL-LINE-EXT-SCM-MIB]: oid-value-assignment
    1.3.6.1.2.1.10.97.3  vdslExtMCMMIB  [VDSL-LINE-EXT-MCM-MIB]: module-identity
    1.3.6.1.2.1.10.97.3.1  vdslLineExtMCMMib  [VDSL-LINE-EXT-MCM-MIB]: oid-value-assignment
    1.3.6.1.2.1.10.97.3.1.1  vdslLineExtMCMMibObjects  [VDSL-LINE-EXT-MCM-MIB]: oid-value-assignment

  Do you see that such is also not logical!?

Bert