At 08:09 AM 10/10/2003, Margaret(_dot_)Wasserman(_at_)nokia(_dot_)com wrote:
Removing a feature from a specification doesn't even prevent people
from using it
I'm changing the thread subject. While this is relevant to the subject
of Tony's appeal, it is also a general debate orthogonal to Tony's
appeal. It is a side note that may prove relevant. While your
assertion may generally be true, this particular change does prevent
people from using it, and I'm not sure the assertion is true as
worded.
Given that the objections to site local were based on the realization
that using it actually causes harm to applications and to the network,
then I agree with you. Most of us realize that we cannot prevent
harmful behavior, especially on a private network. But the intent of
deprecating site-local was at the very minimum to strongly discourage
its use.
The site-local proposal says that there is an assurance that a
particular block of addresses is available to a network administration
to use in whatever way it chooses within the confines of its own
network, on the proviso that it neither advertise those addresses
outside its network in routing nor trust announcements of the block by
others, and presumably also ingress filters for the address prefix.
It turns out that those usage constraints are not sufficient to avoid
harm to the network as a whole, and after numerous attempts we have
not been able to define a set of constraints that still allow use of
site-local while avoiding that harm.
Your assertion is also dangerous in protocols. If a capability is
deprecated (remains defined but its implementation/use is discouraged,
as for example true of TOS routing in OSPF, cf RFCs 1583, 2178, and
2328), then an implementation that contains the capability can
accurately say it is using a superset of the specification.
The terms you are using are biased. A vendor could define a "superset"
of IP that had the "capability" of routing addresses to destinations
other than those intended by the source, or modifying the contents of
messages sent by the source, or masquerading as the destination and
issuing responses that appear to come from the destination. A DNS
server could add the "capability" of misrepresenting the status of a
name given in a query. Indeed, all of these "capabilities" exist in
some product or another. It also turns out that all of these
"capabilities" cause harm to applications.
It's a fallacy to believe, and disingeneous to pretend, that
providing new "capabilities" or a "superset" of a protocol is at worst
a benign activity. There exist "capabilities" that do harm. In the
case of site-locals, it happens that this "capability" was part of an
IETF specification. So once we realized that site-locals were harmful,
it became our responsibility to fix them. I agree, as do most of us,
that we should make considerable effort to avoid disruptive changes to
published specifications. However it was only after investigating
several proposals for less disruptive fixes, and finding all of them
insufficient, that there emerged a consensus to deprecate site-locals.
If the
capability is simply removed, one has to presume that at some time in
the future the bits will be reused with different semantics, making
the implementation that yesterday was using a superset of the
specification an active hazard today, and causing operational networks
that were using the capability to have to make some potentially hard
choices.
We can promise to not re-assign them, and we can keep our promise.
But if site administrators decide to move away from site-locals, this is
a good thing, as it will minimize the harm done by having them in the wild.
Keith