RE: Where to root MIB modules

["Harrington, David" <dbh@enterasys.com>]

Hi Mike,

Part 1: the rmon experience

I reviewed the document you mentioned. It discusses turning over the
authority for rmon assignment to IANA, and how to handle existing
assignments. It doesn't discuss at length any problems of
interoperability that were caused by the earlier approach, except that
sometimes people made mistakes and reused assignments, and some
assignments ended up being obsolete. IANA has made a few mistakes as
well, and some asssignments become obsolete, so I didn't see using IANA
as a better solution, merely a different solution. I agree that since
IANA's job is to assign numbers, it seems beneficial to coordinate the
assignments through IANA, but the WG could add text to a document that
when approved as an RFC, IANA should add the assignments to the existing
list, as is done in this rmon-oids document, as has been proposed for
RADIUS attribute IDs, and many other working-group-maintained but
IANA-blessed assignments.

Part 2: the problem with IANA assignments at RFC time

There have been IETF discussions in the past about documents that were
"good enough" versus documents that were "perfect".

I have concerns that not assigning an OID until a mib is published as an
RFC is sub-optimal for reality. In an era when time-to-market is a
constant vendor concern, and the 24 months it takes to approve Proposed
Standard documents has been identified as an IETF problem to be
addressed, forcing this additional delay in the availability of a mib
via the IANA assignment of OIDs at RFC time seems counterproductive. 

The IETF and other SDOs, such as IEEE, produce working drafts of
protocols which are commonly implemented in pre-standard implementations
and released as products. While there is often a period of potential
non-interoperability in pre-standard releases, the vendors and customers
seem to weather this well, and change to the ratified-standard as soon
as it is available. 

This cannot be done easily with IETF mibs because the OID assignment is
held off until the specification is published as an RFC. We wait for
"perfection" before assigning an OID. Vendors who want to release a
pre-standard implementation are forced to cut-and-paste the mib, and
change the descriptors and OID assignments. Once they have provided the
functionality in a proprietary mib and a corresponding application that
understands their proprietary OIDs, there is little motivation for
vendors to migrate to the IETF standard descriptors and OIDs to provide
the same functionality.

The operator community has complained that the availability of standard
mibs is way too slow, often coming years after the availability of the
protocol which the mib tries to make manageable. This is becoming more
apparent now that other SDO working groups, like IEEE 802.1 and 802.3
and 802.11, have adopted SNMP mibs as their management approach.

We have a way to improve the speed of availability of mibs - let the
assignment of OIDs happen while the mib is under development in
internet-drafts and before being published as an RFC. This will allow
vendors to release products with pre-standard implementations of the mib
that can be corrected when the mib is ratified, much as they do with the
managed protocols.

Waiting until the mib is published as an RFC to assign an OID causes an
**unnecessary** delay that is often not found in other industry
standards.

Part 3: OID assignments and the DHCP mib

The DHCP server mib uses a dhcp { mib-2 TBD } IANA assignment, and then
"pre-assigns" certain OIDs for anticipated mib module extensions within
that subtree such as { dhcp 2 } for a dhcp client mib and { dhcp 3 } for
a dhcpv4 relay, and { dhcp 4 } for a dhcpv6 server mib. [these are
commented out, but still exist in the document.]

Is this "pre-assignment" considered bad practice? As a mib doctor should
I ask that such pre-assignment comments be removed from the mib? Should
these extensions all be at the { mib-2 xxx } level?

dbh

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com] 
> Sent: Monday, January 05, 2004 10:30 AM
> To: Mreview (E-mail)
> Subject: RE: Where to root MIB modules
> 
> 
> On Mon, 5 Jan 2004, Harrington, David wrote:
> > I think allowing a wg to assign the oids for their mibs, in a
> > controlled manner, might be a good thing to consider.
> 
> The RMONMIB WG used to do exactly that, but recently turned over the
> job to IANA.  See draft-ietf-rmonmib-rmon-oid-assignments-01.txt.
> 
> //cmh
> 
> 
>