> From: Lorenzo Colitti <lorenzo@xxxxxxxxxx>
> Compared to the alternative of publishing 6to4-historic now, it:
> a) Delays the time of any statement made by the IETF on the question
> by at least a number of months, while vendors and home gateways are
> *still shipping* products that implement 6to4 and enable it by
> default.
draft-ietf-v6ops-6to4-advisory - which already exists, and which nobody is
objecting to - already contains text which tells manufacturers of both
home routers and hosts to disable 6to4 by default, etc, etc. If acting
ASAP is desirable, that ID could be approved just as quickly as
draft-ietf-v6ops-6to4-to-historic-05.txt could be (to be later updated by
the new document mentioned in the recent announcement).
> b) Even assuming it were to gain consensus in any sort of reasonable
> timescale, it would provide a less clear statement, and thus be less
> of an incentive for implementors such as home gateway manufacturers
> to do the right thing and remove it.
First, killing 6to4 is an additional goal, above and beyond 'stop 6to4
from causing problems'. The only conceivable reason I can think of for
that additional step seems to be the possibility that somehow 6to4 will
cause problems anyway, even if it is normally disabled? This seems
unlikely to me. Is there any reason beyond that to kill 6to4?
Second, what reason is there to believe that a document that says 'remove
6to4' is going to meet with greater/faster compliance from vendors than a
document that says 'disable it'? I would argue that the former takes more
engineering time, and is actually marginally less likely to be timely
responded to.
Noel
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf