RE: Where to root MIB modules

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

> At 12:17 PM 1/5/2004, C. M. Heard wrote:
> >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.
> 
> The job of assigning MIB root OIDs should be done by IANA
> so it is done consistently for all standard MIB modules.
> (When Bert asked me, I gladly gave up the task of OID
> assignment/publication to IANA.)
> 
The RMOB MIB had made erors in the (even reasonably recent) past.
RFC-Editor has not made any MIB OID assignment errors since I came
on board as AD (if I remember correctly).

Doing MIB OID assignment within rmon tree in RMONMIB WG was kind
of acceptable. But only as long as I see that knowledgable and
involved people are present. At some time, the RMONMIB WG may get
closed, and then it needs to move to IANA anyway. Possiblt at
some earlier time, new (less experienced) people might take
over RMONMIB WG and what happens then.
I also do nto want a precendent so that other (inexperienced MIB)
people can claim that they should also be allowed to assign OIDs
under their own branch. I have seen too many bad examples of what
can happen. 

Bert
> Andy
> 
> 
> 
> >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
> 
>