From: "Keith Moore" <moore(_at_)network-heretics(_dot_)com>
To: "Randy Presuhn" <randy_presuhn(_at_)mindspring(_dot_)com>
Sent: Thursday, June 09, 2011 5:49 PM
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt>
Consider, then, RFC 1157.
It was, quite rightly, declared historic years ago, even though it
was a full standard and in rather widespread use at the time.
Was there a replacement for RFC 1157 (presumably, a new version
of SNMP) generally available at the time that document was moved to Historic?
Yes, with some arguments about "generally".
I mean, it would make perfect sense to want to declare 1157 historic
if there were a new version available that clearly worked better. Right
now, there's not a readily available replacement for 6to4 that is clearly
So I think the comparison is not valid. SNMP (of whatever version) is a
protocol that you can use on your own network if you want to, and that's
where most of its utility is. You don't have to get your ISP to support it
before it's significantly useful to you. By contrast, the very purpose
of 6to4 is to communicate with peers over someone else's network(s).
If you want to run IPv6 over your own IPv4 network, 6rd or maybe
6over4 are better suited to that.
There appears to be some dispute about whether the functionality of 6to4 is
really needed. I take no sides in that part of the debate.
My comment was in response to the claim (which you have not made, AFAIK)
that it was inappropriate to declare a standards-track protocol historic while
still in widespread use, for reasonable interpretations of "widespread".
I was making no claims about 6to4's (de)merits.
Your argument seems to be that the peculiar operational characteristics of 6to4
should give it additional immunity to being declared historic. I don't find that
argument persuasive. The history of multiple protocols that have been
declared "historic" shows that vendors seem to care about that designation
only when it is convenient for them to do so. Installed base, customer
demand, operational considerations and so on all trump whatever the IETF
might say about a "historic" protocol. This works both ways: folks might
decide to kill something before it becomes historic, or support it long after.
We can't compel people to continue supporting it any more than we can
make them stop. At most, we can give them (hopefully convincing) reasons
to change. If the SNMP experience shows anything, it shows that even
that isn't enough. For that reason, I find it amusing when others write of
"killing" 6to4. We don't have that kind of power.
Ietf mailing list