I’d add that ICANN has no mechanism for specifying how a top level domain should be handled other than the simple delegation/non-delegation binary (it can specify how certain sub-domains should be handled as a condition of delegation). It cannot, as the .onion proposal does, specify that the domain be handled differently by resolvers without delegation. This alone justifies an IETF mechanism that goes outside ICANNs processes.
David > On 1 Sep 2015, at 10:13 am, John Levine <jo...@taugh.com> wrote: > >> It seems to me that ICANN could well decide that certain names are >> just not going to be delegated in the DNS root, and could do that on >> the understanding that it is because of existing deployments. There >> is an argument to ne made that the "corp" and "mail" examples are of >> this sort, although John Levine might point out that they haven't made >> this permanent. > > Well, since I've been dragged in here ... > > The ICANN new TLD process had a step that looked at DNS Stability (see > pages 2-11 - 2-15 of the applicant guidebook), but the text in the AGB > makes it clear that the issues they were contemplating were things > like IDN names that aren't valid U-labels. The issue of collisions > with existing use wasn't seriously addressed until Verisign made an > issue about it, notably with their March 2014 name collision workshop. > > It is quite true that while ICANN has said they're not planning to > delegate .corp, .mail, and .home, they still have several million > dollars of unrefunded application fees for those names. It is not > necessarily bad that the names aren't reserved forever -- for example, > a lot of the informal use of .corp depended on CAs signing .corp > names, which they don't do any more. It's plausible the enough of the > existing .corp names will eventually move elsewhere that it'd be OK to > delegate it. The problem is that there is no process, inside or > outside of ICANN, to make that decision. > > Applicants call up ICANN every day and scream about how much money > they're losing because they can't implement their business plans. If > they hear there's collision problems, they say fine, whatever, just > tell us what we have to do to make the collisions go away so we can > start collecting rent. This has led to some rather odd things. For > some TLDs, there's a long list of reserved names that look like and > probably are noise, apparently ones that showed up in one of the DITL > snapshots. Or now there's "controlled interruption", wildcards > installed in a TLD for a few months with 127.53.53.53 A records they > hope people will see in their logs. That's a perfectly reasonable > experiment, but by itself it's not going to tell anyone whether it's > safe to delegate domains with a lot of prior use. I don't see ICANN > being opposed to sensible collision management, but I don't see > how to get from here to there. > > So anyway, I agreee with everyone else that .onion is odd enough that > it's worth reserving in an RFC, but beyond that, we're in the > uncharted territory between the IETF and ICANN. > > R's, > John > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
