The call for the New gTLD Subsequent Procedures Working Group will take place on Thursday, 30 April 2020 at 20:00 UTC for 90 minutes.
For other places see: https://tinyurl.com/s62ehqy
- Review Agenda/Updates to Statements of Interest
- Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing
a. 2.7.8 Name Collisions, page 91
Apologies: Maxim Alzoba
Notes/ Action Items
Rationale for Affirmation xx (Rationale 3):
ACTION ITEM: Change language to reference the NCAP report to ICANN Org’s report.
Implementation Guidance (Rationale 5):
ACTION ITEM: Consider whether rather than an “Do Not Apply” list this might be a recommendation for development of criteria.
- Updates to Statements of Interest: No updates provided.
2. Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing
2.7.8 Name Collisions, page 91
Update from Jim Galvin, SSAC/NCAP Co-Chair: NCAP Status
-- Matt Thomas offered apologies that he cannot join.
-- Patrik Faltstrom also offered apologies.
-- Matt Larson from ICANN OCTO is also attending.
-- Trying to gather up everything that we would have to work with on Name Collisions since the 2012 round.
-- .corp, .home, and .mail on hold.
-- Controlled interruption procedure and collect data.
-- Project became an OCTO project.
-- .corp, .home. and .mail are not in scope for SubPro PDP WG.
-- Study 1 offers a perspective on Study 2 and Study 3.
-- What will have to happen is that the final report will go out for public comment ending at the end of June/early July; the Board will have to make a decision on Studies 2 and 3.
NCAP Discussion Group:
-- The NCAP Discussion Group is an SSAC group that has to address 10 questions across 2 Board resolutions.
-- That work will continue regardless of the Board’s decision on Studies 2 and 3.
-- It is now looking specifically at the Board’s questions and what we know to answer the questions and what we think we need, which will feed into the DG’s statement of work for a future project.
-- Will provide guidance for the Board to determine if a string can be delegated or is a collision string.
-- Timeline is the timeline that the NCAP set out for itself. Procurement process at ICANN took longer than we expected -- the administrative side.
-- Starting Study 2 now to take advantage of the time we have.
-- The Board in March 2020 ask ICANN Org to complete Study 1 -- we’ve done that with a contractor; we’ll have the report to the Board by 30 June, but that will be tight.
-- Contractor has delivered a draft final version of the report -- we have a deadline of 06 May to resolve feedback from the Discussion Group.
-- Even though the Board asked ICANN Org to do Study 1 it was originally designed by the SSAC.
-- Study 2 will proceed even if not funded by ICANN; SSAC, through NCAP, has a responsibility to answer the Board’s questions. It may not proceed as originally designed.
Question: What is the relationship of the NCAP Discussion Group, the SSAC, and the NCAP Admin Committee?
-- Originally the Board had focused on the SSAC, and the SSAC had done a proposal.
-- There was some discussion of how to manage the project.
-- The idea was that there should be a project sponsor/manager and OCTO became the home.
-- All of the analysis and technical work will be done by the Discussion Group, which is open and transparent.
-- Contractors are managed by OCTO.
-- Created an Admin Committee that allows the SSAC to have oversight of what is going on. It is Rod Rasmussen, SSAC Chair, and Julie Hammer, SSAC Vice Chair , Merike Kaeo, Matt Larson, and the three NCAP Co-Chairs, Jim Galvin, Matthew Thomas, and Patrik Faltstrom.
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.
-- Implication is that the new round could occur before there is a new framework as long as the existing framework remains in place.
-- Question: Is this the majority view? How are we accounting for the concerns about waiting for the NCAP/SSAC work. Answer: This is the majority view.
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 strings in advance, 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.
-- Hope that a version of this comes out of NCAP.
-- Don’t think NCAP can create a list of strings, but could be a set of questions with particular criteria with data that the Board can use to evaluate. Having criteria would be better than creating a list.
-- SSAC’s position -- SSAC does not want to be in a position to say whether not a string should be delegated. The SSAC believes that there are security and stability issues that have not been thoroughly studied or understood with respect to Name Collisions - need to know what they are before you proceed to delegate.
-- If we finish the policy work it might help all sides finish the work.
-- On the “Do Not Apply” list -- Jim Galvin noted that the NCAP could develop criteria, but not a list. Could still have this as Implementation Guidance, or change it to the criteria to create a “Do Not Apply” list.
-- In 2012 there was no list, but in principle you had data you could look at and make assessments. If you use similar criteria -- today we have the extra issue of whether or not the data can be influenced.
-- Whether there could be a list is dependent on the criteria.
-- Worry about someone who knows the criteria and then sets up the data to their benefit and the detriment of others.
-- Matt Larson will send his slides on recent queries to the root server relating to people working at home recently -- .home, .corp, and .local.
-- The IETF has a special use list of names, that includes .local. There is no rule that says that ICANN can’t delegate .local.
-- This report will recommend that no one will be able to apply for a name on the special use list.
ACTION ITEM: Consider whether rather than an “Do Not Apply” list this might be a recommendation for criteria.
c. New issues raised in deliberations since publication of the Initial Report, if applicable.
-- Minority statements would be submitted after the formal consensus call. The request for minority statements would apply to everything in the report of course, not just this section.
-- Don’t have any language that from the SSAC standpoint Study 2 will proceed.
-- Wondering why we would still be referring to an old draft of Study 1.
-- Need to add that even if ICANN doesn’t fund Study 2 based on the questions posed to the SSAC Study 2 will proceed.
--- Make the change that it’s not the NCAP report but ICANN Org’s report.
-- There is analysis work to be done in order for the SSAC to produce answers to the Board. One part will continue in NCAP regardless of anything else that goes on. That analysis will occur based on two things: 1) what we already know about Name Collisions -- work in 2012 and Study 1; 2) there is an option that SSAC had originally proposed where there is now additional raw data that it wanted to look at again as part of the analysis work that the NCAP will do. Two parts for Study 2 -- respond to the Board’s question with what we have available; dependent on funding is the gathering of new raw data.
ACTION ITEM: Change language to reference the NCAP report to ICANN Org’s report.