FW: MIB Dr. Review of draft-ietf-vrrp-unified-mib-05.txt

["David Harrington" <ietfdbh@comcast.net>]

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).

My $.02
David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net
 

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of 
> jcucchiara@mindspring.com
> Sent: Thursday, July 13, 2006 7:05 AM
> To: mreview@ops.ietf.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
objects
> 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.
> 
> Thanks,
>   Joan
> 
> 
> ----- Original Message -----
> From: <jcucchiara@mindspring.com>
> To: Bill Fenner <fenner@research.att.com>; <Kalyan.Tata@nokia.com>
> Cc: <dromasca@avaya.com>; <vrrp@ietf.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 <fenner@research.att.com>
> > To: <Kalyan.Tata@nokia.com>
> > Cc: <jcucchiara@mindspring.com>; <dromasca@avaya.com>; 
> <vrrp@ietf.org>
> > 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
use
> > > 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
end
> > 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
implemented
> > (at least in my experience, others may have a different
experience).
> >
> > 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
> >
> 
>