OID MIB rooting of draft-ietf-ipcdn-qos-mib-10.txt and other pending IPCDN DOCSIS mib modules

"Jean-Francois Mule" <[email protected]>
Newsgroups gmane.ietf.ipcdn
Message-ID <[email protected]>
All,

   As you know, the authors of the ipcdn docsis qos mib are close to
finalizing the draft. In the final IETF reviews of the QoS MIB
(http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-10.txt),
it was requested that we consider changing the OID root assignment from
..mib-2(1) transmission(10) docsIfMib(127) to just ..mib-2(1). The
alternative is that we document the motivations and rationale for
continuing to assign MIBs under ..mib-2(1) transmission(10)
docsIfMib(127)) - I am willing to do this if the wg feels strongly about
it.

   After some considerations, Eduardo and I do not see any real
implications of this proposed change.  Out of all the internet-drafts on
our charter, if we do not count the RFI MIB v2 which updates rfc2670,
the QoS MIB is the only one in this case, the others do currently
request OID assignment under ..mib-2(1). 2 OID assignments have already
been made for the bis version of rfc2669 and rfc2670:
   - Cable device mib v2 ::= { mib-2 69 }
   - RF MIB v2    ::= { transmission 127 }
The other IPCDN DOCSIS IDs in the queue to become RFC are:
   - Bpi+ (the IETF ID already asks for OID ::= { mib-2 yy } 
   - Event notif ::= { mib-2 xxx }
   - QoS MIB (subject of this discussion)
   - subs mgmt (already approved for IETF publicaiton ::= { mib-2 xx } )

   Therefore, I would like to ping the list to see if anyone has any
objection to changing the OID MIB root of the QoS MIB to ..mib-2(1) from
..mib-2(1) transmission(10) docsIfMib(127). Unless we receive any
objections, the ID will be updated for Bert to put it on the IESG
agenda.

Thanks, 
Jean-Francois
IPCDN co-chair.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.