Dear Working Group members, Please see below the notes from the meeting today, 01 April 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-04-01+New+gTLD+Subsequent+Pro.... Please also see the referenced document at: https://docs.google.com/spreadsheets/d/1Ea-CjtL-heQjEwTesr7MYC_8gFEvmhY8XBCW.... Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: 1. Updates to Statements of Interest (SOIs): No updates provided. 2. Review of comments - Supplemental Initial Report: see the document at:https://docs.google.com/spreadsheets/d/1Ea-CjtL-heQjEwTesr7MYC_8gFEvmhY8XBCW...: a. 2.4 Change Requests – start at line 16 General NCSG comment: Opposition to any kind of string change request. Question: -- On change requests: Is it the WG's understanding that this affects community applications going forward since they weren't able to make such changes under the current rules? Answer: The language seems to apply across the board. This should be made abundantly clear. 2.4.d.1: Lines 17-20, BRG, ALAC, IPC, ALAC -- Agreement Line 21, RrSG -- Agreement New Idea Line 22, RySG -- Divergence (opposes allowing applicant to change its string) -- Question: In some cases RySG says, "some members" but not in this case. Is this correct? Donna Austin will check. -- Is the WG recommendation designed to be very narrow or broad? Answer: WG deliberations: 2) have a limited ability to select a different string, which must be closely related to the original string. • Implementation Guidance: ICANN org may determine that in the event of a joint venture, re-evaluation is needed to ensure that the new entity still meets the requirements of the program. The applicant may be responsible for additional, material costs incurred by ICANN due to re-evaluation and the application could be subject to delays. • Implementation Guidance: Some examples to consider in allowing for a new string to be selected include prepending/appending a new element to the original string or selecting a string that is closely related to the class/sector of the original string. ICANN org must perform a re- evaluation of the new applied-for string in all string related evaluation elements (e.g., DNS Stability, String Contention, etc.) and the application for the new string would be subject to string related objections (e.g., String Confusion Objections, Legal Rights Objections, etc.). Another Working Group member noted that in allowing for a string change, the new string would need to be (a) subject to name collision risk assessment, (b) put out for public comment and (c) open to established Objection procedures. The applicant may be responsible for additional, material costs incurred by ICANN due to re-evaluation and the application could be subject to delay. -- Not meant to be a broad right, but very limited. 2.4.e.1: Line 24, RySG -- Divergence (oppose applicants changing string post-application) 2.4.e.1.1: Line 26-29, BRG, ALAC, IPC, ALAC -- Agreement Line 30, RySG -- Divergence (opposes allowing applicant to change its string with rationale) Line 31, NCSG -- Divergence (opposes allowing string changes to the gTLD once a string is chosen) Line 32, NCSG -- Divergence (opposes allowing string changes to the gTLD once a string is chosen) 2.4.3.1.2: Lines 34-36, BRG, ALAC, IPC -- Agreement Line 37, RySG -- Divergence (opposes jumping from one contention set to another) Line 38, NCSG -- Divergence (opposes ability to change strings with rationale) 2.4.e.1.3: Line 40-44, dotgay LLC, BRG, ALAC, IPC, RySG -- Agreement (but with limitations) Line 45, NCSG -- Divergence (opposes string modification) 2.4.e.2: Lines 47-48, BRG and ALAC -- Agreement (support role for public comment) Line 49, IPC -- Agreement (support for limited role for public comment) Line 50, RySG -- Agreement (support role for public comment -- same "changed" and "new" strings) Line 51, NCSG -- Agreement (support role for public comment with same rules as for original application) Line 52, ALAC -- Agreement (supports 2.4.c.1, 2.4.d.1, 2.4.e.1.1, 2.4.e.2) Line 53, NCSG -- Agreement Concerns (lack of specificity in suggested changes) 2.4.e.3: Line 55, ALAC -- Agreement (with minor changes) -- Updated the ALAC comment under 2.4.e.3 to blue. Line 56, IPC -- Agreement (with additional criteria) -- How will we be noting the additional criteria? IPC is saying there should be changes -- additional question, etc. Changed to "New Idea" (blue text) Line 57, RySG -- Agreement (no specific changes) Line 58, NCSG -- Agreement (support using same rules as original application) b. 2.5 Registrar Support for New gTLDs: General Comments: Line 4, ALAC -- Declines to comment. Line 5, BC -- Agreement (supports a more market-oriented solution with examples) Line 6, RrSG -- Divergence (opposes requirements for registrars to specific and/or all TLDs) 2.5.d.1: Line 8, RySG -- No comment. 2.5.d.1.1: Line 10, RySG -- Agreement (some support/some support one-time subsidy) Divergence (some oppose) Line 11, IPC -- New Idea Divergence 2.5.d.1.2: Line 13, José Alberto Barrueto Rodríguez -- Agreement (some support with examples) Divergence (opposes with examples) Line 14, RySg -- Agreement (some support option) Divergence (some oppose option) Line 15, RrSG -- Divergence (opposes requirements for registrars to carry specific and/or all TLDs) 2.5.d.1.3: Line 17, José Alberto Barrueto Rodríguez -- Agreement (with example) Line 18, RySG -- Agreement (strongly supports option) 2.5.d.1.4: Line 20, RySG -- Agreement Line 21, RrSG -- New Idea, Divergence (opposes suggestion) 2.5.d.1.5: Line 23, RySG -- Agreement (supports option) New Idea (suggests option) Line 24, RrSG -- Divergence (opposes bundling) 2.5.e.1: Line 26, RySG -- See previous comments. 2.5.e.2: Line 28, RySG -- Comments (new additional proposals but recommends a balance between innovation and attractiveness for sales) 2.5.e.3: Line 30, RySG -- Agreement (support for assisting registries) Divergence (oppose assisting registries) 2.5.e.4: Line 32, RySG -- Agreement (in scope but no suggestions) Divergence (out of scope) 2.5.e.5: LIne 34, RySG -- Agreement (in scope but not mandatory) Divergence (out of scope) Line 35, RySG -- Divergence (opposes requirements for registrars to specific and/or all TLDs) 3. AOB: On Name Collisions and NCAP: Discussions on the list about whether to go to the Board on timing? WG leadership is reaching out to the SSAC leadership to see how we can coordinate. 4. Next Steps: -- Next call is Tuesday, 09 April 2019 at 03:00 UTC for 90 minutes. -- Start with summaries of issues.