In general the practice of "importing a (updated) specification" is a bad practice as most network management systems only keep a single version of a MIB module. Importing the latest version into the management system does not take into account the fact that there may different implementations on the boxes in the network and hence the tools break when working with older implementations along with the new specification.
What is required is a proper and full version control of the way we specify our MIB modules... which is way beyond the scope of this particular discussion.
Regards, /gww
> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]
> Sent: Tuesday, October 26, 2004 14:40
> To: David B Harrington
> Cc: 'Wijnen, Bert (Bert)'; 'Mreview (E-mail)'; 'Bill Fenner (E-mail)';
> 'John Flick (E-mail)'; 'Margaret Wasserman (E-mail)'
> Subject: Re: Question on: draft-ietf-ipv6-rfc2013-update-04.txt
>
> On Tue, Oct 26, 2004 at 01:13:29PM -0400, David B Harrington wrote:
>
> > Having worked on management applications, I do have a strong opinion
> > on this. I believe we should provide a machine-readable object showing
> > that the object is deprecated/obsolete.
> >
> > If we do this, then manager applications can import the object and its
> > new status, and warn the operator doing the import that the object is
> > now obsolete or deprecated and that they should check to see if there
> > is a better object to monitor.
>
> Yeah, but those who do not import the updated specification will
> nevertheless continue using the old outdated objects. There is IMHO
> no way to fix this problem and it is more general than just MIB
> modules.
>
> There are still people out there asking question about SNMPv2p. We
> all know this is historic and obsolete. Still, people read books or
> other outdated sources of information and get confused. Even if we
> would have incorporated the SNMPv2p specifications into the SNMPv3
> documents marking each sentence as outdated, the problem would
> persist.
>
> The only solution to this problem is education and to publish an
> easily accessible list of the current MIB modules (and which ones
> are obsolete). The Simple Times has been a good source for this kind
> of information, but due to lack of contributions, it is currently in
> a hibernation mode. Anyway, even with the Simple Times in place, people
> still ask about SNMPv2p stuff in several places...
>
> The only other option I see is that we actually get the act together
> to setup a repository for all the IETF MIB modules which is actively
> maintained. When a MIB module is published which makes another module
> historic, the document could just request that all the definitions
> contained in that module are changed to obsolete, which is carried
> out in the repository. This would be light-weight and perhaps generally
> useful once a well maintained repository does exist. But even then,
> some will ignore it and use outdated information - there is just no
> way to fix this.
>
> /js
>
> --
> Juergen Schoenwaelder International University Bremen
> <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen,
> Germany
>