[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 16 September 2019

Julie Hedlund julie.hedlund at icann.org
Mon Sep 16 16:43:01 UTC 2019


Dear Working Group members,

Please see below the notes from the meeting on 16 September 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-09-16+New+gTLD+Subsequent+Procedures+PDP.

Kind regards,
Julie
Julie Hedlund, Policy Director

Notes and Action Items:

1. Updates to Statements of Interest: No updates provided.

2. Review of summary documents:

a. Name Collisions -- See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrouR4AI/edit?usp=sharing, page 55

Outstanding Items - New Ideas/Concerns/Divergence:
-- GNSO Council letter to the Board asking about dependencies with the NCAP report with respect to the new gTLD subsequent procedures.
-- More Unknowns than knowns at this stage from the NCAP  work.  So we need to draw some lines in the sand for our work re: dependencies.
-- The lack of high-level agreements so far reflect divisions in the community and in the WG that will make us default to 2012 implementation in most of the topics.
-- Some vendors have opted not to bid for the RFP for Study 1, but RFP is still open.
-- In the comments, there is no consensus in deferring or not deferring to NCAP or SSAC.
-- WG needs to plan for both circumstances: 1) NCAP is completed; 2) NCAP is not completed.
-- Question: how many languages/scripts are involved? Answer: name collisions are about strings in ASCII characters.  Name collisions only happen "in the wire", meaning that only in ASCII, even though that could be the IDNA representation of an IDN string.
-- Question: Has any work been done on the RYSG ask for a look at the effectiveness of the previous mitigation measures? (sorry on mobile so slower reaction time)?  Answer: Final report issued by the JAS advisors.  Based on their data they do believe the previous mitigation measures have worked.
-- Zero mishaps perhaps because we don’t know if controlled interruption actually worked effectively to alert us.
-- From a evidence-driven PDP methodology, the only available data says 0.

If NCAP work is not completed prior to the next application round, should the default be that the same name collision mitigation frameworks in place today be applied to those TLDs approved for the next round?
-- Re: RySG comment, “No. ICANN should, at a minimum, release the studies its done on the names collision frameworks so that the community can judge if the same frameworks should be applied. If ICANN cannot do that, ICANN should conduct a prompt, formal study that quantifies and measures the efficacy of the previous controlled interruption framework should be conducted before modifying or replacing the system, without delaying the next round. Without these baseline measurements, assessing the risks of an alternative CI framework is not possible.”  Question: Is there any evidence to the contrary since the JAS report?  Answer: NCAP is looking to see if there was anything else.
-- There is no evidence that controlled interruption worked as intended.
-- Only by asking all Internet users if it worked or not could there be evidence of it having worked 100%.
-- Hard to find evidence that may or may not be out there.
-- An additional concern is that it wasn’t a vetted community driven design


-- But for all anybody knows, it worked. Despite some FUD on the other direction.


-- It is another unknown as it is a risk assessment ratio risk.
-- In response to Rubens…. Rubens part of the scope of Study 1 of NCAP to review the papers and results to come to an assessment - we should not be trying to do that now, as a pdp WG - NCAP will make an independent assessment as per its scope.
-- In order to prove it worked, ICANN would have to make some representative strings not go through controlled interruption, and see what happened in that control group compared to the full slate.

-- NCAP study 1 is just a collection of published material, with no conclusion to be made.

-- Suggestion to the final report: 2012 implementation (due to lack of consensus) + substantial refund + possibility of disabling CI on a per-string basis at ICANN Org request.
-- Good for the WG to acknowledge the findings of SAC90 and potentially agree with them with respect to collaboration.

b. Objections -- See: https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-KNrPs/edit?usp=sharing, page 2

High-Level Agreements:
Re: ICANN must publish, for each type of objection, all supplemental rules as well as all criteria to be used by panelists for the filing of, response to, and evaluation of each objection. Such guidance for decision making by panelists must be more detailed than what was available prior to the 2012 round. (High-Level Agreement C)
-- Could the WG include a recommendation this should be done prior to accepting any applications?  For those who were part of the community applications, there were supplemental rules created after applications were submitted and after objections.  If there are going to be supplemental rules they need to be published prior to applications being submitted.
-- Seems like the first three bullets could be very costly, depending on how implemented.
-- Don’t think the WG is asking for new rules, just for transparency in supplemental rules and in selecting panelists.
-- So there does need to be a balance between transparency and flexibility.  There will be some unknowns prior to the applications being submitted.
-- Basically anything that is meant to apply to objection procedures must be made available upfront.
-- Should we carve out community applications, versus community objections?
-- Those that filed/responded to LPI and other objections would liekly agree with increased transparency.
-- Community objections were also used by community applications to try resolving their contention sets, not only by standard applications against declared as community applications.
-- Do we need to make a There appears to be a concern about the latter being developed on the fly.
-- The point is not about CPE here, but rather about how supplemental documents for CPE were published years after ICANN accepted community applications. Unless we are clear in subsequent procedures about supplemental materials not being permitted for objections, then we don’t have any way of preventing them from doing so.
-- Important to know costs ahead of time.
-- Basically anything that is intended to apply to objection procedures must be made available upfront.
-- Can we separate CPE into a separate category of objections?
Community Objections are a different discussion.
-- Perhaps providing a list of the changed elements would assist the group in understanding the issues you are presenting.

-- CPE is part of string contention resolution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20190916/0ac02044/attachment-0001.html>


More information about the Gnso-newgtld-wg mailing list