[ 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.
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.
In the case of the draft IP MIB there would be some gain in
functionality for an IPv4-only implementation in the form of
per-interface statistics. Since providing this functionality
would require new objects anyway, so it's reasonable to provide
them in a version-independent manner. On the other hand, it's
news to me that there has been a significant demand from actual
users for this feature (correction from actual users is invited),
particularly at the cost of backward compatibility.
In the case of the TCP and UDP MIBs there is no gain in functionality
for an IPv4-only implementation apart from high-capacity counters,
and those are protocol-neutral anyway. Apart from those counters,
the old MIB-II stuff for IPv4 supplemented by the IPv6 TCP connection
table in RFC 2452 and the IPv6 UDP listener table in RFC 2454 seem to
provide the same functionality. I don't see any problem that the
draft solve by replacing the version-specific tables, but I see plenty
of problems that they would create by having new implementations not
being backward compatible with old ones, not to mention implementation
churn. Is it really worth all that to fix what to fix what is essentially
an aesthetic flaw? Better the approach of RFC 2452 and RFC 2454, which
would leave IPv4-only implementations intact.
Mike
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
