--On Friday, July 15, 2011 15:39 -0700 Doug Barton
<dougb@xxxxxxxxxxxxx> wrote:
> To address your concern about whether or not vendors are paying
> attention to this discussion, and why historic status is
> substantively different than "off by default, no really, OFF
> BY DEFAULT," I'll put my FreeBSD developer hat on for a minute
> and tell you that we definitely do pay attention to stuff like
> this, and whereas we already have it off by default (and have
> for some time) moving it to historic gives us the cover we
> need to remove the code at some point down the road when that's
> appropriate. That's an extremely important distinction, and
> one of the reasons that as a "member" of v6ops I ultimately
> came down in support of the 2-document strategy.
Doug,
And that is exactly where we agree on the effect and disagree
about whether it is desirable.
I think there is consensus that 6to4 is dangerous unless
carefully and intelligently configured and that is certainly
should not be turned on by default. If anyone has argued
against that position, they are in a tiny minority.
Similarly, I think there is consensus that following the advice
in the "advice" document makes 6to4 much safer to use, even if
not entirely risk-free (I contend that there is no "risk-free",
perhaps as a corollary to the principle that, if we invent
something idiot-proof, someone will invent a better idiot). So
there should be no question about the desirability about
publishing the content of that document.
The question, as far as the "advice" document is concerned, is
how to get the message out most effectively, most clearly, and
on as timely a basis as possible. I think that having it
"update" the base 6to4 specs is important because that is how
the RFC Series is threaded. Without that, there is an increased
risk of people finding the 6to4 specs and implementing them
without ever seeing the "advice" piece (just as, even with the
"updates"/"updated by" pointers, we still hear about new TCP
implementations based on RFC 793 alone). For the reasons
discussed above, I don't think anyone would find that outcome
desirable. As to whether there should be a single document or a
separate Applicability Statement that points to both the base
specifications and the "advice" document, I'm really pretty
agnostic even though I don't see many advantages in two
documents. A separate Applicability Statement that does update
the base documents but points to the "advice" one would
accomplish much the same purpose and eliminate the requirement
that the "advice" document explicitly update the base ones.
While I think publishing a separate document just to avoid that
linkage would waste time, I'm actually pretty agnostic about
that option too.
But, while some people have argued that 6to4 has caused so much
damage by being misconfigured that it should, presumably as
punishment or to create a public example, be eliminated entirely
as an option -- for FreeBSD users, the exact effect of your
removing the code -- I haven't seen nearly as strong as case, or
anything even close to consensus, for that position. If it was
actually what the community believed, then the "advice" document
would be a complete waste of time except possibly as a
retrospective on how 6to4 might have been better specified (a
retrospective that we would want to publish as (immediately)
Historic).
If the thing is still useful, even in limited circumstances and
used correctly, then the IETF should not provide you with
"cover" to remove the code because it is not in the best
interest of the community for you to remove the code. Might
both your removing the code and moving 6to4 to Historic in the
future be appropriate? Sure. I also look forward to the day
when we can move IPv4 to Historic (just as the various
specifications that make up NCP should have been moved years ago
if we paid attention to that sort of housekeeping).
Summary: we should not move something to Historic that is still
in use, useful, and that can be used correctly. We explain how
to use it or the circumstances under which is should or should
not be used, narrowing those descriptions as much as needed.
And/or we explain all of the situations in which it should not
be used. Simply reclassifying it as Historic is problematic to
the use cases that actually do work and doesn't provide nearly
enough information as what people should actually do, especially
people who already have the protocol deployed in some form.
Using Historic, rather than, e.g., NOT RECOMMENDED [any more] as
a sort of super-deprecation mechanism depends too much on our
assumption that people with working deployments will simply
ignore us. While the assumption is right, it puts the whole
situation into one in which the IETF is publicly operating on
the assumption that its advice won't be followed. If we do
that very often, we might as well just go home.
FWIW, I note that there are at least a few other things that
shipped for years with FreeBSD that could cause a lot of damage
if misconfigured and were hard to configure correctly, but were
nonetheless included in the code in version after version and
even were enabled by default. Getting rid of them would not
have required any IETF action -- there were other
implementations of the same protocols that could have been
included in the base systems instead. But they weren't removed
or replaced (the folks who produced them eventually produced
better versions). But I don't recall seeing the sort of venom
that is directed toward 6to4 being focused on them. Perhaps
there weren't enough complaints or you have solid data that 6to4
has caused even more damage.
best,
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf