RE: Where to root MIB modules

["Routhier, Shawn" <shawn.routhier@windriver.com>]

If we modify when we assign the OID we will also
need to be very clear as to the assignment is 
cast in concrete and can't be changed.  

As I understand it, that is currently when the RFC
is published.  If we want to allow for easier
earlier implementions we may need to add something
to drafts indicating if the OIDs can change or not.
This would allow an early verison of a draft to re-arrange
the objects, but a later version might not be able to.

sar
> -----Original Message-----
> From: Harrington, David [mailto:dbh@enterasys.com]
> Sent: Monday, January 05, 2004 10:50 AM
> To: C. M. Heard; Mreview (E-mail)
> Subject: RE: Where to root MIB modules
> 
> 
> Hi Mike,
> 
> > 
> 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.
> 
> > 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
> > 
> > 
> > 
>