RE: Updates to rfc2011, rfc2096 others

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Thanks for sharing your views on this Mike.

When this work first started, I had not expected that all existing objects
in 2096 (for example) would be deprecated and that we would end up will
only new current objects. So back then I also thought it better to keep
it in one document and mib module. Now I am not so sure. I do agree it
is late inm the process to even bring this up. But right now is THE TIME
that it can still be changed if we thought such would be useful and/or
make sense.

Any other opinions PLEASE!

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: dinsdag 27 januari 2004 16:39
> To: Mreview (E-mail)
> Subject: Re: Updates to rfc2011, rfc2096 others
> 
> 
> On Mon, 26 Jan 2004, Wijnen, Bert (Bert) wrote:
> > I wonder if we are doing a smart thing to update those
> > documents, keep all the old baggage (most of which is
> > depreacated or obsoleted).
> > 
> > Specifically RFC2096 update only has NEW objects that are
> > current. all the former objects from RFC2096 are depreacted
> > or obsoleted. Does it make sense to do it this way or would 
> > we (in a few years) be much better of if we made this a separate
> > MIM module. It can still obsolete the old RFC2096. 
> > Or maybe it should include the old MIB module as a separate 
> > module with just all the deprecated material?
> > 
> > What use does it have to present it as one (bigger) MIB module?
> 
> I think it is probably _better_ to present it that way than it would
> be to have separate documents or MIB modules, because with the
> consolidated presentation there is just one IETF routing table MIB
> module -- the IP-FORWARD-MIB -- and a person call tell by looking at
> the most recent version of that MIB module which definitions are
> useless and should not be implemented (obsolete ones), which ones
> are in use but are being nudged out (the deprecated IPv4-only
> definitions), and which ones are preferred (the current
> definitions).  Unlike some MIB modules, the IP-FORWARD-MIB stands
> almost completely alone, needing very little supporting narrative in
> the containing RFC-to-be.
> 
> There is one way in which I exaggerated in the previous paragraph,
> and that is that the IP-FORWARD-MIB is actually not the only IETF
> routing table MIB module.  There is also the ipRouteTable in RFC
> 1213, which is even more badly flawed than the obsolete stuff in RFC
> 2096 or its update, and there is also the ipv6RouteTable in RFC
> 2465.  I don't think the ipv6RouteTable is very widely implemented
> (nor is RFC 2465 very widely cited), but there are still many
> products out there that claim support of the ipRouteTable.  The fact
> that the ipRouteTable is not explicitly listed with the other
> obsolete objects in IP-FORWARD-MIB is probably a contributing factor
> to the unfortunate longevity of this flawed table.  More
> fragmentation of the IETF routing MIB modules won't be helpful, in
> my opinion.
> 
> There is one other point that I would like to make.  There is
> nothing in our published rules (i.e., in the SMIv2 documents or in
> the MIB review guidelines) that provides guidance to authors in
> situations like this one, and the choice made in this case by the
> IPv6 design team (and accepted by the IPv6 WG) is certainly a
> workable one.  While it would be fair to _suggest_ a different
> presentation (e.g., as two MIB modules in one document, or as two
> documents) I don't think it would be fair to _require_ that as a
> condition of publication.  This is a judgment call, and my advice
> would be to accept the WG's judgment.
> 
> Thanks and regards,
> 
> Mike Heard
> 
>