Re: Updates to rfc2011, rfc2096 others

["C. M. Heard" <heard@pobox.com>]

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