RE: reviewer guidelines

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

Hi Mike,

I have run into multiple applications that assumed all mib OIDs started
with 1.3.6.1, and when they imported mibs into their internal databases,
they didn't bother to record the 1.3.6.1 prefix. I would like to make
application developers more aware of the fact this is a bad assumption. 

I would like to suggest to the mib authors to add one sentence to only
those mib modules that 1) do not start with 1.3.6.1, 2) are (presumably)
developed by other SDOs, and 3) are reviewed by the IETF mib doctors. I
expect the number of mibs that meet those qualities to be very small,
but growing. 

I do not see this as "cluttering up" a mib, but providing application
developers with a warning about the fact that in this way the mib is
non-"standard" (to use your original wording about "standard" mib OIDs).
Suggesting this to the mib authors might also make them more aware that
putting a mib into a non-IANA-controlled subtree could cause problems
for some developers; maybe they will choose to change their mib to be
registered under IANA control.

dbh

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com] 
> Sent: Tuesday, January 21, 2003 5:59 PM
> To: Mreview (E-mail)
> Subject: RE: reviewer guidelines
> 
> 
> On Tue, 21 Jan 2003, Harrington, David wrote:
> > I think it would be good, for mibs that other SDOs ask the mib
> > doctors to review, where the OIDs are not in the IETF mib
> > subtree, to suggest that the SDO put a notice in the mib warning
> > implementers (mainly application developers) to note that the
> > OID is outside the IETF mib subtrees, and does not start with
> > 1.3.6.1 as a result.
> 
> Is this really a problem?  I'm reluctant to ask people to clutter up
> their MIB modules with notes like that, unless it addresses a real
> problem.  I've been under the impression that OIDs of MIB objects
> are generally resolved into numeric form automatically by MIB
> processing tools.  A note would not help in that case.
> 
> //cmh
> 
> 
>