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

Re: [Gnso-newgtld-wg] Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 12 September 2019 at 20:00 UTC
by Emily Barabas Sept. 11, 2019

Sept. 11, 2019

Hi Anne, Thanks for your thorough review of the document. I’ve added some comments to the document to help clarify where everything is captured. Where the responses to questions e.1-e.8 connected back to the preliminary recommendations, these have been included in the summary document in the same section to make it easier to see everything on the related topic together. I noticed that there was one comment from RySG in response to e.7 that wasn’t sufficiently captured and have added that. Where comments apply to either all of the recommendations or all of the recommendations and questions, the summary of the comment is included just once at the top of the outstanding issues section (I’ve added a note in the document to highlight these for reference). Since this is a summary document, this is simply done for brevity to avoid repeating the same text again and again. On the clarification below from ALAC, I see that Justine has added some text to the document to reflect the below. Please let us know if you see anything else that you think needs to be added or clarified. Kind regards, Emily From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Wednesday, 11 September 2019 at 00:40 To: Julie Hedlund <julie.hedlund(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: Re: [Gnso-newgtld-wg] Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 12 September 2019 at 20:00 UTC Hi All – it appears from the summary document section on Name Collisions that there are some cross references to public comment questions missing. The missing cross-references include 2.7.8 (e) (1) through (8.) It would be helpful if these cross-references could be added to the summary document. The topic of “dependency” which Rubens and I have been debating on the list is treated in responses to 2.7.8.(e()1). Below I paste the public comment on 2.7.8.(e) (1) “Dependency”. The last box was cut off but it is the ALAC comment re deferring to the SSAC and we have an updated clarification from ALAC as follows: Hi Jeff, In reply to your request for further clarification, the ALAC is saying: The Subsequent Procedures WG can conclude its work, and implementation may proceed, BUT EITHER ICANN may not launch the application window until the NCAP study(ies) are completed and any recommendations resulting from those study(ies) are addressed in implementation OR ICANN may launch the application window and start the evaluation process, but no TLD may be delegated until the NCAP Study(ies) is/are completed and any recommendations resulting from those study(ies) are retroactively incorporated. Kind regards, Justine Chew ALAC liaison for Subsequent Procedures Thank you, Anne [cid:image001.png@01D567EB.FD2BF6B0] From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Julie Hedlund Sent: Tuesday, September 10, 2019 7:51 AM To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 12 September 2019 at 20:00 UTC [EXTERNAL] ________________________________ Dear all, Please find below the proposed agenda for the call on Thursday, 12 September 2019 at 20:00 UTC (*NOTE NEW TIME*) for 90 minutes: 1. Welcome and Updates to Statements of Interest 2. Review of summary documents: a. Role of Application Comment -- See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>, page 51, Outstanding Items b. Name Collisions -- See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>, page 55 c. Objections (time permitting) – See: https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-K… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>, page 2 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 ________________________________ 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.

1 0

FW: FOR REVIEW: Draft GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies
by Jeff Neuman Sept. 11, 2019

Sept. 11, 2019

All, We just wanted to forward this note to the SubPro PDP Full Working Group. Cheryl and I were asked by the GNSO Council Leadership to give our thoughts to them about the attached draft letter from the Council to the ICANN Board. We provided this feedback and as you can see we made it clear that the redlines are from Cheryl and I and not the Working Group. Please let us know if you have any questions. Jeff Neuman and Cheryl Langdon-Orr From: Jeff Neuman <jeff.neuman(a)comlaude.com> Sent: Tuesday, September 10, 2019 10:44 PM To: Drazek, Keith <kdrazek(a)verisign.com>; Cheryl Langdon-Orr (langdonorr(a)gmail.com) (langdonorr(a)gmail.com) <langdonorr(a)gmail.com>; Pam Little <pam.little(a)alibaba-inc.com>; rafik.dammak(a)gmail.com Cc: gnso-secs(a)icann.org; gnso-chairs(a)icann.org; Steve Chan <steve.chan(a)icann.org>; Emily Barabas <emily.barabas(a)icann.org>; Julie Hedlund <julie.hedlund(a)icann.org>; Jeff Neuman <jeff.neuman(a)comlaude.com> Subject: RE: FOR REVIEW: Draft GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies Dear Keith, Pam and Rafik, Please find enclosed Cheryl and my redlines to the draft letter. We do not believe the substance of the letter has been changed at all, but rather just added some more specificity. This letter contains only the comments of Cheryl and I and not the Subsequent Procedures Working Group. There are so many people making so many arguments and even if the Board says that there are "dependencies", I think they need to be specific as to which exact step is the completion of the NCAP work dependent on. What is the exact point where we cannot move forward. Some people say the Board cannot accept the final policy without this work being done. Some say the policy can be completed, but implementation work cannot be completed prior to the NCAP finishing. Some say that can complete but we cannot complete the AGB. Some say we can complete that but we cannot announce the new round. Some say we can announce but cannot accept applications. Some say we can do it all but not delegate. And finally some say we can delegate and use existing name collision model until NCAP states otherwise. We hope this makes sense and please forward to the GNSO Council for its consideration. Thanks again for reaching out to us. We are going to forward this correspondence chain to the Full Working Group as well. Best regards, Jeff Neuman and Cheryl Langdon-Orr Subsequent Procedures Co-Chairs 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: Drazek, Keith <kdrazek(a)verisign.com<mailto:kdrazek@verisign.com>> Sent: Monday, September 9, 2019 6:48 PM To: Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>>; Cheryl Langdon-Orr (langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>) (langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>) <langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>> Cc: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>; gnso-chairs(a)icann.org<mailto:gnso-chairs@icann.org> Subject: FW: FOR REVIEW: Draft GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies Jeff/Cheryl, FYI, attached is the draft Council letter to the Board on NCAP and SubPro. This has been sent to the Council list for consideration and comment. Best, Keith From: council <council-bounces(a)gnso.icann.org<mailto:council-bounces@gnso.icann.org>> On Behalf Of Drazek, Keith via council Sent: Monday, September 09, 2019 3:47 PM To: council(a)gnso.icann.org<mailto:council@gnso.icann.org> Cc: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> Subject: [EXTERNAL] [council] FOR REVIEW: Draft GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies Hi all, Attached for your review is a draft letter from the GNSO Council to the ICANN Board concerning dependencies between the NCAP and Subsequent Procedures PDP. Please review and advise if you have any comments or questions. We can discuss on the list and this will be included on the agenda for our 19 September GNSO Council meeting. Thanks, Keith ________________________________ 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<https://comlaude.com>

2 1

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 12 September 2019 at 20:00 UTC
by Julie Hedlund Sept. 10, 2019

Sept. 10, 2019

Dear all, Please find below the proposed agenda for the call on Thursday, 12 September 2019 at 20:00 UTC (*NOTE NEW TIME*) for 90 minutes: 1. Welcome and Updates to Statements of Interest 2. Review of summary documents: a. Role of Application Comment -- See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou…, page 51, Outstanding Items b. Name Collisions -- See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou…, page 55 c. Objections (time permitting) – See: https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-K…, page 2 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

Re: [Gnso-newgtld-wg] Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated
by Rubens Kuhl Sept. 9, 2019

Sept. 9, 2019

> > Jeff sent an email stating that all future applications for the .HOME, .CORP, and .MAIL strings were already banned by the Board resolution. (This was inaccurate and had to be addressed in the attached September 6 email quoting the Board resolution.) Then Rubens sent a note to the list stating that in his opinion, there is no longer a dependency between the Name Collision Analysis Project and the policy being developed by this WG. I wouldn't say "no longer" because I never believed in that. But the no-bid from JAS advisors from study 1 explained why much more eloquently than me, so I don't see how any reasonable analysis could still believe in such dependency. > This is inaccurate because Study 1 of the NCAP is proceeding and there is a half day meeting on that topic in Montreal on Friday November 1. These (very specific) comments from Leadership certainly required specific responses, especially since we will address name collision policy in the upcoming call. Many of the public comments simply state “Defer to the SSAC” so that’s important. The ALAC clarification on this point (from Justine Chew) says the following: The public comments in every ICANN topic, not only in this one, are always biased with more disagreement than agreement. This is natural but doesn't represent that everything should be the other way around. > > I can’t imagine why we would ask the WG to develop policy impacting Applicant Freedom of Expression without looking at the attached list of strings that would enjoy protected status prohibiting future applications by the proposed language. If these 2012 applications are outside the Charter as Rubens asserts, then they are definitely outside the scope of giving them preference by banning future applications for the same string. As Alex points out, “apply at your own risk.” > Name collisions in the CHM applications are outside the charter, but this is totally unrelated to subsequent procedures decision of what to allow to be applied for or not, which is on-topic for the WG. Rubens

1 0

Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated
by Susan Payne Sept. 9, 2019

Sept. 9, 2019

All During a call a couple of weeks ago, when we were discussing application prioritisation, I volunteered to circulate for consideration a proposal to prohibit allowing applications in a later application window where the string has previously been applied for and not yet been delegated. Although it had originally been proposed that this might extend to confusingly similar strings, having reflected on the discussion during the call I accept that this would probably be unrealistic, since confusing similarity needs to be determined as part of the TLD evaluation process. I have therefore limited this proposal to exact match strings, as follows: * This proposal assumes that we will have at least one further application round/open window for submission of applications, and possibly that there may be a number of such future open windows during which applications may be submitted, followed by some closed period when applications are not received, before the next application window opens (I will use the phrase “application submission period”). * Where one or more applicants for a particular TLD string have applied for that string in a prior application submission period (including the 2012 application submission period); and * The TLD has not been withdrawn but has not yet proceeded to delegation for whatever reason, including but not limited to: * One or more of the applications has not yet completed evaluation; * One or more of the applications is still the subject of an objection process * The contention set has not yet been resolved; * There is an ongoing accountability process, [appeal] or other legal challenge underway with respect to a decision(s) relating to one or more application; * Time within which to commence an accountability process, [appeal] or other legal challenge on such a decision is still running; * The exact match to that TLD string shall be blocked from application during future application submission periods until such time as the prior round application(s) have finally been concluded, according the rules under which they applied: * If the TLD string is delegated to one of the earlier applicants, then that string will remain unavailable for later applicants; * If all of the earlier applications are finally rejected, then (provided that a decision has not been made by the Board to permanently refuse that string) the TLD string will once again become available for application: * from the next application submission period, provided that this allows a minimum of 3 months notice before the application submission period opens; or, * If the next application submission period opens in less than 3 months, then the subsequent application submission period. Rationale We know that, many years after the 2012 application submission period closed, there are still a handful of applications for TLD strings which remain unresolved, generally due to delays caused by recourse to ICANNs accountability mechanisms. Whilst we all hope that in subsequent procedures we will have fewer of the challenges that we saw in the 2012 round, it is reasonable to assume that some will still occur. In any event, if subsequent procedures take the form of a series of discrete application submission periods, with known, finite, periods between them, then it is conceivable that applications from one application submission period may still be being processed when then next application submission period opens. If the period between application submission periods is reasonably short (12 months has been discussed, for example) we could conceivably see the added complication of applications for the same string being queued up across multiple windows. Whilst a later applicant who applied unsuccessfully for a TLD, which was eventually allocated to an applicant from a prior application submission period, could expect to recover their application fee, there is a cost to putting together an application in excess of the ICANN fee, and this would not be recoverable. The later applicant could also have their application fee tied up for months or even years, pending the outcome of the earlier application(s). Some have argued that this is the choice of the later applicant, that they can check whether there are prior “live” applications and decide accordingly whether they still want to apply. I believe this does a disservice to potential applicants, particularly those who are not so familiar with all of the history of prior applications and who may not appreciate that in many cases they would have no realistic prospect of being allocated the TLD string that ICANN has allowed them to apply for. Blocking the TLD from application, until such time as the previous applications are resolved, seems a much fairer approach. Susan Payne Head of Legal Policy Valideus ________________________________ 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<https://comlaude.com>

5 12

**update** Meeting invitation: New gTLD Subsequent Procedures Working Group call / Thursday, 12 September 2019 at 03:00 UTC
by Julie Bisland Sept. 7, 2019

Sept. 7, 2019

Dear Kathy, all, Apologies for the confusion, the next meetings are as follows: Thursday, 12 September 2019 at 03:00 UTC for 90 minutes Monday, 16 September 2019 at 15:00 UTC for 90 minutes Thursday, 19 September 2019 at 20:00 UTC for 60 minutes (duration changed due to the GNSO Council call) Best regards, Julie From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Nathalie Peregrine <nathalie.peregrine(a)icann.org> Date: Saturday, September 7, 2019 at 8:57 AM To: Kathy Kleiman <kathy(a)kathykleiman.com>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: Re: [Gnso-newgtld-wg] [Ntfy-gnso-newgtld-wg] Meeting invitation: New gTLD Subsequent Procedures Working Group call / Thursday, 12 September 2019 at 03:00 UTC Dear Kathy, The next SubPro PDP WG call is on the 19th September 2019 at 20:00 UTC. Please let us know if we need to re-send the calendar invitations. You can also see all the SubPro meetings listed on the wiki page<https://community.icann.org/pages/viewpage.action?pageId=102138521> and the GNSO Master Calendar [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>. Thank you, Nathalie From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of "kathy(a)kathykleiman.com" <kathy(a)kathykleiman.com> Reply-To: "kathy(a)kathykleiman.com" <kathy(a)kathykleiman.com> Date: Saturday, September 7, 2019 at 12:47 AM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: Re: [Gnso-newgtld-wg] [Ntfy-gnso-newgtld-wg] Meeting invitation: New gTLD Subsequent Procedures Working Group call / Thursday, 12 September 2019 at 03:00 UTC Hi All (and especially Cheryl and Jeff), Given that this was the time of the call this past Wed night/Thurs AM, I am assuming it will change for next week (9/12). What is the next rotation time? Best, Kathy ----- Original Message ----- From: "Terri Agnew" <terri.agnew(a)icann.org> To: "ntfy-gnso-newgtld-wg(a)icann.org" <ntfy-gnso-newgtld-wg(a)icann.org> Cc: "gnso-secs(a)icann.org" <gnso-secs(a)icann.org> Sent: Fri, 6 Sep 2019 21:04:39 +0000 Subject: [Ntfy-gnso-newgtld-wg] Meeting invitation: New gTLD Subsequent Procedures Working Group call / Thursday, 12 September 2019 at 03:00 UTC Dear all, The details are below for the New gTLD Subsequent Procedures Working Group call on Thursday, 12 September 2019 at 03:00 UTC for 90 minutes. (Wednesday) 20:00 PDT, (Wednesday)23:00 EDT, 05:00 Paris CEST, 08:00 Karachi PKT, 12:00 Tokyo JST, 13:00 Melbourne AEST For other places see: https://tinyurl.com/y4mqnzza [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_y4mqnzza&d…> Agenda wiki page: https://community.icann.org/x/coTkBg Zoom room: https://icann.zoom.us/my/gnso.pdp1 [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_my_gnso.…> You will have VoIP and telecom bridge audio options available to you upon logging in. If you are joining via audio only, please see below. One tap mobile +19294362866,,3107952819# US (New York) +16699006833,,3107952819# US (San Jose) Meeting ID: 310 795 2819 Find your local number: https://zoom.us/u/acwzlz1QoY<https://urldefense.proofpoint.com/v2/url?u=https-3A__zoom.us_u_acwzlz1QoY&d…> Slide 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/presentation/disappe… [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_d…> A calendar invitation has equally been sent and an ical (if your inbox doesn’t receive direct calendar invitations) is available here as attachment for you to download to your calendar. If you require a dial-out or to send apologies (do not send to full working group) please send an email request with your preferred contact number to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> Please let me know if you have any questions. Thank you. Kind regards, Terri

1 0

Re: [Gnso-newgtld-wg] [Ntfy-gnso-newgtld-wg] Meeting invitation: New gTLD Subsequent Procedures Working Group call / Thursday, 12 September 2019 at 03:00 UTC
by Kathy Kleiman Sept. 7, 2019

Sept. 7, 2019

Hi All (and especially Cheryl and Jeff), Given that this was the time of the call this past Wed night/Thurs AM, I am assuming it will change for next week (9/12). What is the next rotation time? Best, Kathy ----- Original Message ----- From: "Terri Agnew" To:"ntfy-gnso-newgtld-wg(a)icann.org" Cc:"gnso-secs(a)icann.org" Sent:Fri, 6 Sep 2019 21:04:39 +0000 Subject:[Ntfy-gnso-newgtld-wg] Meeting invitation: New gTLD Subsequent Procedures Working Group call / Thursday, 12 September 2019 at 03:00 UTC Dear all, The details are below for the New gTLD Subsequent Procedures Working Group call on THURSDAY, 12 SEPTEMBER 2019 AT 03:00 UTC FOR 90 MINUTES. (Wednesday) 20:00 PDT, (Wednesday)23:00 EDT, 05:00 Paris CEST, 08:00 Karachi PKT, 12:00 Tokyo JST, 13:00 Melbourne AEST For other places see: HTTPS://TINYURL.COM/Y4MQNZZA [1] AGENDA WIKI PAGE: HTTPS://COMMUNITY.ICANN.ORG/X/COTKBG [2] ZOOM ROOM: https://icann.zoom.us/my/gnso.pdp1 [icann.zoom.us] [3] You will have VoIP and telecom bridge audio options available to you upon logging in. IF YOU ARE JOINING VIA AUDIO ONLY, PLEASE SEE BELOW. One tap mobile +19294362866,,3107952819# US (New York) +16699006833,,3107952819# US (San Jose) Meeting ID: 310 795 2819 Find your local number: https://zoom.us/u/acwzlz1QoY [4] SLIDE TO ASSIST YOU WITH ZOOM: WELCOME TO ZOOM: https://icann.box.com/shared/static/1sal3l5qf4csdukt0pk2c75ey3bte22z.pdf [5] ZOOM FAQ: https://icann.box.com/shared/static/d5rap0g6xphevhkdd3mhu2hy753l2m3s.pdf [6] IF ZOOM DISAPPEARS, SEE INSTRUCTIONS: https://gnso.icann.org/sites/default/files/policy/2019/presentation/disappe… [7] A calendar invitation has equally been sent and an ical (if your inbox doesn’t receive direct calendar invitations) is available here as attachment for you to download to your calendar. If you require a dial-out or to send apologies (do not send to full working group) please send an email request with your preferred contact number to gnso-secs(a)icann.org [8] Please let me know if you have any questions. Thank you. Kind regards, Terri Links: ------ [1] http://gmmn-6gkh.accessdomain.com/HTTPS://TINYURL.COM/Y4MQNZZA [2] http://gmmn-6gkh.accessdomain.com/HTTPS://COMMUNITY.ICANN.ORG/X/COTKBG [3] https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_my_gnso.… [4] https://urldefense.proofpoint.com/v2/url?u=https-3A__zoom.us_u_acwzlz1QoY&a… [5] https://icann.box.com/shared/static/1sal3l5qf4csdukt0pk2c75ey3bte22z.pdf [6] https://icann.box.com/shared/static/d5rap0g6xphevhkdd3mhu2hy753l2m3s.pdf [7] https://gnso.icann.org/sites/default/files/policy/2019/presentation/disappe… [8] mailto:gnso-secs@icann.org

2 1

Re: [Gnso-newgtld-wg] Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated
by Steve Chan Sept. 6, 2019

Sept. 6, 2019

Dear Anne, Jeff, all, Below, please find the link to our working list of remaining applications. We have consulted with GDD to try and make this list as accurate as possible: https://drive.google.com/a/icann.org/file/d/1R2TgxELfg8uNODJ9akAU8mfBEIIHC0… Note that two strings have been removed from this list because they are in the Transition to Delegation phase (.LLP and .CPA). Best, Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Thursday, September 5, 2019 at 11:47 AM To: Jeff Neuman <jeff.neuman(a)comlaude.com>, Susan Payne <susan.payne(a)valideus.com> Cc: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: Re: [Gnso-newgtld-wg] Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated Jeff – You had said you were waiting on GDD approval of the list. Can we have the link to that? Re second question, hard to evaluate a proposal to prohibit new applications for the same strings when we don’t know which applications we are discussing. From: Jeff Neuman <jeff.neuman(a)comlaude.com> Sent: Thursday, September 5, 2019 11:02 AM To: Aikman-Scalese, Anne <AAikman(a)lrrc.com>; Susan Payne <susan.payne(a)valideus.com> Cc: gnso-newgtld-wg(a)icann.org Subject: RE: Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated [EXTERNAL] Anne, I am not sure what you mean by the “GDD approved list of strings that may still be in play from 2012”? We have published a status chart of where everything from 2012, which will need one update (if it has not been already), as I understand .llp may be signed now. I am also not clear on what you mean by concurrent evaluation of these proposals. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com From: Aikman-Scalese, Anne <AAikman(a)lrrc.com> Sent: Thursday, September 5, 2019 1:52 PM To: Jeff Neuman <jeff.neuman(a)comlaude.com>; Susan Payne <susan.payne(a)valideus.com> Cc: gnso-newgtld-wg(a)icann.org Subject: RE: Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated Thanks Jeff. I was under the impression that since there was no consensus evident on Proposal 1, Susan would be drafting proposal 2 for consideration. Separately, I don’t see how any WG member can reflect properly on either proposal without the GDD approved list of strings that may still be in play from 2012. Will that be coming in time for concurrent evaluation of these proposals? Anne From: Jeff Neuman <jeff.neuman(a)comlaude.com> Sent: Wednesday, September 4, 2019 12:10 PM To: Aikman-Scalese, Anne <AAikman(a)lrrc.com>; Susan Payne <susan.payne(a)valideus.com> Cc: gnso-newgtld-wg(a)icann.org Subject: RE: Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated [EXTERNAL] Anne, During the call that Susan is referring to Susan volunteered to draft some language to flesh out her proposal. And although it did not seem to have a huge amount of support on that call, she was asked to send the proposal around to the list to see if it has traction. As you have pointed out, decisions are not generally made with just one phone call. Discussions can and should happen on the mailing list. Susan has responded with her proposal on the list and we can see which version has support. The options are: Prohibit Applications for strings where the applications are still pending (for whatever reason) – As per Susan’s proposal; or Allow applications in for those strings, but do not process them any further than the reveal stage, unless and/or until the applications from the previous round that match those strings have had their final disposition. Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Aikman-Scalese, Anne Sent: Tuesday, September 3, 2019 7:09 PM To: Susan Payne <susan.payne(a)valideus.com> Cc: gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated Susan – sorry for the confusion but based on Jeff’s request, I had understood you were “fleshing out” the part that the WG might be able to agree on – which was that prior round applications should be “completed” prior to subsequent round applications for the same string being considered. I’m pretty sure the recording will confirm this. Anne From: Susan Payne <susan.payne(a)valideus.com> Sent: Tuesday, September 3, 2019 4:06 PM To: Aikman-Scalese, Anne <AAikman(a)lrrc.com> Cc: gnso-newgtld-wg(a)icann.org Subject: Re: Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated [EXTERNAL] Anne, This is based on the comments that my company and INTA had made. I was asked on the call, including by you, to flesh this out so that the group could see what such a proposal would look like, and whether it would garner sufficient support. Here it is. Sent from my iPad On 3 Sep 2019, at 17:57, Aikman-Scalese, Anne <AAikman(a)lrrc.com> wrote: Hi Susan. This is a bit confusing. I recall that Jeff noted there was no high level agreement for this proposition. Rather he stated there could be high level agreement that strings from prior rounds must complete application evaluation prior to consideration of subsequent round applications for the same string. He has since confirmed that in a post to the list. How did we get to a proposal for “no applications for the same string?” Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Susan Payne Sent: Tuesday, September 3, 2019 3:54 PM To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated [EXTERNAL] All During a call a couple of weeks ago, when we were discussing application prioritisation, I volunteered to circulate for consideration a proposal to prohibit allowing applications in a later application window where the string has previously been applied for and not yet been delegated. Although it had originally been proposed that this might extend to confusingly similar strings, having reflected on the discussion during the call I accept that this would probably be unrealistic, since confusing similarity needs to be determined as part of the TLD evaluation process. I have therefore limited this proposal to exact match strings, as follows: This proposal assumes that we will have at least one further application round/open window for submission of applications, and possibly that there may be a number of such future open windows during which applications may be submitted, followed by some closed period when applications are not received, before the next application window opens (I will use the phrase “application submission period”). Where one or more applicants for a particular TLD string have applied for that string in a prior application submission period (including the 2012 application submission period); and The TLD has not been withdrawn but has not yet proceeded to delegation for whatever reason, including but not limited to: One or more of the applications has not yet completed evaluation; One or more of the applications is still the subject of an objection process The contention set has not yet been resolved; There is an ongoing accountability process, [appeal] or other legal challenge underway with respect to a decision(s) relating to one or more application; Time within which to commence an accountability process, [appeal] or other legal challenge on such a decision is still running; The exact match to that TLD string shall be blocked from application during future application submission periods until such time as the prior round application(s) have finally been concluded, according the rules under which they applied: If the TLD string is delegated to one of the earlier applicants, then that string will remain unavailable for later applicants; If all of the earlier applications are finally rejected, then (provided that a decision has not been made by the Board to permanently refuse that string) the TLD string will once again become available for application: from the next application submission period, provided that this allows a minimum of 3 months notice before the application submission period opens; or, If the next application submission period opens in less than 3 months, then the subsequent application submission period. Rationale We know that, many years after the 2012 application submission period closed, there are still a handful of applications for TLD strings which remain unresolved, generally due to delays caused by recourse to ICANNs accountability mechanisms. Whilst we all hope that in subsequent procedures we will have fewer of the challenges that we saw in the 2012 round, it is reasonable to assume that some will still occur. In any event, if subsequent procedures take the form of a series of discrete application submission periods, with known, finite, periods between them, then it is conceivable that applications from one application submission period may still be being processed when then next application submission period opens. If the period between application submission periods is reasonably short (12 months has been discussed, for example) we could conceivably see the added complication of applications for the same string being queued up across multiple windows. Whilst a later applicant who applied unsuccessfully for a TLD, which was eventually allocated to an applicant from a prior application submission period, could expect to recover their application fee, there is a cost to putting together an application in excess of the ICANN fee, and this would not be recoverable. The later applicant could also have their application fee tied up for months or even years, pending the outcome of the earlier application(s). Some have argued that this is the choice of the later applicant, that they can check whether there are prior “live” applications and decide accordingly whether they still want to apply. I believe this does a disservice to potential applicants, particularly those who are not so familiar with all of the history of prior applications and who may not appreciate that in many cases they would have no realistic prospect of being allocated the TLD string that ICANN has allowed them to apply for. Blocking the TLD from application, until such time as the previous applications are resolved, seems a much fairer approach. Susan Payne Head of Legal Policy Valideus 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 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. 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 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. 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 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. 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 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.

5 6

Notes on Registry Services
by Rubens Kuhl Sept. 6, 2019

Sept. 6, 2019

Since I'm not sure I'll be able to join the call in a few hours that will discuss registry services, I will post here some WT4 and RA context regarding some of the comments: - GPML When this topic was being discussed in WT4, the then-current draft of what currently is the Fast-Track RSEP process (https://www.icann.org/resources/pages/fast-track-rsep-process-authorization…) included protected marks list services, but not mentioned as GPML. I used GPML as a token to represent that in order to avoid personalising to one specific registry that is known for providing such PML services... if that list was to be updated, it would read (BTAPPA, Registration Validation per Applicable Law, Registry Lock, IDN Languages) instead of (IDN Languages, GPML, BTAPPA), so one decision for the WG is whether to update the list or to remove the list altogether, since the idea is to reference the Fast-Track process anyways. (This also covers a couple suggestions to add Registration Validation to that list) - Pre-approved services All 2012 registry agreements include a set of pre-approved services that are basic to registry operation, like DNS publication, accepting registrations etc.; so, the discussion is whether this list can be increased, not if such a list could exist. It already exists. - Disclosure of new services In 2012, there was no blocking in the registry agreement to use RSEPs later during the life of the TLD, and the RSEP site contains a number of RSEPs that were approved and incorporated new services into the registry agreements. Since revising the RSEP policy is outside of the WG purview, no SubPro policy can have any effect on that freedom of innovation. We can write anything someone wants in the SubPro policy and that won't change. - ICANN Org interpretation It seems ICANN Org misinterpreted the idea of pre-approved services; pre-approved services means that no registry service evaluation will be made for them, and any evaluation of those services could only happen in other contexts like Technical/Operational evaluation. It's not just a change of label for the process, it's not evaluating those services at all from a registry services perspective, but indeed possibly considering them in other angles of the evaluation. - Overload of RSEP acronyms Because RSEP is used to imply Registry Services Evaluation Procedure, Evaluation Process or Evaluation Policy depending on reference, the term is very loaded to the point that some comments said RSEP Policy shouldn't be changed. The use of RSEP in the WT4 output refers to the process, not to the policy that is used to evaluate new registry services after a TLD is contracted with ICANN. - Moment of registry service evaluation What's currently in the draft was an attempt to have the more transparency and freedom of innovation as possible in the application, by allowing services that would only be applied after contract signing to be described by the applicant. Taking that out only causes less transparency; the more information is published, the more something can trigger application comments or objections. Rubens

4 9

Re: [Gnso-newgtld-wg] Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated
by Alexander Schubert Sept. 5, 2019

Sept. 5, 2019

On first glimpse that LOOKS like a lot of strings.But then a ton of these are "dead": either clinical dead (won't go anywhere but not withdrawn); or delegated to another applicant - and not withdrawn.In order to avoid a Zombi invasion: shouldn't ICANN at some point be able to "withdraw" such applications?If you look at those that might have ANY path forward - it's remarkable few and quite similar to my 5 minute list.The mere fact that it took ICANN that long to compile the list shows me:For the next rounds we need a (much shorter) list of not yet resolved strings; PUBLICLY available.Thanks to staff. Good work.AlexanderSent from my Samsung device -------- Original message -------- From: Steve Chan <steve.chan(a)icann.org> Date: 9/5/19 22:54 (GMT+02:00) To: "Aikman-Scalese, Anne" <AAikman(a)lrrc.com>, Jeff Neuman <jeff.neuman(a)comlaude.com>, Susan Payne <susan.payne(a)valideus.com> Cc: gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated Dear Anne, Jeff, all, Below, please find the link to our working list of remaining applications. We have consulted with GDD to try and make this list as accurate as possible: https://drive.google.com/a/icann.org/file/d/1R2TgxELfg8uNODJ9akAU8mfBEIIHC0… Note that two strings have been removed from this list because they are in the Transition to Delegation phase (.LLP and .CPA). Best,Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of "Aikman-Scalese, Anne" <AAikman(a)lrrc.com>Date: Thursday, September 5, 2019 at 11:47 AMTo: Jeff Neuman <jeff.neuman(a)comlaude.com>, Susan Payne <susan.payne(a)valideus.com>Cc: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org>Subject: Re: [Gnso-newgtld-wg] Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated Jeff – You had said you were waiting on GDD approval of the list. Can we have the link to that? Re second question, hard to evaluate a proposal to prohibit new applications for the same strings when we don’t know which applications we are discussing. From: Jeff Neuman <jeff.neuman(a)comlaude.com> Sent: Thursday, September 5, 2019 11:02 AMTo: Aikman-Scalese, Anne <AAikman(a)lrrc.com>; Susan Payne <susan.payne(a)valideus.com>Cc: gnso-newgtld-wg(a)icann.orgSubject: RE: Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated [EXTERNAL]Anne, I am not sure what you mean by the “GDD approved list of strings that may still be in play from 2012”? We have published a status chart of where everything from 2012, which will need one update (if it has not been already), as I understand .llp may be signed now. I am also not clear on what you mean by concurrent evaluation of these proposals. Jeff NeumanSenior Vice President Com Laude | ValideusD: +1.703.635.7514E: jeff.neuman(a)comlaude.com From: Aikman-Scalese, Anne <AAikman(a)lrrc.com> Sent: Thursday, September 5, 2019 1:52 PMTo: Jeff Neuman <jeff.neuman(a)comlaude.com>; Susan Payne <susan.payne(a)valideus.com>Cc: gnso-newgtld-wg(a)icann.orgSubject: RE: Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated Thanks Jeff. I was under the impression that since there was no consensus evident on Proposal 1, Susan would be drafting proposal 2 for consideration. Separately, I don’t see how any WG member can reflect properly on either proposal without the GDD approved list of strings that may still be in play from 2012. Will that be coming in time for concurrent evaluation of these proposals?Anne From: Jeff Neuman <jeff.neuman(a)comlaude.com> Sent: Wednesday, September 4, 2019 12:10 PMTo: Aikman-Scalese, Anne <AAikman(a)lrrc.com>; Susan Payne <susan.payne(a)valideus.com>Cc: gnso-newgtld-wg(a)icann.orgSubject: RE: Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated [EXTERNAL]Anne, During the call that Susan is referring to Susan volunteered to draft some language to flesh out her proposal. And although it did not seem to have a huge amount of support on that call, she was asked to send the proposal around to the list to see if it has traction. As you have pointed out, decisions are not generally made with just one phone call. Discussions can and should happen on the mailing list. Susan has responded with her proposal on the list and we can see which version has support. The options are: Prohibit Applications for strings where the applications are still pending (for whatever reason) – As per Susan’s proposal; orAllow applications in for those strings, but do not process them any further than the reveal stage, unless and/or until the applications from the previous round that match those strings have had their final disposition. Jeff NeumanSenior Vice President Com Laude | ValideusD: +1.703.635.7514E: jeff.neuman(a)comlaude.com From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Aikman-Scalese, AnneSent: Tuesday, September 3, 2019 7:09 PMTo: Susan Payne <susan.payne(a)valideus.com>Cc: gnso-newgtld-wg(a)icann.orgSubject: Re: [Gnso-newgtld-wg] Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated Susan – sorry for the confusion but based on Jeff’s request, I had understood you were “fleshing out” the part that the WG might be able to agree on – which was that prior round applications should be “completed” prior to subsequent round applications for the same string being considered. I’m pretty sure the recording will confirm this.Anne From: Susan Payne <susan.payne(a)valideus.com> Sent: Tuesday, September 3, 2019 4:06 PMTo: Aikman-Scalese, Anne <AAikman(a)lrrc.com>Cc: gnso-newgtld-wg(a)icann.orgSubject: Re: Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated [EXTERNAL]Anne, This is based on the comments that my company and INTA had made. I was asked on the call, including by you, to flesh this out so that the group could see what such a proposal would look like, and whether it would garner sufficient support. Here it is. Sent from my iPadOn 3 Sep 2019, at 17:57, Aikman-Scalese, Anne <AAikman(a)lrrc.com> wrote:Hi Susan. This is a bit confusing. I recall that Jeff noted there was no high level agreement for this proposition. Rather he stated there could be high level agreement that strings from prior rounds must complete application evaluation prior to consideration of subsequent round applications for the same string. He has since confirmed that in a post to the list. How did we get to a proposal for “no applications for the same string?”Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Susan PayneSent: Tuesday, September 3, 2019 3:54 PMTo: gnso-newgtld-wg(a)icann.orgSubject: [Gnso-newgtld-wg] Proposal on Prioritising Applications - prohibition on applying in a later round for a string from a prior round which has not yet been delegated [EXTERNAL] AllDuring a call a couple of weeks ago, when we were discussing application prioritisation, I volunteered to circulate for consideration a proposal to prohibit allowing applications in a later application window where the string has previously been applied for and not yet been delegated. Although it had originally been proposed that this might extend to confusingly similar strings, having reflected on the discussion during the call I accept that this would probably be unrealistic, since confusing similarity needs to be determined as part of the TLD evaluation process. I have therefore limited this proposal to exact match strings, as follows:This proposal assumes that we will have at least one further application round/open window for submission of applications, and possibly that there may be a number of such future open windows during which applications may be submitted, followed by some closed period when applications are not received, before the next application window opens (I will use the phrase “application submission period”).Where one or more applicants for a particular TLD string have applied for that string in a prior application submission period (including the 2012 application submission period); andThe TLD has not been withdrawn but has not yet proceeded to delegation for whatever reason, including but not limited to: One or more of the applications has not yet completed evaluation;One or more of the applications is still the subject of an objection processThe contention set has not yet been resolved;There is an ongoing accountability process, [appeal] or other legal challenge underway with respect to a decision(s) relating to one or more application;Time within which to commence an accountability process, [appeal] or other legal challenge on such a decision is still running;The exact match to that TLD string shall be blocked from application during future application submission periods until such time as the prior round application(s) have finally been concluded, according the rules under which they applied: If the TLD string is delegated to one of the earlier applicants, then that string will remain unavailable for later applicants;If all of the earlier applications are finally rejected, then (provided that a decision has not been made by the Board to permanently refuse that string) the TLD string will once again become available for application: from the next application submission period, provided that this allows a minimum of 3 months notice before the application submission period opens; or, If the next application submission period opens in less than 3 months, then the subsequent application submission period. RationaleWe know that, many years after the 2012 application submission period closed, there are still a handful of applications for TLD strings which remain unresolved, generally due to delays caused by recourse to ICANNs accountability mechanisms. Whilst we all hope that in subsequent procedures we will have fewer of the challenges that we saw in the 2012 round, it is reasonable to assume that some will still occur. In any event, if subsequent procedures take the form of a series of discrete application submission periods, with known, finite, periods between them, then it is conceivable that applications from one application submission period may still be being processed when then next application submission period opens. If the period between application submission periods is reasonably short (12 months has been discussed, for example) we could conceivably see the added complication of applications for the same string being queued up across multiple windows. Whilst a later applicant who applied unsuccessfully for a TLD, which was eventually allocated to an applicant from a prior application submission period, could expect to recover their application fee, there is a cost to putting together an application in excess of the ICANN fee, and this would not be recoverable. The later applicant could also have their application fee tied up for months or even years, pending the outcome of the earlier application(s). Some have argued that this is the choice of the later applicant, that they can check whether there are prior “live” applications and decide accordingly whether they still want to apply. I believe this does a disservice to potential applicants, particularly those who are not so familiar with all of the history of prior applications and who may not appreciate that in many cases they would have no realistic prospect of being allocated the TLD string that ICANN has allowed them to apply for. Blocking the TLD from application, until such time as the previous applications are resolved, seems a much fairer approach. Susan Payne Head of Legal PolicyValideus 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 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. 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 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. 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 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. 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 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.

1 0