John, On one specific point: >> So my personal preference, in a more perfect world, would be to >> fold these two drafts together, I specifically pushed for the -advisory draft to be kept separate and Informational in order to get it out ASAP (in my dreams, before IPv6 Day, but that didn't prove possible). I still think that is the correct approach - decouple the practical advice from the admittedly political debate. I'm not dismissing the rest of your points - clearly there are varied opinions and "Historic" is, as you say, a blunt instrument. Regards Brian On 2011-06-11 09:05, John C Klensin wrote: > > --On Saturday, June 11, 2011 05:28 +1200 Brian E Carpenter > <brian.e.carpenter@xxxxxxxxx> wrote: > >> John, >> >> On 2011-06-11 05:05, John C Klensin wrote: >> >> ... >>> But, to the extent to which the motivation for moving 6to4 to >>> Historic is what Tony describes as "kill-what-we-don't-like", >> Unfortunately, as I know from the enormous amount of technical >> feedback I got from living, breathing operators while drafting >> draft-ietf-v6ops-advisory, the motivation is "kill something >> that is causing real operational problems and failure modes." >> I wouldn't be endorsing draft-ietf-v6ops-6to4-to-historic if >> there wasn't a very sound operational argument for it. >> >> I think nobody wants to kill the successful use of 6to4, but >> we need to stop the operational problems getting worse. It >> appears that the default help desk advice to disable 1PV6 is >> generally an echo of problems caused by on-by-default 6to4. > > Brian, > > This is not in my primary area of expertise and I am painfully > aware that it has been almost a decade since I have been able to > look in on these things from the viewpoint of an ISP with > default-free backbone arrangements, small end-site customers, > and almost everything in between. > >>From the above and other comments you have made, I don't think > we disagree very much on the substance here. I'm certainly not > about to try to make the case that 6to4 is a wonderful option to > be widely preferred. As a variation on your comment above, I > don't want to see the IETF denounce or kill the successful use > of 6to4 and don't believe anyone else does either (or at least > should). > > Where we disagree is about a procedural matter and the stance > the IETF takes formally and, perhaps still, about where the > motivations to deploy IPv6 "for real" comes from. > > Let me see if I can describe my position and recommendation in > another way: > > Even among those of us who believe that IPv6 conversion has > ceased being optional and has to be considered the only option > at this stage, we really have few clues about what is going to > cause a given ISP, or a given end-node customer, to switch over. > Most of our arguments are faulty, at least for some particular > set of cases. Your capitalism/competition one is an example -- > there are places where it will work and places where it won't. > The applications support and availability of IPv6-capable (and > IPv6-native) servers is another -- sometimes ISPs are waiting > for customer demand and/or enough deployment on customer sites > before they think about making the switch and the customers are > waiting for more evidence that the applications issues are > sorted out and will work reliably. We talk about the advantages > to the folks who switch early, but we are aware that some folks > don't want to be the first to switch. And so on, for a rather > long list. > > Part of this adds up to a conclusion that we are lots better at > protocol design than we are at predicting the future or gaming > out the decision processes under various circumstances. We had > better be -- our track record for those predictions is bad > enough that, if our protocol design and engineering were worse, > we should all find other occupations. > > At the same time, my very limited and quite anecdotal experience > suggests that the decision in several dual-stack setups to > automatically prefer IPv6 when it is available (following IETF > advice if I recall) combines with sometimes-sketchy IPv6 > connections and routing to cause connectivity problems that can > overwhelm the sorts of folks who staff first-level help desks. > 6to4 is certainly part of that problem --and a little worse if > it is set up without user or ISP knowledge-- but the implicit > argument in both ..-6to4-advice and 6to4-historic that 6to4 is > the dominant cause of those problems isn't convincing. Maybe it > is the case, maybe it is the dominant case (and, again, I don't > have enough firsthand experience in recent years to claim to > know) but certainly it is not the only one. > > I accept the claim that it can easily be misconfigured, but that > may not be sufficient to demonize it. > > I don't think the technical content of either > draft-ietf-v6ops-6to4-to-historic or > draft-ietf-v6ops-6to4-advisory is especially bad. Indeed, the > analysis in ...-6to4-advisory seems quite good to me -- the sort > of thing the IETF should, IMO, be doing a lot more often. I'm > just suggesting that we should not write off _any_ option that > has proven useful to folks in preparing to transition, planning > for transitions, or actually transitioning. To that end, the > abstract of ...6to4-advisory is just the right think to do. > Advising that 6to4 is a really lousy default, that > implementations should allow it to be turned on only after > appropriate warnings and only if the advice in Section 4 of > ..-6to4-advice is followed _really_ carefully may be entirely > appropriate. Put differently, your analysis appears good enough > that I can see no argument against branding 6to4 as "really > dangerous -- use only if actually understood and needed, then > with great caution, and then only if there is some reason why > 6rd is inappropriate or unavailable". > > But "Historic" is a really blunt instrument, especially since we > use it primarily for protocols that are no longer in use and/or > that have been demonstrated to be of no redeeming value. This > situation is, IMO, an almost perfect example of why 2026 permits > us to identify a protocol specification as "NOT RECOMMENDED" > (yes, I think 2119 is defective in listing the conformance > language (MUST/ SHOULD/ MAY/...) but not the recommendation > terminology, but that is another topic). > > So my personal preference, in a more perfect world, would be to > fold these two drafts together, drop "Historic" and any even > slightly hyperbolic language, issue the combination as a > standards-track A/S that updates 3056 and 3068 and makes a clear > and carefully explained "NOT RECOMMENDED" statement. If, in > conjunction with that move, you or others see value in > downgrading 3056 and 3068 to Experimental and including comments > to the effect that they are normally useful only for > exploratory/experimental use, I wouldn't have any problem with > that at all. > > I actually don't feel very strongly about the above. I probably > would not have said anything in this thread if you hadn't raised > the capitalism/competition argument. But, if there is a > situation where 6to4 really is appropriate and the IETF makes > what appears to be a strong statement deprecating it, we either > convince someone to further defer thinking through and migrating > to IPv6 or we help contribute to the impression that the IETF is > out of touch with real world realities. I don't consider either > of those outcomes desirable and presume you don't either. On > the other hand, my impression from conversations with operations > is that it certainly would not be either the first or the most > extreme case in which we've shown the IETF to be out of touch > and at least some users and implementers who find value in 6to4 > are likely to continue doing whatever they think it is > appropriate to do regardless of what labels the IETF decided to > put on the specs. > > best, > john > > > p.s. Editorial nit: I'd love to know what a "domestic customer" > in Sections 2 and 4.2.4 of ...-6to4-advice is. The term is as > likely to be construed as "within a particular country" (New > Zealand?) as "residential" (which I'm guessing is what you > mean). As far as I can tell from skimming the document > "residential, small office, or home office (SOHO)" would be more > appropriate and consistent with terminology in common use. > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf