Hi. I've been thinking about this and having a few off-list conversations and want to make a suggestion that draws together a few others. Since many people don't like my long notes with the conclusion at the end, this one is suggestion-first. If the suggestion offends you sufficiently, you can just stop reading there.
Recommendation: (1) Abandon the effort to classify the specifications as Historic. It is at best a symbolic act that few people outside the IETF community will even notice, much less act differently because we have done it. Instead, let's try to focus on what is actually important, not classification and name-called ("curse you, you Historic protocol" :-( ). (2) Pull the "-advice" document back from the RFC Editor queue and fold the actual substantive content of the "-historic" document into it, preferably as a very clear and very prominent Applicability Statement. If this is what v6ops believes, the statement might reasonably say something like: (2a) This protocol, if not used very carefully, leads to bad operational situations in which things get lost and the problems are hard to diagnose. We strongly recommend that it not ever be a default and that it not be used except under special circumstances and with great care. (2b) Even then, we recommend that it not be used unless all of those configuring routing information and all the systems along the routing path are run by experts who both understanding the issues and are willing to accept responsibility. (2c) If you do decide to use the thing, the "advice" recommendations in the rest of this document are mandatory and MUST be followed to avoid serious operational problems. I haven't included either Randy's colorful language or mine in the example above, but the intent should be clear. Depending on how much detail the community thinks is useful, there is a good deal of potentially-useful text in draft-moore-6to4-experimental as well as in the "-historic" draft. The resulting document should explicitly update RFC3056 and RFC3068. Taking that action will send a much stronger "you need to read that document before doing anything with this one" message to most of the people who are familiar with how things work than a reclassification of the base documents. For those who aren't familiar with how things work, all of these approaches, including moving 6to4 to Historic, are pointless. That is all. This can and should be made to sound like mature engineering advice, which it presumably is, and not like small children throwing mud at each other. Explanation and Rants: (ii) I think moving _this_ protocol to Experimental is just silly. We use Experimental for things that are pre-standardization or not sufficiently mature to be standardized. Although the bar is higher, there are elements of "experiment" in every Proposed Standard --that is why we have a multiple-step standardization process. If there is really something to be learned from 6to4 operated in a different way, then the right action to take would be to propose a 6to4bis that outlines the characteristics of the protocol, eliminates anything we have concluded should not be done, and outlines the desired experiment. That document might reasonably be listed as updating RFC3056 and RFC3068 as well. (i) <rant> Presumably our goal is to get IPv6 deployed and provide advice useful to its deployment, independent of any particular piece of protocol or transition arrangement. At least one of the many reasons we haven't seen more deployment is that we keep sending messages to the broader community that, however unintentionally, discourage that deployment. In the early days of IPv6, we did that by advertising (or letting others who were presumed to be speaking for us advertise) that IPv6 was completely ready and that transition was going to be easy, cheap, and seamless. For those who had to make decisions as to when to deploy IPv6, sufficient investigation tp discover that some of that story was untrue became sufficient motivation to back away from IPv6 entirely until we got our acts together. In more recent years, we have continued to deliver the message that the IETF (and, to a lesser extent the RIRs) are simply confused about what advice to give and therefore that IPv6 isn't ready for someone to deploy who suffers from limited resources and a strong desire to do it only when all of the ducks are lined up. Every time we propose a new transition model or denounce an old one without what seems to be an externally-convincing analysis of the complete picture, we make things worse by distributing yet another chapter of "even the IETF has no real idea how to transition to IPv6". If we are serious about encouraging deployment of IPv6 -- and I hope we are -- then it is time to stop the apparent war among transition strategies. It seems to me that the document that is needed is a vastly strengthened (and probably standards-track) version of RFC 6180 (a rather nice document that I would encourage those who are engaged in the 6to4 debate on the IETF list to read), but one that goes beyond such statements as There are several types of tunneling mechanisms, including manually configured IPv6-over-IPv4 tunnels [RFC4213], 6to4 [RFC3056], automatic host-based tunnels [RFC4380], tunnel brokers [RFC3053], running IPv6 over MPLS with IPv6 Provider Edge Routers (6PE) [RFC4798], the use of Virtual Private Networks (VPNs) or mobility tunnels to carry both IPv4 and IPv6 [RFC4301] [RFC5454] [RFC5555] [RFC5844], and many others. (from Section 4.2) and into a serious discussion of the scenarios that are the best match to different of these strategies (and others). If we don't know, then let's say, explicitly, that we haven't had quite enough experience to provide a differential chart of when particular techniques can be used but that they are out their, with their strengths and weaknesses, for situations to which they seem well-adapted. It is almost possible to infer from 6180's conclusions that almost all transition mechanisms are equivalent, at least within groups, and those that aren't are best dealt with by public burning. Clearly we don't believe the first part of that; we should get away from the appearance of believing the second. And, again and most important, if we want to see IPv6 deployed, we need a clear message that we actually understand what we are doing, that we have a coherent picture, and that our process is not one of lurching among solutions, hoping that each one will be the magic bullet, and then denouncing any that turn out to not have sufficient magical properties. The marketplace knows how to deal with the message we are sending with debates about recategorization and we have already seen the answer: it isn't the universal deployment of IPv6 before now or any time soon. </rant> john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf