Re: [council] Fwd: Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>
Dear all, If time permits Avri or David may wish to bring up the topic under AOB during the Council call this Thursday. As the last call deadline is 11 August, however, which will be prior to the next Council meeting, any action that the Council might consider appropriate will likely need to be finalized via the mailing list. Cheers Mary Mary Wong Senior Policy Director Internet Corporation for Assigned Names & Numbers (ICANN) Telephone: +1 603 574 4889 Email: mary.wong@xxxxxxxxx From: <owner-council@xxxxxxxxxxxxxx> on behalf of David Cake <dave@xxxxxxxxxxxxxxxxx> Date: Tuesday, July 21, 2015 at 02:09 To: <avri@xxxxxxx> Cc: "<council@xxxxxxxxxxxxxx>" <council@xxxxxxxxxxxxxx> Subject: Re: [council] Fwd: Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt> > For background - > - the board has been aware of the RFC 6761 issue for some time, obviously. > This is not that new, the RFC was finalised in early 2013. The Special Use > Names list are names that are permanently removed from ICANN delegation > because they are reserved for some special purpose. > - the Special Use Names list is maintained by IANA, like most IETF lists of > important things Eg > https://www.iana.org/assignments/special-use-domain-names/special-use-domain-n > ames.xml as you can see its pretty dull now, mostly the .arpa names > corresponding to numbers that have special purpose of their own, plus a few > sanity checks (like please don¹t delegate .localhost as a TLD). > - the one use of the RFC 6761 process that is probably fairly well known is > multicast DNS specified in RFC 6762, which uses .local, and adds it to the > Special Use Names list. This is the technology that Apple created, and > markets as Bonjour,and took to the IETF for standardisation, now more widely > known as Zeroconf. .local names are treated as DNS names in some respects, but > use an entirely different resolution process outside of what we normally think > of as the DNS (at least, it is entirely independent of the root server system > and the normal TLD system). Technically, because multicast DNS also specifies > special uses for some numbers, it also adds the corresponding .arpa names to > the reserved list. > - in particular there was a draft circulating that proposed adding a wide > range of names related to peer to peer technologies to the Special Use Names > list, including .onion for Tor, .bit for NameCoin, and several others to the > list. There was also another draft circulating that proposed adding .alt to > the Special Use Names list as permanent ?carve-out¹ from the DNS that could be > used as the top of a hierarchy for such uses e.g. so if you created your own > exciting new way of resolving names outside of the root server system, you > could use .myexcitingnewthing.alt as a place in the domain namespace secure in > the knowledge that ICANN would never delegate .alt but without having to go > through your own entire RFC process for your new exciting thing. These were > circulated in the IETF DNSOP Working Group > - the Board noted these activities (Suzanne Woolf is one of the chairs of the > working group), felt they were of interest to the ICANN community, and sent > correspondence noting that they were happening and recommending that > interested ICANN community members should join the DNSOP WG mailing list and > participate in discussion there if interested. I¹m unable to locate this > correspondence due to ICANN inexplicably awful web site search system, but I > recall it distinctly because as a result I joined the DNSOP WG mailing list > and have participated in some of the discussion there. > - the two drafts circulating did not get consensus, for a variety of reasons. > In particular, there was a general feeling that the P2P names proposal tried > to do too many things at once. > - some backers of the .onion draft felt that it was urgent (for reasons > related to certificate authorities and .onion certificates), and presented a > new draft that only asked for .onion to be added to the Special Use Names > list, and asked for it to be done relatively urgently. There has been > discussion and consensus on this within the DNSOP WG, as a result of which it > is now out for last call. There are some interesting issues here - .local is > reserved for a different method of name resolution, but ,onion specifies not > only a very different method of name resolution, but an entirely different > routing scheme. > - I personally back the .onion proposal, but I agree with Avri that the RFC > 6761 process merits some further discussion. For example, should there be some > coordination mechanism between ICANN and the IETF other than the informal one > of having ICANN people also involved in relevant IETF processes? > > I¹d be happy to lead discussion of this issue, though Avri in particular knows > far more about the broader IETF than I probably ever will. We might also > consider asking Suzanne Woolf to join us. > > Regards > > David > > >> On 21 Jul 2015, at 7:08 am, Avri Doria <avri@xxxxxxx> wrote: >> >> >> Hi, >> >> The following message is a hint at some of the discussions that have >> been going on in the IETF for some time now. These relate to RF6761 >> <https://www.rfc-editor.org/rfc/rfc6761.txt> on Special Use domain names. >> >> At some point we may want to discuss this issue. Should not let the >> IETF working group have all the fun. We need to remember that because >> the IETF determines the protocols and their reserved names, they >> determine which names are available to ICANN. >> >> One example of a special use name is currently in last call: >> draft-ietf-dnsop-onion-tld-00.txt which is in last call until 11 August: >> <https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/> >> >> We may decide that this is ok. Part of me think it may be. But in any >> case, we should probably not let this slip my without a discussion. >> RFC6761 slipped by without out noticing it. I think I mentioned it at >> the time to various folks but the GNSO did not discuss it in any way. >> Perhaps it is time we had some discussions on the issue and perhaps want >> to send in a comment as part of the last call. >> >> avri >> >> >> >> -------- Forwarded Message -------- >> Subject: Re: the names that aren't DNS names problem, was Last Call: >> <draft-ietf-dnsop-onion-tld-00.txt> >> Date: 20 Jul 2015 19:22:19 -0000 >> From: John Levine <johnl@xxxxxxxxx> >> To: ietf@xxxxxxxx >> >> >> Now that you and Andrew have pointed it out, and after today's dnsop >> session, I agree that the trickle of not-DNS domain names is likely >> only to become larger, and we need a better way to deal with it than a >> two-month all-IETF debate per name. >> >>> why can't we take the Special Names >>> problem to them, say "look, we understand that these names look >>> like names in the public DNS root and that confusion that would >>> have bad effects is a real risk, how about you devise a >>> procedure for dealing with them that recognizes the importance >>> of existing deployment and use and considers the low likelihood >>> that people who are using these names will stop because you tell >>> them too. Clearly the procedure you use for new gTLD >>> applications won't work. And, because some of these names won't >>> wait, if you can't get that procedure together immediately, we'd >>> be willing to let you delegate things to us on some reasonable >>> basis until you do." >> >> That is an excellent question, and I suppose it couldn't hurt to ask. >> But I have little confidence that ICANN in anything like its current >> form, where it is dominated by people who want to collect rent on >> every imaginable TLD, would come up with an answer any better than let >> them pay $185K and take their chances. >> >> As a second level issue, we might want to consider whether it's >> worth standardizing DNS escapes which are now typically done by >> a hacked version of a SOCKS server or DNS resolver. >> >> R's, >> John >> >> >> >> >> --- >> This email has been checked for viruses by Avast antivirus software. >> https://www.avast.com/antivirus >> > Attachment:
smime.p7s
|