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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf