RE: Where to root MIB modules

["C. M. Heard" <heard@pobox.com>]

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

I will ask Bert and Andy to respond to these points.

dbh> Part 2: the problem with IANA assignments at RFC time
dbh> 
dbh> There have been IETF discussions in the past about documents
dbh> that were "good enough" versus documents that were "perfect".
dbh> 
dbh> I have concerns that not assigning an OID until a mib is
dbh> published as an RFC is sub-optimal for reality. In an era when
dbh> time-to-market is a constant vendor concern, and the 24 months
dbh> it takes to approve Proposed Standard documents has been
dbh> identified as an IETF problem to be addressed, forcing this
dbh> additional delay in the availability of a mib via the IANA
dbh> assignment of OIDs at RFC time seems counterproductive.
dbh> 
dbh> The IETF and other SDOs, such as IEEE, produce working drafts of
dbh> protocols which are commonly implemented in pre-standard
dbh> implementations and released as products. While there is often a
dbh> period of potential non-interoperability in pre-standard
dbh> releases, the vendors and customers seem to weather this well,
dbh> and change to the ratified-standard as soon as it is available.
dbh> 
dbh> This cannot be done easily with IETF mibs because the OID
dbh> assignment is held off until the specification is published as
dbh> an RFC. We wait for "perfection" before assigning an OID.
dbh> Vendors who want to release a pre-standard implementation are
dbh> forced to cut-and-paste the mib, and change the descriptors and
dbh> OID assignments. Once they have provided the functionality in a
dbh> proprietary mib and a corresponding application that understands
dbh> their proprietary OIDs, there is little motivation for vendors
dbh> to migrate to the IETF standard descriptors and OIDs to provide
dbh> the same functionality.
dbh> 
dbh> The operator community has complained that the availability of
dbh> standard mibs is way too slow, often coming years after the
dbh> availability of the protocol which the mib tries to make
dbh> manageable. This is becoming more apparent now that other SDO
dbh> working groups, like IEEE 802.1 and 802.3 and 802.11, have
dbh> adopted SNMP mibs as their management approach.
dbh> 
dbh> We have a way to improve the speed of availability of mibs - let
dbh> the assignment of OIDs happen while the mib is under development
dbh> in internet-drafts and before being published as an RFC. This
dbh> will allow vendors to release products with pre-standard
dbh> implementations of the mib that can be corrected when the mib is
dbh> ratified, much as they do with the managed protocols.
dbh> 
dbh> Waiting until the mib is published as an RFC to assign an OID
dbh> causes an **unnecessary** delay that is often not found in other
dbh> industry standards.

There already exists a mechanism to deal with this:  any WG can get
an OID assignment under the experimental subtree for the asking, and
according to what I read in RFC 2578, it is perfectly legal to use
such an assignment in an Internet-Draft in lieu of { mib-2 xxx } or
{ transmission xxx } or the like.  Once the final version is
approved, the whole MIB module can be re-rooted in the mgmt tree.  
Note that RFC 2578 does NOT require new descriptors, since only
"standard" MIB modules have a requirement to have unique
descriptors (RFC 2578, Section 3.1, next to last paragraph;
RFC 2578, Section 4, fifth and sixth paragraphs).

I know this mechanism is seldom used;  but would it not do what you
want?  And if not, why not?

>>>>> On Mon, 5 Jan 2004, Routhier, Shawn wrote:
sar> If we modify when we assign the OID we will also
sar> need to be very clear as to the assignment is 
sar> cast in concrete and can't be changed.  
sar> 
sar> As I understand it, that is currently when the RFC
sar> is published.  If we want to allow for easier
sar> earlier implementions we may need to add something
sar> to drafts indicating if the OIDs can change or not.
sar> This would allow an early verison of a draft to re-arrange
sar> the objects, but a later version might not be able to.

Rooting draft versions in the experimantal subtree, with the
understanding that the published version gets re-rooted in
the mgmt tree, would seem to accomplish the same thing.


dbh> Part 3: OID assignments and the DHCP mib
dbh> 
dbh> The DHCP server mib uses a dhcp { mib-2 TBD } IANA assignment,
dbh> and then "pre-assigns" certain OIDs for anticipated mib module
dbh> extensions within that subtree such as { dhcp 2 } for a dhcp
dbh> client mib and { dhcp 3 } for a dhcpv4 relay, and { dhcp 4 } for
dbh> a dhcpv6 server mib. [these are commented out, but still exist
dbh> in the document.]
dbh> 
dbh> Is this "pre-assignment" considered bad practice? As a mib
dbh> doctor should I ask that such pre-assignment comments be removed
dbh> from the mib? Should these extensions all be at the
dbh> { mib-2 xxx } level?

That is what I would do.

//cmh