- Gnso-newgtld-wg - lists.icann.org

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC
by Julie Hedlund Feb. 12, 2020

Feb. 12, 2020

Dear Working Group members, Please see below the notes from the meeting on 10 February 1500 UTC. 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/2020-02-10+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.2.3 Applications Assessed in Rounds: Implementation Guidance xx (see rationale 2): ACTION ITEM: Take the contents of Jeff Neuman’s email into Implementation Guidance (amended for clarity as necessary). ACTION ITEM: WG members will be invited to present a minority view. Proposal from Alexander Schubert: “If a string has been evaluated and is not approved by ICANN – the application will be withdrawn BY ICANN once all appeals and accountability mechanisms are exhausted (no input by the applicant required; prevents “blocking of a string forever”).” ACTION ITEM: Take the discussion of Alexander Schubert’s proposal to the email list. 2.2.6 RSP Pre-Approval: Recommendation xx (Rationale 1): ACTION ITEM: Add after first sentence: “may receive pre-approval by ICANN if they pass the required technical evaluation and testing conducted by ICANN, or their selected third party provider.” Implementation Guidance xx (rationale 7): ACTION ITEM: Re-write to clarify. Recommendation xx (rationale 5): ACTION ITEM: Add some language in a note about the comment from Donna Austen about whether we can get details concerning the costs. Recommendation xx (rationale 6): ACTION ITEM: Change the first sentence to read “The list of pre-approved RSPs must be published…” Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkR… a. 2.2.3 Applications Assessed in Rounds (brief continued discussion – page 4) -- Spent a lot of time on how we perceived a subsequent round if there are still applications in process. -- Current language: Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [PROVIDED THE APPLICANT(S) for that same string FROM THE PRIOR ROUND HAVE AGREED IN WRITING TO FOLLOW ALL UPDATED POLICY provisions prior TO THE OPENING OF THE NEXT ROUND. DING ADOPTED BY NEW POLICIES]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round, unless and/or until the applications from the previous round that match those strings have had their final disposition. Email from Jeff Neuman: See http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002434.html Discussion: -- Question: What does “on hold” mean? Answer: Subject of GAC advice or challenge from right of first refusal; didn’t apply to many. Means the application is still being processed. Subject of an appeal or accountability mechanism. .IDN is still in an accountability mechanism. -- Question: What does Application Support mean as a category? Answer: That the application is being evaluated for application support. -- Seems like most of the edge cases will have been addressed by the Board. -- The principle suggested by Anne Aikman-Scalese that there could be backup applications would not be allowed on the current suggested policy where there are policy issues involved (on hold, brand issue, appeal/accountability mechanisms). -- Allowing backup applications would add lots of complications and unintended consequences. Simpler to have a rule to say if it is in any of these statuses you can’t apply for it. -- There should be pressure on prior applicants to meet new policy. -- But that assumes that there is new policy, and not sure we can assume that. -- Question: How long do you let an application "hang out" without any pending mechanisms on it? Answer: There are timelines for accountability mechanisms in the Bylaws and we’ll be setting implementation guidance when we discuss appeals. -- Why assume that people will want to apply for the problematic strings (those that had name collisions) and assume that those problems will be resolved? -- Anne Aikman-Scalese: I am not talking about 6.c "Not approved" only. I am talking about most of your detailed categories - many of which prohibit back-up offers that will lock applicants out until another window opens up - perhaps much later, e.g. in the case of appeals and accountability mechanisms. ACTION ITEM: Take the contents of Jeff’s email into Implementation Guidance (amended for clarity as necessary). ACTION ITEM: WG members will be invited to present a minority view. Proposal from Alexander Schubert: “If a string has been evaluated and is not approved by ICANN – the application will be withdrawn BY ICANN once all appeals and accountability mechanisms are exhausted (no input by the applicant required; prevents “blocking of a string forever”).” See: http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002431.html Question: Currently there is no mechanism to force the withdrawal of an application for a string. Should we create one? Discussion: -- Does this trigger the necessity to exhaust all remedies? -- Support Alexander’s proposal to include a provision to force withdrawals in the case where the Board says the application shouldn’t proceed and there should be a refund. -- What happens if the Board says the application won’t proceed for now -- “not approved” is not the same as “rejected”? We could always say that the Board needs to be explicit. -- Strings that were rejected due to objection - and can't move forward (e.g. a city or a religious community). Should be withdrawn to allow others to apply for it in the future.  ACTION ITEM: Take the discussion of Alexander Schubert’s proposal to the email list. b. 2.2.6 RSP Pre-Approval (page 20) -- Email from Jim Predergast: Could we call this two phases of testing, rather than “pre-approval”. Have two phases -- second phase would be everything in schedule A, that is unique to each TLD. Avoid the implication of “pre-approval”. So, call it “passed Phase 1 testing”. -- Assumption is that there will be a phase 2 of testing. -- We are trying to signify RSPs that have passed an initial evaluation. Is there a way of indicating that without using the word “approval”? -- We went to “pre-approval” to avoid the terminology of “certification”. -- Hard not to get bogged down in trying to find a word that is acceptable to all. -- We could add explanatory language as to what “pre-approval” means. -- New data from ICANN reinforces that there continue to be problems with registry back-end operators. -- Explanatory language would only work for insiders -- outsiders would see that as approval. -- Continue this discussion on the list. -- The testing part would apply to both, the only difference is the timing. -- Other terminology for Recommendation xx (Rationale 1): “... may receive pre-approval if they pass the required technical evaluation and testing conducted by ICANN, or their selected third party provider.” -- Or call it “Pre-testing Program” or “ Pre-qualification”. ACTION ITEM: Amend Recommendation xx (Rationale 1): add after first sentence: “may receive pre-approval by ICANN if they pass the required technical evaluation and testing conducted by ICANN, or their selected third party provider.” Implementation Guidance xx (rationale 7): With respect to each subsequent round, ICANN org may establish a separate more streamlined process for reassessments in terms of evaluation and testing than those entities seeking RSP pre-approval for the first time. Discussion: -- We don’t know how this will go in the next round. -- Probably easier to say that we stay the same as what we had before, but if there is an opportunity for ICANN to streamline the process they should be allowed to do so. -- We are saying that there could be a much more extensive pre-approval process, but for reassessment it might be less extensive. -- Need to clarify the wording. -- Should defer to the SSAC as technical experts and ICANN staff. -- Saying that RSPs do not have technical expertise might be wrong SSAC and ICANN does not necessarily have understanding of all aspects of the inner work of Registries backends.  ACTION ITEM: Re-write to clarify. Recommendation xx (rationale 5): The RSP pre-approval program must be funded by those seeking pre-approval on a cost-recovery basis. Costs of the program should be established during the implementation phase by the Implementation Review Team and/or ICANN org. Discussion: -- Really would like to understand what those costs are. -- Important, if possible, to get some indicative costs. If the costs are prohibitive then we won’t get anyone using the pre-approval program. Flag to come back to this. -- Not sure that we’ll have information on the costs during the PDP. Should have a better understanding during implementation. ACTION ITEM: Add some language in a note about the comment from Donna Austen about whether we can get details concerning the costs. Recommendation xx (rationale 6): Results of an RSP Pre-Approval Program must be published on ICANN’s website with all of the other new gTLD materials and must be available to be used by potential applicants with an adequate amount of time to determine if they wish to apply for a gTLD using a Pre-Approved RSP. Discussion: -- Could we narrow this so that there could be security purposes to not publish? -- Say that “the list of pre-approved RSPs will be published”. ACTION ITEM: Change the first sentence to read “The list of pre-approved RSPs must be published…” 3. Work Plan -- See email from Jim Prendergast on the Work Plan: http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002442.html. -- Topics for the next meeting at 0300 UTC on 13 February are: Universal Acceptance and Registry System Testing. 4. Topics for ICANN67 -- Working with the GAC to identify topics. -- Will provide briefing documents to help guide discussions. -- GAC members will be able to attend the SubPro PDP WG meetings because they will not have conflicts for those sessions.

5 7

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 13 February 2020 at 03:00 UTC
by Julie Hedlund Feb. 12, 2020

Feb. 12, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 13 February 2020 at 03:00 UTC for 90 minutes: 1. Review Agenda/Statements of Interest 2. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… * 2.3.4 Universal Acceptance (page 6) * 2.11.1 Registry System Testing (page 7) 3. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie Julie Hedlund, Policy Director

3 2

REMINDER / Meeting Invitation Webinar | EPDP - Phase 2 Proposed Recommendations on a Standardized System for Access and Disclosure | Thursday, 13 February 2020 at 14:00 UTC
by Terri Agnew Feb. 12, 2020

Feb. 12, 2020

Dear all, Please find the details below for the EPDP - Phase 2 Proposed Recommendations on a Standardized System for Access and Disclosure Webinar. This webinar will provide an overview of the EPDP’s Phase 2 proposed recommendations for a Standardized System for Access and Disclosure (SSAD). This effort builds upon the EPDP’s Phase 1 work on enhancing Registration Data Services where, under certain circumstances, personal contact information is now redacted. The Phase 2 effort for developing the SSAD will allow for disclosure of this redacted contact information based on third-party legitimate interests, administration proceedings, and law enforcement needs, subject to applicable law and the rights of the data subject. The webinar will highlight each of the EPDP Team’s recommendations and will provide an opportunity for participants to ask questions and provide feedback on the Initial Report, which is currently out for public comment. The report can be found on the public comment proceedings section on https://www.icann.org/public-comments [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_public-2…>, and the webinar materials will be posted on the EPDP’s wiki page<https://community.icann.org/x/6g6JBw> following the webinar. Thursday, 13 February 2020 at 14:00 UTC for 60 minutes For other times: https://tinyurl.com/wsm7h3y [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_wsm7h3y&d=…> Join Zoom Meeting: https://icann.zoom.us/s/331729252 [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_s_331729…> Meeting ID: 331 729 252 Password: 586730 One tap mobile +16699006833,,331729252# US (San Jose) +19294362866,,331729252# US (New York) Find your local number: https://icann.zoom.us/u/abQBVd1jHM [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_u_abQBVd…> Slides to assist you with Zoom: Welcome to Zoom: https://icann.box.com/shared/static/1sal3l5qf4csdukt0pk2c75ey3bte22z.pdf [icann.box.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.box.com_shared_s…> Zoom FAQ: https://icann.box.com/shared/static/d5rap0g6xphevhkdd3mhu2hy753l2m3s.pdf [icann.box.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.box.com_shared_s…> If Zoom disappears, see instructions:https://gnso.icann.org/sites/default/files/policy/2019/present…<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_d…> A calendar invitation has equally been attachment for you to download to your calendar. Thank you in advance for reserving this time in your schedule. Kind Regards, Terri

1 1

Re: [Gnso-newgtld-wg] [gnso-secs] [Ext] RE: Review and provide feed back | New Public Comment feature
by Andrea Glandon Feb. 11, 2020

Feb. 11, 2020

Dear Jeff, Please see the response below from the group handling this review: David’s blog post explains: “When you access the new Public Comment Feature [feedback.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__feedback.icann.org_&d=…>, you will see a new user interface. The Public Comment Proceedings that you will see on the landing page are comprised of test data, so these are not active Proceedings. We created these sample Proceedings, to give you the opportunity to experiment with the new interface and allow you to test out and publish a sample Public Comment Submission using the new format.” The sample proceedings are based on closed proceedings. Thank you! Kind Regards, Andrea From: Gnso-secs <gnso-secs-bounces(a)icann.org> on behalf of Terri Agnew <terri.agnew(a)icann.org> Date: Tuesday, February 11, 2020 at 15:03 To: Jeff Neuman <jeff.neuman(a)comlaude.com>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Cc: "gnso-secs(a)icann.org" <gnso-secs(a)icann.org> Subject: Re: [gnso-secs] [Ext] RE: [Gnso-newgtld-wg] Review and provide feed back | New Public Comment feature Hi Jeff, We have provided this feedback to the group handling this review. Kind regards, Terri From: Jeff Neuman <jeff.neuman(a)comlaude.com> Date: Tuesday, February 11, 2020 at 2:59 PM To: Jeff Neuman <jeff.neuman(a)comlaude.com>, Terri Agnew <terri.agnew(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Cc: "gnso-secs(a)icann.org" <gnso-secs(a)icann.org> Subject: [Ext] RE: [Gnso-newgtld-wg] Review and provide feed back | New Public Comment feature It should say there is NO upcoming proceeding in March 2020 for WT 5. I wish they put fake text in….because several people have now reached out to me to see if there was something going on with WT 5. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Jeff Neuman Sent: Tuesday, February 11, 2020 3:56 PM To: Terri Agnew <terri.agnew(a)icann.org>; gnso-newgtld-wg(a)icann.org Cc: gnso-secs(a)icann.org Subject: Re: [Gnso-newgtld-wg] Review and provide feed back | New Public Comment feature Please note that all of the data on that page is “Test Data”. It is NOT REAL. So, the fact that it says that there is a March 2020 for WT 5 is not real. I repeat, it is NOT REAL. There is upcoming proceeding in March 2020 for WT 5. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Terri Agnew Sent: Tuesday, February 11, 2020 12:54 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Cc: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> Subject: [Gnso-newgtld-wg] Review and provide feed back | New Public Comment feature Dear all, As per David Olive’s blogpost [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_blo…>, the Public Comment feature has undergone improvements, developed thanks to community input. The Information Transparency Initiative (ITI) team released the new Public Comment feature on the 7th February 2020 and your feedback is greatly anticipated. Review https://alpha.icann.org/en/public-comment [alpha.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__alpha.icann.org_en_pub…> and provide feedback to public-comment(a)icann.org<mailto:public-comment@icann.org> Thank you. With kind regards, Terri --- Terri Agnew Operations Support - GNSO Lead Administrator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: terri.agnew.icann Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com [comlaude.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&…> ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com [comlaude.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&…>

1 0

Re: [Gnso-newgtld-wg] [Ext] RE: Review and provide feed back | New Public Comment feature
by Terri Agnew Feb. 11, 2020

Feb. 11, 2020

Hi Jeff, We have provided this feedback to the group handling this review. Kind regards, Terri From: Jeff Neuman <jeff.neuman(a)comlaude.com> Date: Tuesday, February 11, 2020 at 2:59 PM To: Jeff Neuman <jeff.neuman(a)comlaude.com>, Terri Agnew <terri.agnew(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Cc: "gnso-secs(a)icann.org" <gnso-secs(a)icann.org> Subject: [Ext] RE: [Gnso-newgtld-wg] Review and provide feed back | New Public Comment feature It should say there is NO upcoming proceeding in March 2020 for WT 5. I wish they put fake text in….because several people have now reached out to me to see if there was something going on with WT 5. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Jeff Neuman Sent: Tuesday, February 11, 2020 3:56 PM To: Terri Agnew <terri.agnew(a)icann.org>; gnso-newgtld-wg(a)icann.org Cc: gnso-secs(a)icann.org Subject: Re: [Gnso-newgtld-wg] Review and provide feed back | New Public Comment feature Please note that all of the data on that page is “Test Data”. It is NOT REAL. So, the fact that it says that there is a March 2020 for WT 5 is not real. I repeat, it is NOT REAL. There is upcoming proceeding in March 2020 for WT 5. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Terri Agnew Sent: Tuesday, February 11, 2020 12:54 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Cc: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> Subject: [Gnso-newgtld-wg] Review and provide feed back | New Public Comment feature Dear all, As per David Olive’s blogpost [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_blo…>, the Public Comment feature has undergone improvements, developed thanks to community input. The Information Transparency Initiative (ITI) team released the new Public Comment feature on the 7th February 2020 and your feedback is greatly anticipated. Review https://alpha.icann.org/en/public-comment [alpha.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__alpha.icann.org_en_pub…> and provide feedback to public-comment(a)icann.org<mailto:public-comment@icann.org> Thank you. With kind regards, Terri --- Terri Agnew Operations Support - GNSO Lead Administrator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: terri.agnew.icann Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com [comlaude.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&…> ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com [comlaude.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&…>

1 0

Review and provide feed back | New Public Comment feature
by Terri Agnew Feb. 11, 2020

Feb. 11, 2020

Dear all, As per David Olive’s blogpost [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_blo…>, the Public Comment feature has undergone improvements, developed thanks to community input. The Information Transparency Initiative (ITI) team released the new Public Comment feature on the 7th February 2020 and your feedback is greatly anticipated. Review https://alpha.icann.org/en/public-comment [alpha.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__alpha.icann.org_en_pub…> and provide feedback to public-comment(a)icann.org<mailto:public-comment@icann.org> Thank you. With kind regards, Terri --- Terri Agnew Operations Support - GNSO Lead Administrator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: terri.agnew.icann Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

2 2

Re: [Gnso-newgtld-wg] [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC
by Julie Hedlund Feb. 10, 2020

Feb. 10, 2020

Thanks Jim for the clarification. Kind regards, Julie From: Jim Prendergast <jim(a)GALWAYSG.COM> Date: Monday, February 10, 2020 at 3:48 PM To: Julie Hedlund <julie.hedlund(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC Hi Julie – one addition on the Actions from 2.2.6 RSP Pre-Approval Its buried in the notes but the action item should be to come up with a term that describes the program but replaces the term “Approval” because of the implications that may convey in light of the recent EBERO/SLAM data we received. Concerns are further described in my email to the list from Jan 30 - https://mm.icann.org/pipermail/gnso-newgtld-wg/2020-January/002400.html and supported by Rubes on list and a few others on the call earlier today. Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Julie Hedlund Sent: Monday, February 10, 2020 11:51 AM To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC Dear Working Group members, Please see below the notes from the meeting on 10 February 1500 UTC. 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/2020-02-10+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.2.3 Applications Assessed in Rounds: Implementation Guidance xx (see rationale 2): ACTION ITEM: Take the contents of Jeff Neuman’s email into Implementation Guidance (amended for clarity as necessary). ACTION ITEM: WG members will be invited to present a minority view. Proposal from Alexander Schubert: “If a string has been evaluated and is not approved by ICANN – the application will be withdrawn BY ICANN once all appeals and accountability mechanisms are exhausted (no input by the applicant required; prevents “blocking of a string forever”).” ACTION ITEM: Take the discussion of Alexander Schubert’s proposal to the email list. 2.2.6 RSP Pre-Approval: Recommendation xx (Rationale 1): ACTION ITEM: Add after first sentence: “may receive pre-approval by ICANN if they pass the required technical evaluation and testing conducted by ICANN, or their selected third party provider.” Implementation Guidance xx (rationale 7): ACTION ITEM: Re-write to clarify. Recommendation xx (rationale 5): ACTION ITEM: Add some language in a note about the comment from Donna Austen about whether we can get details concerning the costs. Recommendation xx (rationale 6): ACTION ITEM: Change the first sentence to read “The list of pre-approved RSPs must be published…” Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkR… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> a. 2.2.3 Applications Assessed in Rounds (brief continued discussion – page 4) -- Spent a lot of time on how we perceived a subsequent round if there are still applications in process. -- Current language: Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [PROVIDED THE APPLICANT(S) for that same string FROM THE PRIOR ROUND HAVE AGREED IN WRITING TO FOLLOW ALL UPDATED POLICY provisions prior TO THE OPENING OF THE NEXT ROUND. DING ADOPTED BY NEW POLICIES]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round, unless and/or until the applications from the previous round that match those strings have had their final disposition. Email from Jeff Neuman: See http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002434.html Discussion: -- Question: What does “on hold” mean? Answer: Subject of GAC advice or challenge from right of first refusal; didn’t apply to many. Means the application is still being processed. Subject of an appeal or accountability mechanism. .IDN is still in an accountability mechanism. -- Question: What does Application Support mean as a category? Answer: That the application is being evaluated for application support. -- Seems like most of the edge cases will have been addressed by the Board. -- The principle suggested by Anne Aikman-Scalese that there could be backup applications would not be allowed on the current suggested policy where there are policy issues involved (on hold, brand issue, appeal/accountability mechanisms). -- Allowing backup applications would add lots of complications and unintended consequences. Simpler to have a rule to say if it is in any of these statuses you can’t apply for it. -- There should be pressure on prior applicants to meet new policy. -- But that assumes that there is new policy, and not sure we can assume that. -- Question: How long do you let an application "hang out" without any pending mechanisms on it? Answer: There are timelines for accountability mechanisms in the Bylaws and we’ll be setting implementation guidance when we discuss appeals. -- Why assume that people will want to apply for the problematic strings (those that had name collisions) and assume that those problems will be resolved? -- Anne Aikman-Scalese: I am not talking about 6.c "Not approved" only. I am talking about most of your detailed categories - many of which prohibit back-up offers that will lock applicants out until another window opens up - perhaps much later, e.g. in the case of appeals and accountability mechanisms. ACTION ITEM: Take the contents of Jeff’s email into Implementation Guidance (amended for clarity as necessary). ACTION ITEM: WG members will be invited to present a minority view. Proposal from Alexander Schubert: “If a string has been evaluated and is not approved by ICANN – the application will be withdrawn BY ICANN once all appeals and accountability mechanisms are exhausted (no input by the applicant required; prevents “blocking of a string forever”).” See: http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002431.html Question: Currently there is no mechanism to force the withdrawal of an application for a string. Should we create one? Discussion: -- Does this trigger the necessity to exhaust all remedies? -- Support Alexander’s proposal to include a provision to force withdrawals in the case where the Board says the application shouldn’t proceed and there should be a refund. -- What happens if the Board says the application won’t proceed for now -- “not approved” is not the same as “rejected”? We could always say that the Board needs to be explicit. -- Strings that were rejected due to objection - and can't move forward (e.g. a city or a religious community). Should be withdrawn to allow others to apply for it in the future.  ACTION ITEM: Take the discussion of Alexander Schubert’s proposal to the email list. b. 2.2.6 RSP Pre-Approval (page 20) -- Email from Jim Predergast: Could we call this two phases of testing, rather than “pre-approval”. Have two phases -- second phase would be everything in schedule A, that is unique to each TLD. Avoid the implication of “pre-approval”. So, call it “passed Phase 1 testing”. -- Assumption is that there will be a phase 2 of testing. -- We are trying to signify RSPs that have passed an initial evaluation. Is there a way of indicating that without using the word “approval”? -- We went to “pre-approval” to avoid the terminology of “certification”. -- Hard not to get bogged down in trying to find a word that is acceptable to all. -- We could add explanatory language as to what “pre-approval” means. -- New data from ICANN reinforces that there continue to be problems with registry back-end operators. -- Explanatory language would only work for insiders -- outsiders would see that as approval. -- Continue this discussion on the list. -- The testing part would apply to both, the only difference is the timing. -- Other terminology for Recommendation xx (Rationale 1): “... may receive pre-approval if they pass the required technical evaluation and testing conducted by ICANN, or their selected third party provider.” -- Or call it “Pre-testing Program” or “ Pre-qualification”. ACTION ITEM: Amend Recommendation xx (Rationale 1): add after first sentence: “may receive pre-approval by ICANN if they pass the required technical evaluation and testing conducted by ICANN, or their selected third party provider.” Implementation Guidance xx (rationale 7): With respect to each subsequent round, ICANN org may establish a separate more streamlined process for reassessments in terms of evaluation and testing than those entities seeking RSP pre-approval for the first time. Discussion: -- We don’t know how this will go in the next round. -- Probably easier to say that we stay the same as what we had before, but if there is an opportunity for ICANN to streamline the process they should be allowed to do so. -- We are saying that there could be a much more extensive pre-approval process, but for reassessment it might be less extensive. -- Need to clarify the wording. -- Should defer to the SSAC as technical experts and ICANN staff. -- Saying that RSPs do not have technical expertise might be wrong SSAC and ICANN does not necessarily have understanding of all aspects of the inner work of Registries backends.  ACTION ITEM: Re-write to clarify. Recommendation xx (rationale 5): The RSP pre-approval program must be funded by those seeking pre-approval on a cost-recovery basis. Costs of the program should be established during the implementation phase by the Implementation Review Team and/or ICANN org. Discussion: -- Really would like to understand what those costs are. -- Important, if possible, to get some indicative costs. If the costs are prohibitive then we won’t get anyone using the pre-approval program. Flag to come back to this. -- Not sure that we’ll have information on the costs during the PDP. Should have a better understanding during implementation. ACTION ITEM: Add some language in a note about the comment from Donna Austen about whether we can get details concerning the costs. Recommendation xx (rationale 6): Results of an RSP Pre-Approval Program must be published on ICANN’s website with all of the other new gTLD materials and must be available to be used by potential applicants with an adequate amount of time to determine if they wish to apply for a gTLD using a Pre-Approved RSP. Discussion: -- Could we narrow this so that there could be security purposes to not publish? -- Say that “the list of pre-approved RSPs will be published”. ACTION ITEM: Change the first sentence to read “The list of pre-approved RSPs must be published…” 3. Work Plan -- See email from Jim Prendergast on the Work Plan: http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002442.html. -- Topics for the next meeting at 0300 UTC on 13 February are: Universal Acceptance and Registry System Testing. 4. Topics for ICANN67 -- Working with the GAC to identify topics. -- Will provide briefing documents to help guide discussions. -- GAC members will be able to attend the SubPro PDP WG meetings because they will not have conflicts for those sessions.

1 0

Post Call / New gTLD Subsequent Procedures Working Group call on Monday, 10 February 2020 at 15:00 UTC
by Michelle DeSmyter Feb. 10, 2020

Feb. 10, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Monday, 10 February 2020 at 15:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/HAVxBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards, Michelle

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC
by Julie Hedlund Feb. 9, 2020

Feb. 9, 2020

Dear Working Group members, Please see below the notes from the meeting on 06 February 2000 UTC. 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/2020-02-06+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…. Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date.  -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.)  -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG.

8 12

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Monday, 10 February 2020 at 15:00 UTC
by Julie Hedlund Feb. 7, 2020

Feb. 7, 2020

Dear all, Please find below the proposed agenda for the call on Monday, 10 February 2020 at 15:00 UTC for 90 minutes: 1. Review Agenda/Statements of Interest 2. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… * 2.2.3 Applications Assessed in Rounds (brief continued discussion – page 20) * 2.2.6 RSP Pre-Approval (page 20) 3. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie Julie Hedlund, Policy Director

2 1