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

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

RFC 2578 has language, sich as that found in section 10.2:
(3)  A STATUS clause value of "current" may be revised as "deprecated"
     or "obsolete".  Similarly, a STATUS clause value of "deprecated"
     may be revised as "obsolete".  When making such a change, the
     DESCRIPTION clause should be updated to explain the rationale.

Personally, I believe the above "should" needs to be replaced
as "must". For deprecated items, I start the DESCRIPTION text
with something like..
"This item is DEPRECRATED. This is done because..."
I thne leave the original DESCRIPTION text. For obsoleted
items, I generally remove the original DESCRIPTION cause
text.

Regards,
/david t. perkins

On Thu, 13 Jul 2006, David Harrington wrote:
> 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
> > >
> > 
> > 
> 
>