[NCAP-Discuss] Current Status of the NCAP Project

Wed Nov 9 19:13:42 UTC 2022

Rubens,
Time and again you misrepresent what I am saying.  I am saying that agreeing on and defining a written framework is critical to actually getting to Board approval.   The reason is that there was in fact no formal adoption of written procedures during the 2012 round for identifying high risk strings until after the high risk strings had already been identified by JAS/Interisle and after some strings were given the option to launch based on Alternate Path to Delegation.

The language of the Sub Pro first Recommendation is “MUST” and the fact is that in the 2012 round, the system for identifying high risk strings was never, as you put it, “defined”.    I’m going to paste that Recommendation language again below.

Recommendation 29.1: ICANN must 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

At the very least, THERE IS A GAP IN THE FALLBACK POSITION OF USING THE NEW GTLD COLLISION OCCURRENCE MANAGEMENT FRAMEWORK because it does not provide a concrete method for evaluating risk in relation to newly-applied for strings.    What are the specific standards in that 2012 methodology that result in a string being identified as “high risk” and  not approved for going forward?  Will all of you who advocate the fallback position please provide comments to the current draft (as has been requested numerous times by leadership) or else make a finite written counterproposal in a form that the Board could actually adopt?

The fallback reference to the “New gTLD Collision Occurrence Management Framework” is in fact inadequate because it does not specify any method whatsoever for identifying high risk strings.  (Incidentally it also states that .corp, .home, and .mail cannot move forward.)  There is no way the Board can actually act on this fallback without it being further “defined”.

Furthermore, the following Implementation Guidance appears BELOW the endorsement of the fallback position in the Sub Pro Final Report.   This Implementation Guidance should not be ignored and the GAC has called it out.

Implementation Guidance 29.4: To the extent possible, all applied-for strings
should be subject to a DNS Stability evaluation to determine whether they
represent a name collision risk.

Implementation Guidance 29.5: The ICANN community should develop name
collision risk criteria and a test to provide information to an applicant for any
given string after the application window closes so that the applicant can
determine if they should move forward with evaluation.

We all understand that you and others want to make the NCAP project “go away”.  (In fact, at one point, the GNSO Council was asked by Sub Pro Leadership to write a letter to the Board to try to kill it.   Council wisely declined to do so.)

Rather than saying “we object, we object”, it would be great if you could propose some concrete written guidelines for testing new proposed strings, specifying who will run the test,  and putting all that into a written proposal that the Board could actually act upon when it receives the requested input from the SSAC in response to its questions.  In this regard, please do not continue to ignore GAC and ALAC comments on this topic as if those have no effect on the Board, e.g.

From the ALAC:

6. Name Collision
• The ALAC supports the ICANN Board’s continued keen interest in the outcome of the SSAC’s
Name Collision Analysis Project (NCAP) and its impact on Subsequent Procedures and the
future rounds of the New gTLD Program.
• We join the SSAC in recommending that the ICANN Board, prior to authorizing the addition of
new gTLDs to the root zone, receive and consider the results of the NCAP, pursuant to Board
Resolution 2017.11.02.30.
• Further, we strongly advocate for the recommendations of SSAC resulting from the NCAP
Studies 2 and 3 (as approved by the ICANN Board) to be implemented prior to the launch of
the next round of applications for New gTLDs; or in the alternative, that delegation of any
applied-for strings which pose a risk of name collisions be withheld until the NCAP studies are
completed and recommendations are addressed in implementation, retrospectively for the next
round.

Thank you,
Anne

Anne E. Aikman-Scalese

Of Counsel

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

D. 520.629.4428

[cid:image002.png at 01D8F42D.3F799D30]

From: NCAP-Discuss <ncap-discuss-bounces at icann.org> On Behalf Of Rubens Kuhl via NCAP-Discuss
Sent: Tuesday, November 8, 2022 7:18 PM
To: NCAP Discussion Group <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] Current Status of the NCAP Project

Sub Pro Recommendation 1 says ICANN MUST develop a Name Collision Risk Assessment methodology prior to the next round.  “Let’s do what we did in 2012” does not describe a methodology and can’t really be effectively adopted by the Board, particularly not when standing GAC and ALAC advice is asking for more.

Anne,

Time and time again you misrepresent what SubPro Rec 1 said. There is nothing there preventing the same framework used in 2012 to be used in future rounds if Org so sees fit.
The only thing that recommendation does not allow is to define the framework afterwards, which was what happened in 2012.

The 2012 framework checks all the boxes of the SubPro recommendations on the topic, so if you prefer new-magic-fancy-framework in lieu of the 2012 one is something you can do, but misrepresenting that the 2012 is a viable option is not.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20221109/3cc1b14a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 224 bytes
Desc: image001.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20221109/3cc1b14a/image001-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2031 bytes
Desc: image002.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20221109/3cc1b14a/image002-0001.png>