Dear colleagues, Not to pick on Mark, but I have the sinking feeling that this discussion is a good example of why some operators think the IETF doesn't understand operational problems.
On Sat, Apr 05, 2008 at 10:07:54AM +1100, Mark Andrews wrote: > I said COPY. I did not say "THEIR OWN ROOT". A copy needs to > be kept up to date or it ceases to be a copy. It becomes a > snapshot. The point of this exercise, as far as I recall, was to solve the problem that "junk" queries go to the roots -- things like .local and .txt. Now, if I'm a mom & pop ISP being crunched by large carriers (who are using every trick in the book to drive me out of business) and expensive customer calls, I'm going to do whatever will make my customers happy, right now, and get them off the phone. So I'm going to say, "What's the harm in adding the entries for .local into this instance that I'm already running for other TLDs anyway?" It will make one failure mode go away for the customer, and it will reduce my load on my systems. By telling everyone to run their own authoritative copy for the top level, you are effectively telling them that they can add _anything_ at the top level. After all, you just told them to respond authoritatively at that level. And since they have the authority server at that level, who's to tell them that they shouldn't add the extra entries? It solves their operational problem, makes things easy for their customers, and (since the point of this effort is to stop leaking queries) doesn't harm anyone else. Right? The harm, of course, will come when people change ISPs and things don't work quite the same; or when they run into surprises by carrying their laptops into another network with a disjunct set of these non-IANA-root entries. This scheme more or less guarantees the end of the pretense of a unified namespace (which is related, I think, to the arguments elsewhere in this thread that such has already happened anyway). A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
