[NCAP-Discuss] Current Sub Pro Draft Final Report Language

Wed Jul 1 20:27:13 UTC 2020

Dear NCAP - DG Members:
Per our call today, see the Sub Pro draft Final Report text below.  This text has been through our "can't live with" exercise and should now be final for purposes of being issued for public comment.  In forwarding this text, I am not at all trying to dictate any terms of the NCAP - DG scope or timing of its work - rather just looking to cooperate as suggested by the Board in its public comment on the Sub Pro Initial Report.

Please note that the Sub Pro WG report says that unless and until the ICANN Board adopts a new framework for name collision risk assessment and mitigation, controlled interruption should apply as it did in the 2012 round.  That language is highlighted below.  (This is Leadership's assessment of the majority view.)  There is also some discussion/reference to the NCAP work and expression of concern that this work will not be ready in time for the next round.

As I understand our Sub Pro timeline, this draft Final Report is likely to go out for public comment later this month.
Anne
>From the Sub Pro Draft Final Report:
2.7.8 Name Collisions

a. Recommendations and/or implementation guidelines

Affirmation xx (Rationale 1): The Working Group affirms Recommendation 4 of the 2007 policy, which states: "Strings must not cause any technical instability."

Recommendation xx (Rationale 2): 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.

Affirmation xx (Rationale 3): The Working Group affirms continued use of the New gTLD Collision Occurrence Management framework unless and until the ICANN Board adopts a new mitigation framework. This includes not changing the controlled interruption duration and the required readiness for human-life threatening conditions for currently delegated gTLDs and future new gTLDs.

Implementation Guidance xx (Rationale 4): ICANN should develop a mechanism or test to determine the name collision risk for any given string. The Working Group suggests putting them into three categories: high risk, aggravated risk, and low risk. High-risk strings should not be allowed to be applied for (if possible) or delegated, and aggravated risk strings should require the inclusion of a specific name collision mitigation framework.

Implementation Guidance (Rationale 5): To the extent possible, ICANN should seek to identify high-risk strings in advance of opening the Application Submission Period, which should constitute a "Do Not Apply" list. ICANN should also seek to identify aggravated risk strings in advance of the next application window opening and whether it would, which would be expected to require a specific name collision mitigation framework. However, all applied-for strings should be subject to a DNS Stability evaluation to determine whether they represent a high, aggravated, or low risk of name collision.

[Implementation Guidance (Rationale 5): To the extent possible, all applied-for strings should be subject to a DNS Stability evaluation to determine whether they represent a high, aggravated, or low risk of name collision risk.]

Implementation Guidance xx (Rationale 4): 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.

Implementation Guidance xx (Rationale 6): If controlled interruption (CI) for a specific label (usually a 2nd-level domain) is found to cause disruption, ICANN may decide to allow CI to be disabled for that label while the disruption is fixed, provided that the minimum CI period is still applied to that label.

b. Deliberations and rationale for recommendations and/or implementation guidelines

Rationale for Affirmation xx (Rationale 1): In its deliberations the Working Group agreed that the policy goal continues to be what it was in 2007, which is that any string must not cause any technical instability. The Working Group thinks that still remains an appropriate objective, and therefore affirms Recommendation 4 from the 2007 policy.

Rationale for Recommendation xx (Rationale 2): The Working Group agreed that the recommendation that ICANN must include a mechanism to evaluate the risk of name collisions in the TLD evaluation process as well during the transition to delegation phase is still relevant, with the addition of the requirement for such a mechanism to be ready prior to the next application period. The Working Group agreed that the requirement for a mechanism would promote predictability for applicants and other parties. In response to concerns raised in comments, the Working Group agreed that it did not have to recommend what the mechanism is.

Rationale for Affirmation xx (Rationale 3): In its deliberations the Working Group noted that while there was some support for some aspects of a new mitigation strategy relating to evaluation of high and aggravated-risk strings, and disabling CI, there was considerable disagreement concerning the form of a new mitigation framework. The Working Group noted that in its Final Report, JAS Global Advisors does believe that the previous mitigation measures have worked. The Working Group noted also that no data that has been presented has shown that the previous mitigation measures haven't worked. The Working Group acknowledged that there are a number of groups that think that the launch of the next round should be dependent on the outcome of the NCAP studies, while noting that at the time of deliberation it was unclear whether any of the NCAP studies would be completed by the time subsequent gTLDs are ready to launch.

With respect to the NCAP, the Working Group reviewed the Board resolution on its creation as well as in directing ICANN org to initiate Study 1. The Working Group agreed that it is up to the ICANN community and ICANN Board of Directors to determine any dependencies between the NCAP and the next round of new gTLD applications. To gain some clarification from the ICANN Board concerning possible dependencies with the ongoing work of the NCAP, the GNSO Council sent a letter on 20 September 2019 requesting guidance from the ICANN Board of Directors concerning its views related to "dependencies, if any, between the NCAP and the ongoing policy work of the New gTLD Subsequent Procedures PDP." In its response on 1 November 2019 Cherine Chalaby, then Chairman of the ICANN Board, noted that the "Board has not sought to establish a new dependency on completion of the PDP work based on commissioning NCAP Study 1", which had not yet started at that time, but that "upon completion of Study 1, the Board can determine in consultation with the community whether additional NCAP work is necessary and, if so, which elements should be a dependency for any of the other future milestones noted in your letter." At the time of the Working Group deliberations on the public comments the GNSO Council had not yet sent its letter to the ICANN Board, but the Working Group agreed that it needed to plan for a circumstance where the NCAP work is either not completed or they choose not to go on with Study 2 or 3, or there are no new recommendations coming out of Study 1.

The Working Group notes that ICANN org, in cooperation with the NCAP Discussion Group, has since completed its Study 1, leveraging an outside consultant. The consultant who produced the Study 1 report made the following draft conclusions relating to Studies 2 and 3: "Regarding Study 2 analyzing datasets is unlikely to identify significant root causes for name collisions that have not already been identified. New causes for name collisions are far more likely to be found by investigating TLD candidates for potential delegation on a case by case basis. Regarding Study 3, the review of prior work has not identified any new mitigation strategies for name collisions to be tested. Also, controlled interruption has already proven an effective mitigation strategy. Without a compelling new mitigation strategy to consider, Study 3 does not seem to be needed at this time. All of that being said, this does not mean further study should not be conducted into name collision risks and the feasibility of potentially delegating additional domains that are likely to cause name collisions. Most notably, the Study 3 question of how to mitigate name collisions for potential delegation of the corp, home, and mail TLDs is still unresolved. However, the proposals for Studies 2 and 3, which were developed years ago, do not seem to be effective ways of achieving the intended goals."

Given that the Working Group did not agree on a new mitigation framework, the Working Group affirms continued use of the New gTLD Collision Occurrence Management framework unless and until the ICANN Board adopts a new mitigation framework.

Rationale for Implementation Guidance xx (Rationale 4): The Working Group agreed that ICANN should develop a mechanism or test to determine the name collision risk for any given string, putting them into three baskets: high risk, aggravated risk, and low risk. High-risk strings should not be allowed to be applied for (if possible) or delegated, and aggravated risk strings should require the inclusion of a specific name collision mitigation framework. Although the Working Group noted questions concerning the exact measurements that will place the TLD in a risk category, the data used to evaluate the risk, the frequency of risk assessments, and gaming via superfluous DNS requests it did not see the need to formulate guidance to address these concerns at this time.  However, the Working Group reviewed the SSAC's advice in SAC090 and agreed that Recommendation 2, part 3 may provide guidance concerning the development of a risk mechanism or test.

The Working Group acknowledges that the Name Collision Analysis Project work in relation to Board Resolutions 2017.11.02.29 - 2017.11.02.31 is ongoing and that the Board advised the Working Group in public comment on the Subsequent Procedures Initial Report to work together with the NCAP Discussion Group on the topic of name collisions. Accordingly, some Subsequent Procedures Working Group members are participating in the NCAP.

Rationale for Implementation Guidance  xx (Rationale 5): The Working Group agreed that to the extent possible, ICANN should seek to identify high-risk strings in advance of opening the application submission period, which should constitute a "Do Not Apply" list. ICANN should also seek to identify aggravated strings in advance of the next application window opening and whether it would, which would be expected to require a specific name collision mitigation framework. However, to the extent possible, all applied-for strings should be subject to a DNS Stability evaluation to determine whether they represent a high, aggravated, or low risk of name collision. The Working Group's justification for including this Implementation Guidance is that high-risk strings are likely to cause technical instability by definition, so these should not be able to be delegated. In addition, the Working Group agreed that identifying high-risk and aggravated-risk strings early in the process would promote predictability for applicants and other parties to the extent possible.

Rationale for Implementation Guidance xx (Rationale 4): The Working Group agreed that 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. The Working Group reviewed the SSAC's advice in SAC090 and agreed that Recommendation 2, part 3 may provide guidance concerning the development of criteria and a test.

The Working Group acknowledges that the Name Collision Analysis Project work in relation to Board Resolutions 2017.11.02.29 - 2017.11.02.31 is ongoing and that the Board advised the Working Group in public comment on the Subsequent Procedures Initial Report to work together with the NCAP Discussion Group on the topic of name collisions. Accordingly, some Subsequent Procedures Working Group members are participating in the NCAP.

Rationale for Implementation Guidance xx (Rationale 6): The Working Group agreed that if CI for a specific label is found to cause disruption, ICANN may decide to disable CI for that label while the disruption is fixed, provided that the minimum CI period is still applied to that string.  The Working Group noted that this recommendation is one on which the Working Group's Work Track 4 reached consensus. The Working Group agreed that there was support to include this recommendation as Implementation Guidance.

c. New issues raised in deliberations since publication of the Initial Report, if applicable.

In its deliberations, the Working Group discussed those comments to the Initial Report, including from the ALAC, that said that the NCAP work should be completed before any new round begins.  Subsequent to those deliberations and to gain some clarification from the ICANN Board concerning possible dependencies with the ongoing work of the NCAP, the GNSO Council sent a letter on 20 September 2019 requesting guidance from the ICANN Board of Directors concerning its views related to "dependencies, if any, between the NCAP and the ongoing policy work of the New gTLD Subsequent Procedures PDP."  In its response on 01 November 2019 Cherine Chalaby, then Chairman of the ICANN Board, noted that the "Board has not sought to establish a new dependency on completion of the PDP work based on commissioning NCAP Study 1", (which had not yet started at that time), but that "upon completion of Study 1, the Board can determine in consultation with the community whether additional NCAP work is necessary and, if so, which elements should be a dependency for any of the other future milestones noted in your letter."

Since its deliberations on the comments to the Initial Report, the Working Group has continued to discuss the issue of whether the completion of the NCAP studies is a contingency for the Working Group to complete its work. In reviewing the NCAP's work as well as the Board's response to the GNSO Council, the Working Group believes that the completion of the NCAP's studies and SSAC work are not necessarily a contingency for the PDP Working Group to complete its work, but as the Board notes, "the Board can determine in consultation with the community whether additional NCAP work is necessary and, if so, which elements should be a dependency for any of the other future milestones".

d. Dependencies/relationships with other areas of this report or external efforts

  *   The recommendations in this section seek to promote 2.7.6 Security and Stability of the DNS, a topic this is addressed more broadly in section xx..

Anne E. Aikman-Scalese

Of Counsel

520.629.4428 office

520.879.4725 fax

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

_____________________________

[cid:image006.png at 01D64FAB.53C500F0]

Lewis Roca Rothgerber Christie LLP

One South Church Avenue, Suite 2000

Tucson, Arizona 85701-1611

lrrc.com<http://lrrc.com/>

[cid:image007.jpg at 01D64FAB.53C500F0]

Because what matters

to you, matters to us.(tm)

________________________________

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: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200701/2e366c24/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 70 bytes
Desc: image001.gif
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200701/2e366c24/image001-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 6528 bytes
Desc: image006.png
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200701/2e366c24/image006-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.jpg
Type: image/jpeg
Size: 2461 bytes
Desc: image007.jpg
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200701/2e366c24/image007-0001.jpg>