[Gnso-newgtld-wg-wt4] ICANN Compliance x Name Collisions

[Rubens Kuhl]

> Em 12 de set de 2017, à(s) 21:38:000, Aikman-Scalese, Anne <AAikman at 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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170914/c5f87f4c/attachment.html>