[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt
I prefer to have the objects inline. This makes it easier for humans
to see the OID assignments that have been made. This is purely a
preference, and not doing it this way should have little impact on
tools, but human readability should be a high priority.
I would like to see a text section that discusses the fact they are
deprecated and why, and I would like to see comments at the object
definition (large and glaring if necessary) to point out that the
object is deprecated (possibly with a pointer back to the text section
in the RFC that discusses why, even though the surrounding text might
not be shipped with a stripped MIB module).
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of
> Sent: Thursday, July 13, 2006 7:05 AM
> To: firstname.lastname@example.org
> Subject: Fw: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt
> Hello Everyone,
> Just wanted to bring up the subject of placement for
> deprecated objects. This is no current guideline and
> it appears as though, one of the ADs has been advised
> several times to put deprecated objects at the end of the
> MIB Module.
> I'd like to reach a consensus on this and perhaps create
> a MIB guideline. The outcome is basically the same for the
> MIB Module (assuming MIB tools do the right thing) but when reading
> the MIB Module, there are certainly implications when putting
> near the end of the module. In my experience, deprecated objects
> are usually implemented, because customers want them.
> Any thoughts here? If there is no strong interest and both ways
> are acceptable, that would be good to know also.
> ----- Original Message -----
> From: <email@example.com>
> To: Bill Fenner <firstname.lastname@example.org>; <Kalyan.Tata@nokia.com>
> Cc: <email@example.com>; <firstname.lastname@example.org>
> Sent: Thursday, July 13, 2006 6:57 AM
> Subject: Re: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt
> > ----- Original Message -----
> > From: Bill Fenner <email@example.com>
> > To: <Kalyan.Tata@nokia.com>
> > Cc: <firstname.lastname@example.org>; <email@example.com>;
> > Sent: Wednesday, July 12, 2006 11:40 AM
> > Subject: RE: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt
> > Hi Bill,
> > >
> > > >5) I consulted with other MIB Doctors and the rough
> consensus was to
> > > >leave deprected objects where they are in the MIB, even
> though they are
> > > >deprecated but to make it very obvious that they are deprected.
> > >
> > > As Kaylan mentions, in my AD + RFC4181 review I suggested moving
> > > these, based on having received the same suggestion when we did
> > > RFC 4293, 4113, 4022. I thought that was the accepted procedure
> > > (it made sense to me, since we want a new MIB user to see and
> > > the current objects before the deprecated ones).
> > >
> > Yes, there does seem to be 2 ways deprecated objects are handled
> > (i.e., leave the deprecated objects in place or move them to the
> > of the MIB Module). My motivation for consulting the
> > other MIB Drs was to see if there was a recommended way of
> > handling deprecated objects.
> > The MIB Drs. that commented on my question seemed to prefer
> leaving the
> > deprecated objects where they were. This is also my
> preference because
> > deprecated
> > objects are often still wanted by the customers and thus, agent
> > developers implement them for some length of time. The
> IP-MIB (RFC 4293)
> > is an example of where deprecated objects continue to be
> > (at least in my experience, others may have a different
> > So, how best to bring closure to this issue for this MIB Module?
> > Certainly, the document may proceed with the deprecated objects
> > where they are. I will revisit the issue with the MIB Drs.
> and hopefully
> > this will result in a new guideline.
> > Thanks,
> > -Joan
> > > Bill