On Dec 4, 2013, at 2:59 PM, Joe Abley <jab...@hopcount.ca> wrote: > > > On Wednesday 4 December 2013 at 14:40, Warren Kumari wrote: > >> I really like .alt -- it makes it clear that this is an alternate namespace >> type thing, mirrors the usenet alt convention, etc. >> .p2p seems less descriptive, and not all alternate things are peer to peer. > > I think it's pertinent to characterise what you mean by .alt (or .whatever). > Do you mean adding .alt to the reserved list so that it is not used? Or do > you mean it should be delegated somewhere? If so, that can of worms will need > to be opened at some point, and pandora's box of root zone management needs > to be opened.
Hmm... Good question…. <runs away> Actually I think that "both" is the right answer here, although I understand that that is not really possible. Ideally it should be marked as "Reserved, see RFC xxx" and *also* delegated to AS112. Simply reserving it so that it is not used on the big-I internet won't actually stop queries from leaking out and hitting the root. I am aware of the can of worms^W snakes, and understand that opening that can / box is not to be undertaken lightly. So, I'd be OK with .alt being "Reserved" in some RFC, and that RFC also suggesting that this be delegated to AS112. The actual action could be taken later. Yes, I fully get the irony of me saying "Don't poke the bear without reason" and then doing so. Oh well. >> Whatever the case, .<new label> could be delegated to AS112 -- if you don't >> have the special source that uses the alternate namespace this will at least >> cut down on the excess "junk" queries hitting the root. > > See above regarding the Box, but also bear in mind that we're moving AS112 > towards DNAME redirection rather than delegation. > > There was at least one study commissioned by ICANN on the prudence of > provisioning DNAME RRs in the root zone that concluded that there was no > obvious danger, but remember that any novel RRTypes in the root zone are > going to need implementation time in the systems and processes involved in > root zone management, and such changes have proven in the past to be neither > quick nor easy. Yup. See the "Reserve in an RFC. Delegate to AS112 later, in another draft, written by someone else" cowardly proposal above :-) > > There are also many non-technical communities that have demonstrated the > effectiveness of their brakes when it comes to making changes to root zone > provisioning, no matter how benign the change might seem to a technical > audience. You reckon? > > Note that I'm not commenting on any general or specific idea, just pointing > out that there are dragons every which way you look if your proposal involves > the root zone. Yup. Dragons and monsters and big hairy things with sharp, pointy teeth… W > > > Joe > > -- Militant Agnostic -- I don't know and you don't either... _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
