> On Mar 31, 2010, at 12:28 AM, Igor Gashinsky wrote: >> >> You are absolutely right -- it's not a DNS problem, it *is* a host >> behavior problem. The issue is that it takes *years* to fix a host >> behavior problem, and we need to engineer and deploy a fix much sooner >> then that (hopefully about a year before the v4 exhaustion date). Given >> that, is there something other then DNS that can address it better/faster? > > Except that, since it IS a host problem, why not focus on improved detection > and debugging.... > > EG, yahoo is one of the big pushes behind it. THey could easily add > auto-debugging to their homepgae would would detect this condition and NOTIFY > the users that this will be a problem, same for google. > > This to me seems like a "cure" worse than the disease.
That is also a concern I share. It seems that have the cart before the horse, so to speak. IMHO, we need to do the following (and there's no reason they cannot occur rapidly): 1 - Develop a clear problem statement that outlines (1) how "broken" users are defined and (2) what effects this "brokenness" has on these end users (or other parts of the Internet). 2 - Describe all the various methods and tactics by which end user "brokenness" can be detected. This may include website-based detection, DNS-query-based detection, or a variety of other methods. 3 - Then, after we have agreement on Problem Definition and Problem Detection, we can measure the problem to understand what the scope or scale of the problem is. 4 - After we understand Problem Definition, Problem Detection, and Problem Scope, then you can arrive at possible solutions. Seems like in this case we sort of *started* here, which concerns me and I think we need to be careful that discussion thus far does not constrain development of a full list of Solution Options. I further believe we will need to encourage the pursuit of multiple solutions simultaneously. Lastly, just because end user software upgrades may be difficult doesn't mean we shouldn't do them and shouldn't focus just as much energy on those than other options. Jason _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
