Ned, On Jun 17, 2010, at 2:18 PM, Ned Freed wrote: > Well, first of all, there are plenty of places that do not enjoy the benefits > of all that fancy stuff. What may be a tiny bit of meaningless overhead may > be something else entirely for someone else. Perhaps. However, since connecting to the Internet today implies you are constantly flooded with probes of various flavors from myriad malware and miscreants, I have some skepticism that anyone would even notice a few additional packets/kbytes of data during communication set up. And in such cases, I'd imagine connection status info would be cached (like most resolvers cache EDNS0 support in DNS). > And those failed lookups have a real support overhead cost. Among other things, > they create entries in appliction and firewall logs. I would think the delays implied by IPv6-then-IPv4 communication setup failure would result in _far_ more calls than calls from the (relatively) few people who look at application and firewall logs (ever look at the console log on your average MacOSX system? I doubt Apple gets many calls despite the tremendous amount of noise that gets logged). > At this point I wouldn't consider shipping an application that doesn't support > at least basic IPv6 connectivity, but there's also no way I'd consider shipping > an application that has that support enabled by default, because it's > guaranteed to be a support call generator. An understandable and conservative approach, however won't the implication of taking this route be that in the longer term, your products will, by default, generate support calls as customers will not be able to connect to IPv6-only sites (or connect sub-optimally to multi-layer NATv4 sites)? [On APIs] > At this point the work is really too little too late. I've read long ago that back in the 80s, the guy who wrote make(1) realized that makefile's use of whitespace was problematic, but the user base of about 50 people was too large to make any changes... Regards, -drc _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf