[NCAP-Discuss] [Ext] Re: An Approach to Measuring Name Collisions Using Online Advertisement

Aikman-Scalese, Anne AAikman at lewisroca.com
Thu Jun 9 17:11:44 UTC 2022


Thanks Rubens.  I could be wrong, but I don’t think the tests employed by Interisle and JAS that you and Jeff refer to were codified as formal ICANN evaluation procedures in the 2014 Name Collision Occurrence Management Framework.  Here it is:

https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf

Anne

Anne E. Aikman-Scalese

Of Counsel



AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>

D. 520.629.4428

[cid:image003.png at 01D87BE9.50DC7050]



From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of Rubens Kuhl via NCAP-Discuss
Sent: Thursday, June 9, 2022 9:23 AM
To: NCAP Discussion Group <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] [Ext] Re: An Approach to Measuring Name Collisions Using Online Advertisement


Anne,

The 2012 NCF is much more than just the 90-controlled interruption. It involved a risk evaluation of all applied for strings, which is detailed in the Interisle and JAS reports. Saying they are not risk assessments is strongly wrong.


Rubens




On 9 Jun 2022, at 13:20, Aikman-Scalese, Anne <AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>> wrote:

The language is clear “MUST have ready a mechanism to EVALUATE THE RISK” (emphasis mine) and it needs to operate at two stages:  (1) during the evaluation of the application and (2) during the transition to delegation.

This is not a description of legacy 90-day controlled interruption.  It does fit the description of Passive Collision Assessment and Active Collision Assessment as described in the workflow.  Jeff Schmidt’s comments about applying the system (by a third party test or otherwise) in the next round are helpful.
Anne

Anne E. Aikman-Scalese

Of Counsel

<image004.png>

AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>

D. 520.629.4428

<image003.png>



From: NCAP-Discuss <ncap-discuss-bounces at icann.org<mailto:ncap-discuss-bounces at icann.org>> On Behalf Of Rubens Kuhl via NCAP-Discuss
Sent: Thursday, June 9, 2022 9:13 AM
To: NCAP Discussion Group <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>>
Subject: Re: [NCAP-Discuss] [Ext] Re: An Approach to Measuring Name Collisions Using Online Advertisement


Anne,

Must have is not must develop. It means either develop a new one or use one ICANN already has, like the one used in 2012. And there is nothing in the recommendation to say what/should be the solution, or when passive or active collision assessments fits in the timeline.


The only thing that ICANN can't is do it later than the submission period, which unfortunately was the case in 2012.



Rubens




On 9 Jun 2022, at 13:04, Aikman-Scalese, Anne <AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>> wrote:

Thanks Rubens.  I’ll defer to the Co-Chairs to answer the first question re .mail.  Regarding the Sub Pro Recommendation that contains a MUST, please see below exact language:

Recommendation 29.1: ICANN must (emphasis mine) have ready prior to the opening of the Application Submission Period a mechanism to evaluate the risk of name collisions in the New gTLD evaluation process as well as during the transition to delegation phase.

With respect to the above requirement, I think Passive Collision Assessment correlates to the “evaluation process” and Active Collision Assessment correlates to the “transition to delegation phase”.

Anne

Anne E. Aikman-Scalese

Of Counsel

<image004.png>

AAikman at lewisroca.com<mailto:AAikman at lewisroca.com>

D. 520.629.4428

<image003.png>



From: NCAP-Discuss <ncap-discuss-bounces at icann.org<mailto:ncap-discuss-bounces at icann.org>> On Behalf Of Rubens Kuhl via NCAP-Discuss
Sent: Wednesday, June 8, 2022 5:54 PM
To: NCAP Discussion Group <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>>
Subject: Re: [NCAP-Discuss] [Ext] Re: An Approach to Measuring Name Collisions Using Online Advertisement



In my opinion, the problem we are solving is that the risk assessment used in the 2012 round was not systematic.  Perhaps the best evidence of this is that strings which arguably carry more collision risk than .mail were delegated and .mail was not.

Which strings do you believe had more collision risk than .mail and were delegated ? .mail was unique due to dotless collisions that I don't saw happening at any other 2012 applied string, so I don't see which strings it could be compared to, since all others were collisions of host.TLD or host.something.TLD type, not just "TLD".






What is different now is we are called upon to develop a systematic process for risk assessment.   That comes with a “MUST” in the Sub Pro Final Report Recommendations.  If you want the Board to lockup and defer going forward on the next round, your approach makes sense.  If you want the next round to move forward, there needs to be consistency between the answers to the  questions the Board put to the SSAC and the “MUST” part of the Sub Pro Recommendations.

Which part of the SubPro report do you believe carries a MUST in that direction ? I don't see any, only SHOULDs and COULDs.


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.




________________________________

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.


________________________________

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220609/4bfe9f3a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2031 bytes
Desc: image003.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220609/4bfe9f3a/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 212 bytes
Desc: image004.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220609/4bfe9f3a/image004-0001.png>


More information about the NCAP-Discuss mailing list