Team, In consideration of the fact that ICANN received at least 37 formal reports of name collisions, it seems only prudent that we establish an expert, freshly informed position on this topic. Additionally, we should ask ICANN for an assessment of the explicitly reported impacts resulting from name collisions as new gTLDs were delegated, particularly those that were apparent but not expressly reported to ICANN. To continue without any disclosure of reported operational and security impacts, or absent consideration of any such assessment by the ICANN and the ICANN community, would not seem to be in the public interest. Thoughts? Thanks Sarah From: gnso-newgtld-wg-wt4-bounces@icann.org [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Aikman-Scalese, Anne Sent: Wednesday, September 13, 2017 1:39 AM To: 'Rubens Kuhl' <rubensk@nic.br>; gnso-newgtld-wg-wt4@icann.org Subject: [EXTERNAL] Re: [Gnso-newgtld-wg-wt4] ICANN Compliance x Name Collisions Thank you Rubens. It would indeed be good to know how many back-end providers are involved in these instances of name collision. Regarding the requests for informal technical advice on the name collisions issue, I look forward to receiving copies of the full responses – hopefully all in one shot (rather than digging through e-mail archives) prior to any final formulation of a recommendation from Work Track 4. I certainly applaud the idea of name collision risk being reviewed up front before any other aspect of technical evaluation – in order to save time and money for applicants and others. I really don’t have a sense as to whether the “three categories” are appropriate or how this approach was developed. Could you please advise? Who exactly determines the category of name collision risk on a case-by-case basis? What standards do they use? Is a Technical Panel involved? Depending on the answers, and as noted on a previous call, it seems to me more formal technical advice may be needed on the proposed name collision framework (as was done in the 2012 round). I am also uncomfortable with the idea that “mitigation of name collision risk” would become a matter to be addressed individually by the registry working with ICANN staff prior to delegation. That seems very time consuming for staff and may suffer from a lack of transparency as well. (This appeared to me to be part of the current Straw Proposal.) I would favor a system which requires name collision risk to be judged according to a generally applicable Framework and which involves technical evaluation independent of the contracting party negotiation with ICANN staff prior to delegation. Ideally an independent third party would advise on a formal basis as to the appropriate name collision framework for the next round so that objective standards are established and apparent to the Community. Certainly there would be no problem with ICANN staff working to mitigate name collision incidents which continue to occur post-delegation so I agree with you there. Thank you, Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman@lrrc.com<mailto:AAikman@lrrc.com> _____________________________ Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 700 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> From: gnso-newgtld-wg-wt4-bounces@icann.org<mailto:gnso-newgtld-wg-wt4-bounces@icann.org> [mailto:gnso-newgtld-wg-wt4-bounces@icann.org] On Behalf Of Rubens Kuhl Sent: Tuesday, September 12, 2017 5:07 PM To: gnso-newgtld-wg-wt4@icann.org<mailto:gnso-newgtld-wg-wt4@icann.org> Subject: [Gnso-newgtld-wg-wt4] ICANN Compliance x Name Collisions https://www.icann.org/en/system/files/files/compliance-update-jun17-en.pdf At the end of page 3: "This quarter, the ICANN Contractual Compliance team also processed referrals from ICANN Technical Services regarding controlled interruption wildcard record violations. Approximately 45 TLDs were found to have activated names (other than nic.tld) in the DNS, while controlled interruption wildcard records continued to exist in their zone file." It seems a high number of TLDs are still having issues with the 2012-round Name Collision Framework, long after delegation. This specific data point suggests that one of the suggested modifications, having ICANN or an ICANN contractor run the process before the TLD is delegated to the approved applicant, would not only address the time-to-market problem seen by registries but also improve compliance with the framework as designed. We should note though that this report doesn't mention distribution by registry service provider; all 45 TLDs could share a single back-end for all we know. Rubens _____ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.

Em 12 de set de 2017, à(s) 21:38:000, Aikman-Scalese, Anne <AAikman@lrrc.com> escreveu:

Thank you Rubens. It would indeed be good to know how many back-end providers are involved in these instances of name collision.

Regarding the requests for informal technical advice on the name collisions issue, I look forward to receiving copies of the full responses – hopefully all in one shot (rather than digging through e-mail archives) prior to any final formulation of a recommendation from Work Track 4.

Unfortunately there isn't much substance to report... IETF DNSop WG leadership seems unsure whether it would be a topic for discussion there, and no one responded to the list in DNS-OARC or RIPE DNS WG. What was mentioned both in lists and privately was a bit of surprise that such an effort was ongoing , even from ICANN staffers, and a sense of welcoming this discussion long before instead of after the application window. So my takeaways are: (1) That it was a good move (thanks to ICANN's OCTO suggestion), but a more targeted outreach should be done when we have something more concrete. (2) That we should focus IETF DNSop discussion more towards the Specia Use TLDs theme, something they clearly see as an overlap between IETF and ICANN and are willing to address (3) That DNS-OARC or ICANN DNS Forum would be the forums and events that we should keep interacting with.

I certainly applaud the idea of name collision risk being reviewed up front before any other aspect of technical evaluation – in order to save time and money for applicants and others. I really don’t have a sense as to whether the “three categories” are appropriate or how this approach was developed. Could you please advise? Who exactly determines the category of name collision risk on a case-by-case basis? What standards do they use? Is a Technical Panel involved?

The 3 categories approach was developed based on 2012-round experience and aggregation of ideas from the community, but mostly from the 2012 framework developer, JAS Advisors. The other questions of who determines, on what would be the criteria, is exactly something that an staff feedback pointed out as still needed in WT4 work. Note that we could develop criteria or develop the criteria-making guidance, and while I don't want to preclude any of the possible outcomes, the criteria itself sounds more like implementation and the criteria-making guidance sounds more like policy, so we as WT should aim to at least provide criteria-making guidance but if we can get to criteria, great.

Depending on the answers, and as noted on a previous call, it seems to me more formal technical advice may be needed on the proposed name collision framework (as was done in the 2012 round). I am also uncomfortable with the idea that “mitigation of name collision risk” would become a matter to be addressed individually by the registry working with ICANN staff prior to delegation. That seems very time consuming for staff and may suffer from a lack of transparency as well. (This appeared to me to be part of the current Straw Proposal.)

I would favor a system which requires name collision risk to be judged according to a generally applicable Framework and which involves technical evaluation independent of the contracting party negotiation with ICANN staff prior to delegation. Ideally an independent third party would advise on a formal basis as to the appropriate name collision framework for the next round so that objective standards are established and apparent to the Community. Certainly there would be no problem with ICANN staff working to mitigate name collision incidents which continue to occur post-delegation so I agree with you there.

Do you mean in the cases of aggravated risk ? Because for standard risk strings, what is currently foreseen is ICANN doing the controlled interruption on its own even before a registry gets a contract for the applied-for string... ICANN staff wouldn't even know at that point, at least for contention sets, which one of the applicants will actually become a registry... Rubens