RE: Where to root MIB modules

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

Hi Dave,

Comments inline.

> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> Sent: Monday, January 05, 2004 2:25 PM
> To: mreview@ops.ietf.org
> Subject: RE: Where to root MIB modules
> 
> 
> HI,
> 
> Your message below is a good summary of the situation.
> 
> It leads to two questions, which are:
> 1) Is the trend for errors in assigments by IANA getting
>    better, worse, or staying the same. Or another way,
>    has IANA made any mistakes in the last couple of years
>    and do they have a process in place to "eliminate"
>    mistakes? 

A related question is: Is the trend for errors in assignments by the
rmon wg getting better, worse, or staying the same? Has rmon made any
mistakes in the last couple of years and do they have a process in place
to eliminate mistakes?

> 
> 2) Why is there is need for changing MIB descriptors?
>    (My answer - inadequate tools!)
>    Changing OIDs and descriptors is an error prone
>    process and can result in management apps (and possibly
>    agents) supporting 2 (or more) copies of object,
>    notificaton, and TC definitions.
>    What if there was a programmatic way to rename
>    descriptors. For example, to prefix each lowercase
>    descriptor with xn and uppercase descriptor with Xn.
>    For example, descriptor "myObject" would be renamed
>    to "x1myObject" in prerelease 1 of the MIB module.
> 
>    In summary - work out some scenarios to see the
>    consequence of each policy.

I'm not sure I understand the conceptual level of your question. 

If a vendor decides to implement a prerelease version of an IETF mib,
and assigns enterpise OIDs to the objects, it is necessary to change the
descriptors to differentiate  the names of their proprietary objects
from names of the standards-track objects.

The Xn-prefix proposal would likely be problematic if X1foo and X2foo
and Xfinalfoo have  identical semantics and OID assignments. A similar
problem arose when IETF mibs were named by their RFC#s.

> 
> An observation - there are forces that cause actions.
> For IEEE and IETF technical specifications, users are
> concerned about interoperability between products
> from different vendors. Also, product reviews and
> formal test groups focus on interoperability. In
> general, if there is no interoperability the
> "system will not work". 

I agree. And that is what drives vendors to migrate to the standard. I
think this is demonstrated time after time in most IEEE standards and
most non-mib IETF standards. 

However, there is a tradeoff in costs, and if the costs of migrating
from a proprietary implementation to the standard is too high, then the
migration doesn't happen, and the operators lose. 

> There is no work around
> in using a feature/capability where there is
> no interoperability other than a single vendor
> solution. However, for management, the current
> state is that proprietary solutions are needed for
> configuration (with a few exceptions), and for
> monitoring, it is accepted that an "adapter layer"
> will be used to modify retrieved data so that
> it fits the model used by the management station.
> So, bottom line is that I don't see the pressures
> to force the implemenation of management interfaces
> (MIB definitions) to move from a pre-release to
> a final version of a technical specification,
> as long as the pre-release specification
> is good enough.

I agree that the adapter layer can reduce the pressure to standardize,
but the cost of migrating to the standard in subsequent product releases
is greatly reduced if the pre-standard and standard are already very
close.

I have concerns that the same situation will arise in XMLCONF, where a
"standard" xml schema for some functionality will be years behind the
functionality as we wait for an official blessing of the schema being
added to an IETF XML namespace. That's a problem I don't see going away
unless we consider allowing for useable pre-release specs, or publish
specs that are only "good enough" as RFCs. 

dbh
> 
> Regards,
> /david t. perkins
> 
> On Mon, 5 Jan 2004, Harrington, David wrote:
> > 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
> > > 
> > > 
> > > 
> > 
> 
> 
>