Hi - > From: "Keith Moore" <moore@xxxxxxxxxxxxxxxxxxxx> > To: "Randy Presuhn" <randy_presuhn@xxxxxxxxxxxxxx> > Cc: <ietf@xxxxxxxx> > 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 better. > > 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. Randy _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf