<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div><div>Dear all,</div><div><br></div><div>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.</div><div><div><br></div>Cheers</div></div><div>Mary</div><div><br></div><div><div><div><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri">Mary Wong</font></font></div><div><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri">Senior Policy Director</font></font></div><div><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri">Internet Corporation for Assigned Names & Numbers (ICANN)</font></font></div><div><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri">Telephone: +1 603 574 4889</font></font></div><div><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" face="Calibri">Email: mary.wong@icann.org</font></font></div><div><br></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> <<a href="mailto:owner-council@gnso.icann.org">owner-council@gnso.icann.org</a>> on behalf of David Cake <<a href="mailto:dave@difference.com.au">dave@difference.com.au</a>><br><span style="font-weight:bold">Date: </span> Tuesday, July 21, 2015 at 02:09<br><span style="font-weight:bold">To: </span> <<a href="mailto:avri@acm.org">avri@acm.org</a>><br><span style="font-weight:bold">Cc: </span> "<<a href="mailto:council@gnso.icann.org">council@gnso.icann.org</a>>" <<a href="mailto:council@gnso.icann.org">council@gnso.icann.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [council] Fwd: Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt><br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">For background - <div class="">- 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. </div><div class="">- the Special Use Names list is maintained by IANA, like most IETF lists of important things Eg <a href="https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml" class="">https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml</a> 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). </div><div class="">- 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. </div><div class="">- 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 </div><div class="">- 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.</div><div class="">- 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. </div><div class="">- 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. </div><div class="">- 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?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class="">David</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 21 Jul 2015, at 7:08 am, Avri Doria <<a href="mailto:avri@acm.org" class="">avri@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="">Hi,<br class=""><br class="">The following message is a hint at some of the discussions that have<br class="">been going on in the IETF for some time now. These relate to RF6761<br class=""><<a href="https://www.rfc-editor.org/rfc/rfc6761.txt" class="">https://www.rfc-editor.org/rfc/rfc6761.txt</a>> on Special Use domain names.<br class=""><br class="">At some point we may want to discuss this issue. Should not let the<br class="">IETF working group have all the fun. We need to remember that because<br class="">the IETF determines the protocols and their reserved names, they<br class="">determine which names are available to ICANN.<br class=""><br class="">One example of a special use name is currently in last call:<br class="">draft-ietf-dnsop-onion-tld-00.txt which is in last call until 11 August:<br class=""><<a href="https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/" class="">https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/</a>><br class=""><br class="">We may decide that this is ok. Part of me think it may be. But in any<br class="">case, we should probably not let this slip my without a discussion.<br class="">RFC6761 slipped by without out noticing it. I think I mentioned it at<br class="">the time to various folks but the GNSO did not discuss it in any way.<br class="">Perhaps it is time we had some discussions on the issue and perhaps want<br class="">to send in a comment as part of the last call.<br class=""><br class="">avri<br class=""><br class=""><br class=""><br class="">-------- Forwarded Message --------<br class="">Subject: Re: the names that aren't DNS names problem, was Last Call:<br class=""><draft-ietf-dnsop-onion-tld-00.txt><br class="">Date: 20 Jul 2015 19:22:19 -0000<br class="">From: John Levine <<a href="mailto:johnl@taugh.com" class="">johnl@taugh.com</a>><br class="">To: <a href="mailto:ietf@ietf.org" class="">ietf@ietf.org</a><br class=""><br class=""><br class="">Now that you and Andrew have pointed it out, and after today's dnsop<br class="">session, I agree that the trickle of not-DNS domain names is likely<br class="">only to become larger, and we need a better way to deal with it than a<br class="">two-month all-IETF debate per name.<br class=""><br class=""><blockquote type="cite" class="">why can't we take the Special Names<br class="">problem to them, say "look, we understand that these names look<br class="">like names in the public DNS root and that confusion that would<br class="">have bad effects is a real risk, how about you devise a<br class="">procedure for dealing with them that recognizes the importance<br class="">of existing deployment and use and considers the low likelihood<br class="">that people who are using these names will stop because you tell<br class="">them too. Clearly the procedure you use for new gTLD<br class="">applications won't work. And, because some of these names won't<br class="">wait, if you can't get that procedure together immediately, we'd<br class="">be willing to let you delegate things to us on some reasonable<br class="">basis until you do."<br class=""></blockquote><br class="">That is an excellent question, and I suppose it couldn't hurt to ask.<br class="">But I have little confidence that ICANN in anything like its current<br class="">form, where it is dominated by people who want to collect rent on<br class="">every imaginable TLD, would come up with an answer any better than let<br class="">them pay $185K and take their chances.<br class=""><br class="">As a second level issue, we might want to consider whether it's<br class="">worth standardizing DNS escapes which are now typically done by<br class="">a hacked version of a SOCKS server or DNS resolver.<br class=""><br class="">R's,<br class="">John<br class=""><br class=""><br class=""><br class=""><br class="">---<br class="">This email has been checked for viruses by Avast antivirus software.<br class=""><a href="https://www.avast.com/antivirus" class="">https://www.avast.com/antivirus</a><br class=""><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></span></body></html>