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

Thu Jun 9 18:41:50 UTC 2022

IF it ends up there becomes a test TLD for this, I think coordinating it
into the Public Suffix List will give a better indication of how browsers
would behave.  That said, we are incredibly pedantic about ICP-3 adherence,
or vetting via some I* org.

Otherwise, rule 1 is that we serve up a hot cup of "NOPE" for things like
this.

 I SUSPECT a test TLD could be tried, as there is precedent with the IDN
test strings (although these were technically root listed).

I am glad to accomodate (as I am able to), but we would need a memo from
OCTO, SSAC chair or some high level person at IETF or ICANN so that it
stands to public record so that it appears we are operating in a fair and
consistent manner.

  That way, I don't face massive headwinds on allowing through something
that isn't root listed.

PLUS, I don't want a thundering herd of alt-root TLD requests for inclusion
citing it as precedent.

Jothan

On Thu, Jun 9, 2022, 10:11 AM Aikman-Scalese, Anne <AAikman at lewisroca.com>
wrote:

> 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
>
> D. 520.629.4428
>
>
>
> *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>
> 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
>
> D. 520.629.4428
>
> <image003.png>
>
>
>
> *From:* NCAP-Discuss <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>
> *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>
> 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
>
> D. 520.629.4428
>
> <image003.png>
>
>
>
> *From:* NCAP-Discuss <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>
> *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.
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220609/c62534db/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 2031 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220609/c62534db/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 212 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220609/c62534db/image004-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 212 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220609/c62534db/image004-0003.png>