Joe, I was in the middle of a long, extremely eloquent point-by-point rebuttal when I realized it was pointless: we're approaching the draft from completely different directions and I strongly doubt anything I might say might change your mind.
However, I did want to focus on one point. To quote a bit of your message: > There's no obvious operational benefit to root server operators [...] I do not believe the draft is about improving life for the root server operators. That might be a side benefit in that it would reduce the noise root server operators have to wade through, but it isn't the primary goal. I see the primary benefit being a way of addressing what I consider a fundamental flaw in the historical DNS operational architecture. Specifically, the DNS operational infrastructure is a bit like 6to4: it relies on the kindness of strangers who may or may not have any incentive to ensure the service is provided in the best possible way. This draft attempts to document a way in which organizations can choose to be the masters of their own fate when it comes to root name service instead of relying on a set of 12 (or 11, depending on your point of view) volunteers who upgrade or not, buy capacity or not, deploy IPv6 or not, deploy anycast or not, etc., based on their own internal rationales and justifications. Further, it is opt-in: if you're perfectly happy with the existing system, no one is forcing you, as a resolver operator, to slave the root zone. In my mind, this is a much more scalable, resilient, robust, and even rational (from the perspective of the operation of critical infrastructure) system that the current root service architecture. Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
