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

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

Inline

> -----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
> 
> 
> [ NOTE:  this is cross-posted to the MIBS list
>   because the discussion concerns both IPv4 and
>   IPv6. The "new MIBS" referred to are those in
>   draft-ietf-ipngwg-rfc2011-update-00.txt,
>   draft-ietf-ipngwg-rfc2012-update-00.txt,
>   draft-ietf-ipngwg-rfc2013-update-00.txt, and
>   draft-ietf-ipngwg-rfc2096-update-00.txt.  ]
> 
> 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.

> 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.


I hope this eases some of your concerns.

Bert