RE: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466

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

On Sun, 26 Aug 2001, Wijnen, Bert (Bert) wrote:

> > -----Original Message-----
> > From: C. M. Heard [mailto:heard@pobox.com]
> > Sent: dinsdag 7 augustus 2001 1:29
> > To: ipng@sunroof.eng.sun.com; mibs@ops.ietf.org
> > Subject: Re: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466
[ ... ]
> > 
> > On Fri, 27 Jul 2001, Bill Fenner wrote:
> > >   The plan is to deprecate the existing objects in these RFCs
> > > in favor of the protocol-independent ones.  The exact plan is not
> > > yet known (e.g. publish a new revision with all objects listed
> > > as deprecated vs. reclassify the old RFCs as historic, etc.).
> > 
> > And as one can see explicitly from the drafts themselves, the intent
> > is also to deprecate all of the IPv4-specific stuff in RFC 2011,
> > RFC 2012, RFC 2013, and RFC 2096.  Note that the MIB modules in the
> > first three of these RFCs are simply translations into SMIv2 of
> > the MIB-II IP group (less routing table), TCP group, and UDP group,
> > respectively;  the substance is unchanged from RFC 1213.
> > 
> > > The intent is definitely not to suddenly cause existing 
> > > implementations to be non-standard, but to encourage evolution.
> > 
> > But that's PRECISELY what adoption of these drafts in their present
> > form would do.  Where new compliance statements exist, they make the
> > new version-independent objects unconditionally mandatory and don't
> > mention the version-specific objects.  That makes existing 
> > implementations
> > non-compliant and (if the drafts were to be adopted as standards)
> > non-standard.
> > 
> I doubt that this is true. The objects are DEPRECATED, which means they
> are they are specifically there for backward compatibility and continued
> interoperability with old/existing implementations.
> If we wanted to break with backward compatibility, then we would OBSOLETE
> those objects. See RFC2578 section 6.1 for details.

RFC 2578 says:

   The value "obsolete" means the definition is obsolete and should not
   be implemented and/or can be removed if previously implemented.
   While the value "deprecated" also indicates an obsolete definition,
   it permits new/continued implementation in order to foster
   interoperability with older/existing implementations.

Note well:  this _permits_ new/continued implementation of deprecated
objects, but does not _require_ it.  It is left to the module's
compliance statements to specify whether the deprecated objects are
optional, conditionally mandatory, or unconditionally mandatory.

Because of the wide deployment of the stuff in RFC 2011, RFC 2012, and
RFC 2013 (i.e. the IP, ICMP, TCP, and UDP groups in RFC 1213 less the
ipRouteTable), continued interoperation with deployed IPv4-only managers
(respectively agents) will _require_ that new agents (respectively managers)
implement the IPv4-only objects in these MIB modules.  Thus, to avoid a
break with backward compatibility, it seems to me that the compliance
statements in the documents that replace RFC 2011, RFC 2012, and
RFC 2013 need to make these objects manadatory for implementations that
support IPv4.  The present round of drafts does not do this.

> > Notice that it is not just existing implementations of the existing
> > IPv6 MIBs in RFC 2452, RFC 2454, RFC 2465, and RFC 2466 that would
> > be destandardized, but also existing implementations of the MIB-II
> > IP, TCP, and UDP groups.  The older IPv4-specific objects have in all
> > cases been deprecated in favor of the new protocol-independent objects,
> > and so have the old IPv4-specific compliance statements.  
> > 
> So we want to encourage new implementations to use the new objects while
> existing ones can continue to use the old ones. The old ones in fact
> are still at Full Standard (RFC1213) for quite a while to come.

But the new implementations need to implement the old IPv4-only objects
in RFC 1213 in order to interoperate with old implementations.  Shouldn't
this be an explicit _requirement_ of the conformance statements in the
new documents?

> I hope this eases some of your concerns.

Some, but not all.  I am still troubled that the drafts that are proposed
to replace RFC 2012 and RFC 2013 (IPv4-only TCP and UDP MIBs) and RFC 2452
and RFC 2454 (IPv6-only TCP and UDP MIBs) are fixing some things that are
not actually broken.  Maybe it is more elegant to have one combined
version-independent connection table/listener table instead to two
version-specific ones, but there is no gain at all in functionality.
I ask again:  it it worth the implementation churn to make what is,
in effect, and aesthetic change?  I can see a reason to republish
RFC 2452 and RFC 2454 to improve the compliance statements (i.e. to
explicity reference the necessary objects from RFC 2012 and RFC 2013),
but I can't see what it buys to replace the version-specific connection
and listener tables, especially since the the IPv4-specifc ones need to
be implemented anyway in order to maintain interoperability with
deployed implementations.

Mike