[NCAP-Discuss] Name collision timeline

Wed Aug 10 22:10:18 UTC 2022

Hi Jeff,
Thanks for the robust discussion in today’s NCAP meeting.  I would like to clarify the reasons I keep bringing up the recommendations and implementation guidance in the Sub Pro Final Report:

1.       The Sub Pro Working Group knew that the NCAP work was afoot and agreed to defer to outcomes from the NCAP process if adopted by the Board.  Whether or not the Recommendation that will come from the SSAC satisfies a “cost/benefit” analysis is ultimately up to the Board.

2.       There is standing GAC formal public comment on the Sub Pro Final Report in which Name Collisions are specifically called out and even certain Implementation Guidance items  are specifically mentioned to be of importance to the GAC.   Every time there is a conflict between GAC Advice and anything coming out of the GNSO, the Board punts it back to the Community.  This is what we want to avoid because it just delays launch of the next application window.  This is what I mean when I say that different arms of ICANN need to take into account what is going on elsewhere in the community in order to avoid the increasing “backlog” and “bottleneck” that happens at the Board level because the Board insists on not making policy.  (Put another way, when will we “kids” ever learn that our differences have to be resolved before we get to the Board?)  GAC formal comment to the Board on Name Collisions is pasted below for ease of reference.  (Anyone who thinks this is not going to result in GAC Advice is, in my opinion, engaging in wishful thinking.)

Name Collisions: Topic 29 in Final Report
The GAC highlights the importance, also expressed by ALAC in its Advice to the Board, of
ensuring an effective framework for measuring and tackling name collision in further rounds of
new gTLDs, taking into account the work on name collisions carried out so far by the Name
Collision Analysis Project (NCAP). The GAC draws the ICANN Board’s attention to the SSR2
recommendation 17 and supports the proposed setting of a framework to characterize the
nature and frequency of name collisions and resulting concerns thereby allowing the
appropriate handling of sensitive data and security threats. The ICANN community should
develop a clear policy for avoiding and handling new gTLD-related name collisions. The GAC
therefore calls upon the Board to take due consideration of the Final report’s implementation
guidelines 29 (and 29.3 and 29.4 in particular).

3.       The cost-benefit analysis you mention is worth noting as an aspect that must be weighed by Board, but I think the DG does not know the costs and I think the DG does not yet know the benefits of any proposed mitigation plans.  I am not sure on what basis you have concluded that the cost exceeds the benefit when the risk must be evaluated on a string-by-string basis.  (As you have mentioned, there are “Black Swans” out there and we know that JAS recommended against delegating .corp, .home, and  later added .mail. )  There is apparently some data showing that .mail may not be a “Black Swan” but I think you still think it is.  As you point out, however, this is the job of a properly constituted Technical Review Team (TRT) composed of experts.

4.       The Timeline indicates there are “Off-Ramps” that are very important to the process and the cost/benefit analysis you have invoked. For example, Off Ramp #1 is when the Applicant does its own assessment and may determine that the name collision risk will cause too many problems and is too expensive to mitigate.  Supposedly the Applicant can refer to published ICANN lists and will have other tools available to make this determination.  The Study 2 Report needs to state what the known tools are and where to find them.

5.       At OffRamp #2, the TRT identifies “Black Swans” (High Risk Strings) and presents those to the Applicant and to the Board.   (I would suggest that in the description of this Off-Ramp, the Black Swan not be presented to the Board unless and until the Applicant states that it wants to pursue the string rather than withdraw with a refund.)  I understood you to be in agreement with this process as it resembles the work that was done by JAS in the 2012 round and would benefit the Applicant and the Board greatly to know this well before further steps are taken which would involve greater costs, e.g. string contention processes.  So the net result is there is a cost benefit to the Applicant to knowing the collision risk up front.  That is more cost- effective than the process that ensued in 2012.

6.       I think your biggest objection comes in at Off Ramp #3 which occurs after Passive Collision Assessment.  It’s important to note that one of the Sub Pro Implementation Recommendations that was emphasized by the GAC involves giving Applicants a decision point related to the risk of name collisions that allows the Applicant the ability to make a decision to proceed or withdraw the application and get a refund.  Again, I think the timeline needs to clarify this in writing and I think OffRamp #3 is another one of those decision points.  Again, there is a benefit to the Applicant in knowing whether or not to proceed with an application and in the case of string contention, there is definitely a cost benefit to the community if some applicants drop out at that point in time because they don’t want to deal with name collision risk mitigation.  If only one Applicant remains, there is no longer a need to determine string contention.

7.       You believe not all strings should go into Active Collision Assessment, that this is actually a “honeypot” and that there are various reasons not to do that.  Jim believes otherwise.  I don’t know the answer but have asked whether there might be certain strings that could pass through Passive Collision Assessment, be found to be lower in risk and proceed directly to a default “notification” process to the end user.  In this regard, I refer the DG to the Board questions on how the end user is potentially impacted/harmed by name collisions.

8.        Jim firmly believes that ACA is required for every string.   We know how Jim feels and how you feel but we don’t know how the rest of the DG views this issue or why.  It will be important to discuss this further when we see a revised timeline with Off-Ramps #1 through #4 laid out in text.

9.       Re Study 3, I don’t know how the Board can proceed to authorize a next round without mitigation/remediation tools being developed.  You say because Sub Pro specifies a “default” position and I say it won’t fly when GAC Advice differs or will differ as shown via the GAC’s formal comment on Name Collisions detailed above.  As you know, the ByLaws provide that the Board cannot override GAC Consensus Advice without a 60% vote so that is why items get thrown back into an EPDP or a GNSO Guidance Process.   Like it or not, name collision risk is also a Consumer Trust and Confidence issue and the GAC and the ALAC are particularly concerned about the effects on end users.  (The GAC comment references the ALAC formal comment on the Sub Pro Final Report.)   The DG should not take the “ostrich” approach to how this topic is being handled in the rest of the ICANN community.

All of the above is why I think we need a more fully  flushed out timeline with labelled options for each Off-Ramp before it is determined where we do and do not have consensus in the DG.

Anne

Anne E. Aikman-Scalese

Of Counsel

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

D. 520.629.4428

[cid:image003.png at 01D8ACC4.F8F5DEA0]

From: NCAP-Discuss <ncap-discuss-bounces at icann.org<mailto:ncap-discuss-bounces at icann.org>> On Behalf Of Jeff Schmidt via NCAP-Discuss
Sent: Tuesday, August 2, 2022 9:58 AM
To: ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] Name collision timeline

[EXTERNAL]
________________________________
This diagram implies that all steps are done for all strings in sequence. My understanding from the team call 2 weeks ago is that if and how the TRT used the arrows in their quiver would be left to their expert discretion and applied as-needed on a string-by-string basis. This chart over-specifies their work, unnecessarily. And as discussed we all agree that all steps will be unnecessary for all but a very few (or zero) identified Black Swans.

The flow should be:

Application Submitted
Name Collision Analysis by TRT
Fork in the road:
                TRT identifies potential Black Swan: More technical research, offramps, honeypots, *CA, etc
                (default) passes the check and proceeds

Additional thoughts:

Contention Sets can be safely ignored by the TRT, unless the identified string is a Black Swan. Then the “who” and compensating controls (applicant’s specific use case) may become an issue. For example, a theoretical application from Microsoft for .corp should be viewed differently than someone wanting to use .corp as a generic. These will need to be worked on a case-by-case basis as they are highly situation dependent.

The TRT should do their work in batch after strings have been released publicly. This will somewhat mitigate risks of gaming and maintain an even field for applicants. The 2012 round contained a “DNS Stability Review” – which was essentially a check for technical Black Swans. The DNS Stability Review was performed by independent technical experts (in 2012 ICANN contracted with Interisle to perform this function) (AGB 2.2.1.3, p. 62). No reason not to use the same approach in future rounds and simply augment guidance provided to the contractor for collisions. No need to make this more complicated.

Jeff

From: NCAP-Discuss <ncap-discuss-bounces at icann.org<mailto:ncap-discuss-bounces at icann.org>> On Behalf Of Thomas, Matthew via NCAP-Discuss
Sent: Tuesday, August 2, 2022 7:41 AM
To: ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>
Subject: [NCAP-Discuss] Name collision timeline

NCAP DG,

Attached is a draft timeline of the name collision workflow.  We think it would be useful for the DG to review this and to discuss some questions that have been identified during writing team sessions.

I would expect us to have conversations around the duration of each of these events in the workflow.  Also to discuss where things like contention sets are dealt with.  What happens if another application is filed for the same string while a string is already in the name collision process?  What happens if an applicant pulls out while in the middle of this process?  What actions are being made/taken and when in the RSS (regarding delegations/removals)? How does all of this fit in a First Come First Serve model, a batch model, or a round conducted like 2012? Do our recommendations change at all in different models? Do certain models present more risk for gaming/manipulation? And finally – we should examine in more detail what the “Off-ramps” entail.

Talk to you all tomorrow.

Best,

Matt Thomas

________________________________

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/20220810/3cc01682/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/20220810/3cc01682/image003-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 183 bytes
Desc: image004.png
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20220810/3cc01682/image004-0001.png>