September 2019 - Gnso-newgtld-wg

**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

Re: [Gnso-newgtld-wg] [NCAP-Discuss] Fwd: [Ext] JAS no-bid on NCAP Study 1 - BUT THERE IS ONE OTHER BID
by Rubens Kuhl Sept. 5, 2019

Sept. 5, 2019

> Em 5 de set de 2019, à(s) 15:03:000, Aikman-Scalese, Anne <AAikman(a)lrrc.com> escreveu: > > Dear List, > Regarding the message from Rubens and the message from JAS Advisors, > > 1. There is, as far as I know as a member of the NCAP Discussion Group, at least one response to the RFP on Study 1 for the Name Collision Analysis Project, so there is a dependency to Sub Pro recommendations. ( The assertion that there is such a dependency is only Anne's opinion. > NCAP Recommendations will go directly to the Board as well but Rubens and Jeff are both members of the NCAP Discussion Group. Jeff has stated that his purpose is to coordinate with them.) > > 2. I note that JAS Advisors says in its email that its Final Report on Name Collisions stands and Rubens has made some points about that. I don’t recall Work Track 4 actually taking the time to review that report in full. A copy is attached. That report was one of the many materials reviewed by WT4. > > 3. I have also taken a section from the Final Report and its recommendations that is referred to by JAS in the new email in its discussion of .corp and other high risk strings. It’s clear JAS recommended total reservation of .HOME, .CORP, and .MAIL in its Final Report, I don't agree with that interpretation regarding CHM TLDs, but this is not a topic for SubPro so I'll let JAS state their positions in NCAP discussions. > i.e. that none of these be delegated going forward. And it’s clear from the email that JAS recommends a way of identifying similar high risk strings be developed. I think Work Track 4 referred to this in its tentative recommendations as “developing a DO NOT APPLY” list. I think the JAS recommendation goes broader then the "DO NOT APPLY" list, but yes, the ideas are very compatible. > The Final Report is very long – but the summary of recommendations appears early on. These are worth your consideration prior to the Monday call. While there are other materials in the WT4 wiki, this one is indeed a worthy reading. Rubens > > Thank you, > Anne > > > > From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Jeff Neuman > Sent: Wednesday, September 4, 2019 12:04 PM > To: Rubens Kuhl <rubensk(a)nic.br <mailto:rubensk@nic.br>>; gnso-newgtld-wg(a)icann.org <mailto:gnso-newgtld-wg@icann.org> > Subject: Re: [Gnso-newgtld-wg] [NCAP-Discuss] Fwd: [Ext] JAS no-bid on NCAP Study 1 > > [EXTERNAL] > Thanks Rubens for forwarding all of the communication. Please note that Name Collisions is on our agenda most likely next Monday if all goes according to the Work Plan. > > 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 Rubens Kuhl > Sent: Wednesday, September 4, 2019 10:38 AM > To: gnso-newgtld-wg(a)icann.org <mailto:gnso-newgtld-wg@icann.org> > Subject: Re: [Gnso-newgtld-wg] [NCAP-Discuss] Fwd: [Ext] JAS no-bid on NCAP Study 1 > > > As a follow-up, there is an interesting thread of discussions in the NCAP list regarding this topic after the message I forwarded; it can be followed even by non-subscribers using the list archive: > https://mm.icann.org/pipermail/ncap-discuss/2019-September/thread.html <https://mm.icann.org/pipermail/ncap-discuss/2019-September/thread.html> > > > > Rubens > > > > > > > Em 3 de set de 2019, à(s) 18:18:000, Rubens Kuhl <rubensk(a)nic.br <mailto:rubensk@nic.br>> escreveu: > > > This message distributed in the name collisions project list touches 3 discussion topics from WT4 and the full WG: > - JAS Advisors believe the NCAP Study 1 provides no actual new content. I agree with their assessment, and already factored that in my opinion that there is no dependency between NCAP and SubPro for the policy part, even though is possible that NCAP studies 2 and 3, if they are ever commissioned, could interrelate in implementation. > - JAS Advisors makes a suggestion regarding the next procedures that we can check if it was already factored or not in the report or already mentioned by any other commenter. > - JAS Advisors makes a point regarding a topic that is in our charter but hasn't been discussed so far, name collisions in current gTLDs. > > > Rubens > > > > Início da mensagem encaminhada: > > De: Matt Larson <matt.larson(a)icann.org <mailto:matt.larson@icann.org>> > Assunto: [NCAP-Discuss] Fwd: [Ext] JAS no-bid on NCAP Study 1 > Data: 3 de setembro de 2019 13:47:32 BRT > Para: "ncap-discuss(a)icann.org <mailto:ncap-discuss@icann.org>" <ncap-discuss(a)icann.org <mailto:ncap-discuss@icann.org>> > > Dear colleagues, > > David Conrad and I thought the email below from Jeff Schmidt (who is known to most of you based on his firm's previous work on name collisions) was worth forwarding to this group, which we are doing with Jeff's permission. > > Matt > > > > Begin forwarded message: > > From: Jeff Schmidt <jschmidt(a)jasadvisors.com <mailto:jschmidt@jasadvisors.com>> > Subject: [Ext] JAS no-bid on NCAP Study 1 > Date: August 27, 2019 at 11:25:49 AM EDT > To: Roy Arends <roy.arends(a)icann.org <mailto:roy.arends@icann.org>>, Matt Larson <matt.larson(a)icann.org <mailto:matt.larson@icann.org>>, David Conrad <david.conrad(a)icann.org <mailto:david.conrad@icann.org>> > > Hello Team ICANN! > > JAS elected not to bid on the NCAP Study 1; thank you for the invitation and please keep us in mind for Study 2 if such a study occurs. > > Our primary rationale for not bidding on Study 1 is simply that we don’t believe we have anything useful to add to the discussion given the limited scope of Study 1. We believe that at this point DNS namespace collisions are well understood (albeit by a relatively small technical community) and that any further work product from JAS would largely be a restatement of our October 2015 Final Report. In the three years since our Final Report, our conclusions have been shown to be largely correct and the mitigation strategy we proposed (“Controlled Interruption”) has had the desired effects. Many TLDs have been delegated and used in a variety of fashions at this point and – as we suggested – the few problems that surfaced were isolated and not serious. Our definition of DNS namespace collisions and the causes/etiology as described in Sections 4 and 5 of our report still hold. At the end of the day, we can’t take your money if we don’t believe we have anything useful to add. ;-) > > The one glaring failure and our great disappointment is that the IETF has refused to take-up our Recommendation #1 to clearly create an RFC 1918-like protected namespace for local use. Until this happens, DNS namespace collisions will continue to occur; however, increased awareness should reduce the risk of widespread serious future problems (with the “corp-like” exception noted below). Given the lack of clarity of RFC 6762 (including errata), this issue will persist until folks are told unambiguously the *right* way to do this. > > We believe the datasets available to research collisions are also fairly well known – the DNS-OARC DITL data, data that may be made available from large recursive operators, and authoritative data acquired by acquiring/hosting known colliding domains (the 30+ such domains JAS owns, Mike O’Connor’s corp.com <http://corp.com/>, etc). While these datasets have been available for years, extremely limited research interest (essentially zero) has been shown in collision-related topics. > > JAS remains concerned about the security implications of a small number of “special” domains – like .corp – including the ones that have not yet been discovered. The special nature of the string “corp” was not predictable a-priori and highly esoteric; all future TLD application rounds should contain steps to identify potential corp-like “special” strings requiring exceptional treatment. JAS also remains concerned about the practice of “drop catching” which is essentially the intentional discovery and monetization of DNS namespace collisions and referenced this practice in our Final report and in Recommendation #14. We would very much appreciate the opportunity to assist with these issues at some future point. > > Happy to chat further feel free to reach out of course; just wanted to make sure I closed the loop since you invited a bid from us. Please do let whomever you select to perform Study 1 know that we’re happy to chat with them and provide whatever historical information/assistance we can. > > Thank you! > Jeff > > _______________________________________________ > NCAP-Discuss mailing list > NCAP-Discuss(a)icann.org <mailto:NCAP-Discuss@icann.org> > https://mm.icann.org/mailman/listinfo/ncap-discuss <https://mm.icann.org/mailman/listinfo/ncap-discuss> > > _______________________________________________ > By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. > > _______________________________________________ > Gnso-newgtld-wg mailing list > Gnso-newgtld-wg(a)icann.org <mailto:Gnso-newgtld-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg> > _______________________________________________ > By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. > > 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/> > > 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

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 Jamie Baxter Sept. 5, 2019

Sept. 5, 2019

3 2

Re: [Gnso-newgtld-wg] [NCAP-Discuss] Fwd: [Ext] JAS no-bid on NCAP Study 1 - BUT THERE IS ONE OTHER BID
by Aikman-Scalese, Anne Sept. 5, 2019

Sept. 5, 2019

Dear List, Regarding the message from Rubens and the message from JAS Advisors, 1. There is, as far as I know as a member of the NCAP Discussion Group, at least one response to the RFP on Study 1 for the Name Collision Analysis Project, so there is a dependency to Sub Pro recommendations. (NCAP Recommendations will go directly to the Board as well but Rubens and Jeff are both members of the NCAP Discussion Group. Jeff has stated that his purpose is to coordinate with them.) 2. I note that JAS Advisors says in its email that its Final Report on Name Collisions stands and Rubens has made some points about that. I don’t recall Work Track 4 actually taking the time to review that report in full. A copy is attached. 3. I have also taken a section from the Final Report and its recommendations that is referred to by JAS in the new email in its discussion of .corp and other high risk strings. It’s clear JAS recommended total reservation of .HOME, .CORP, and .MAIL in its Final Report, i.e. that none of these be delegated going forward. And it’s clear from the email that JAS recommends a way of identifying similar high risk strings be developed. I think Work Track 4 referred to this in its tentative recommendations as “developing a DO NOT APPLY” list. The Final Report is very long – but the summary of recommendations appears early on. These are worth your consideration prior to the Monday call. Thank you, Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Jeff Neuman Sent: Wednesday, September 4, 2019 12:04 PM To: Rubens Kuhl <rubensk(a)nic.br>; gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] [NCAP-Discuss] Fwd: [Ext] JAS no-bid on NCAP Study 1 [EXTERNAL] ________________________________ Thanks Rubens for forwarding all of the communication. Please note that Name Collisions is on our agenda most likely next Monday if all goes according to the Work Plan. 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 Rubens Kuhl Sent: Wednesday, September 4, 2019 10:38 AM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] [NCAP-Discuss] Fwd: [Ext] JAS no-bid on NCAP Study 1 As a follow-up, there is an interesting thread of discussions in the NCAP list regarding this topic after the message I forwarded; it can be followed even by non-subscribers using the list archive: https://mm.icann.org/pipermail/ncap-discuss/2019-September/thread.html Rubens Em 3 de set de 2019, à(s) 18:18:000, Rubens Kuhl <rubensk(a)nic.br<mailto:rubensk@nic.br>> escreveu: This message distributed in the name collisions project list touches 3 discussion topics from WT4 and the full WG: - JAS Advisors believe the NCAP Study 1 provides no actual new content. I agree with their assessment, and already factored that in my opinion that there is no dependency between NCAP and SubPro for the policy part, even though is possible that NCAP studies 2 and 3, if they are ever commissioned, could interrelate in implementation. - JAS Advisors makes a suggestion regarding the next procedures that we can check if it was already factored or not in the report or already mentioned by any other commenter. - JAS Advisors makes a point regarding a topic that is in our charter but hasn't been discussed so far, name collisions in current gTLDs. Rubens Início da mensagem encaminhada: De: Matt Larson <matt.larson(a)icann.org<mailto:matt.larson@icann.org>> Assunto: [NCAP-Discuss] Fwd: [Ext] JAS no-bid on NCAP Study 1 Data: 3 de setembro de 2019 13:47:32 BRT Para: "ncap-discuss(a)icann.org<mailto:ncap-discuss@icann.org>" <ncap-discuss(a)icann.org<mailto:ncap-discuss@icann.org>> Dear colleagues, David Conrad and I thought the email below from Jeff Schmidt (who is known to most of you based on his firm's previous work on name collisions) was worth forwarding to this group, which we are doing with Jeff's permission. Matt Begin forwarded message: From: Jeff Schmidt <jschmidt(a)jasadvisors.com<mailto:jschmidt@jasadvisors.com>> Subject: [Ext] JAS no-bid on NCAP Study 1 Date: August 27, 2019 at 11:25:49 AM EDT To: Roy Arends <roy.arends(a)icann.org<mailto:roy.arends@icann.org>>, Matt Larson <matt.larson(a)icann.org<mailto:matt.larson@icann.org>>, David Conrad <david.conrad(a)icann.org<mailto:david.conrad@icann.org>> Hello Team ICANN! JAS elected not to bid on the NCAP Study 1; thank you for the invitation and please keep us in mind for Study 2 if such a study occurs. Our primary rationale for not bidding on Study 1 is simply that we don’t believe we have anything useful to add to the discussion given the limited scope of Study 1. We believe that at this point DNS namespace collisions are well understood (albeit by a relatively small technical community) and that any further work product from JAS would largely be a restatement of our October 2015 Final Report. In the three years since our Final Report, our conclusions have been shown to be largely correct and the mitigation strategy we proposed (“Controlled Interruption”) has had the desired effects. Many TLDs have been delegated and used in a variety of fashions at this point and – as we suggested – the few problems that surfaced were isolated and not serious. Our definition of DNS namespace collisions and the causes/etiology as described in Sections 4 and 5 of our report still hold. At the end of the day, we can’t take your money if we don’t believe we have anything useful to add. ;-) The one glaring failure and our great disappointment is that the IETF has refused to take-up our Recommendation #1 to clearly create an RFC 1918-like protected namespace for local use. Until this happens, DNS namespace collisions will continue to occur; however, increased awareness should reduce the risk of widespread serious future problems (with the “corp-like” exception noted below). Given the lack of clarity of RFC 6762 (including errata), this issue will persist until folks are told unambiguously the *right* way to do this. We believe the datasets available to research collisions are also fairly well known – the DNS-OARC DITL data, data that may be made available from large recursive operators, and authoritative data acquired by acquiring/hosting known colliding domains (the 30+ such domains JAS owns, Mike O’Connor’s corp.com<http://corp.com/>, etc). While these datasets have been available for years, extremely limited research interest (essentially zero) has been shown in collision-related topics. JAS remains concerned about the security implications of a small number of “special” domains – like .corp – including the ones that have not yet been discovered. The special nature of the string “corp” was not predictable a-priori and highly esoteric; all future TLD application rounds should contain steps to identify potential corp-like “special” strings requiring exceptional treatment. JAS also remains concerned about the practice of “drop catching” which is essentially the intentional discovery and monetization of DNS namespace collisions and referenced this practice in our Final report and in Recommendation #14. We would very much appreciate the opportunity to assist with these issues at some future point. Happy to chat further feel free to reach out of course; just wanted to make sure I closed the loop since you invited a bid from us. Please do let whomever you select to perform Study 1 know that we’re happy to chat with them and provide whatever historical information/assistance we can. Thank you! Jeff _______________________________________________ NCAP-Discuss mailing list NCAP-Discuss(a)icann.org<mailto:NCAP-Discuss@icann.org> https://mm.icann.org/mailman/listinfo/ncap-discuss _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg(a)icann.org<mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. ________________________________ 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> ________________________________ 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

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 05 September 2019
by Julie Hedlund Sept. 5, 2019

Sept. 5, 2019

Dear Working Group members, Please see below the notes from the meeting on 05 September 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2019-09-05+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: Registry Services: ACTION ITEM 1 re: NCSG divergence, page 47 re: Interpreting that the divergence is not with the inclusion of certain services as approved registry services, it is it is an objection to one particular service – the Globally Protected Marks List -- under rights protection. Follow up with RPM PDP WG to see if they are discussing this issue, if not, add it to our discussion. ACTION ITEM 2 re: ICANN Org comment, page 47: Possible new high-level agreement: (ICANN Org comment) it would be helpful for us to make the recommendation that the implementation team revise the RSEP workflow to fit within the new gTLD processes and timelines and then put these as a couple of the examples -- (i.e., using priority number to order evaluation, using clarifying questions to address issues). ACTION ITEM 3 re: Question: Can we refine the reference to previously approved registry services that will be included by reference in the applicant guidebook and registry agreement to make it clear which services will be included in the applicant guidebook and which will be included in the RA? Answer: Certainly in the RA which is included with the AGB. We need to decide one way or the other. ACTION ITEM 4 re: IPC: Language of Question 23 required disclosure of new services. That requirement should not be changed since it is essential to evaluation. Check with IPC. ACTION ITEM 5 re: Additional fees associated with evaluations: MARQUES Comment: Supports a base application fee which all applicants should pay for standard evaluation with supplementary / top up fees paid for more detailed evaluation. Move to the discussion on fees. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review of summary document – See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou… a. Applicant Reviews: Technical/Operational, Financial and Registry Services (continued discussion, Registry Services on page 46) See also: https://newgtlds.icann.org/sites/default/files/agreements/agreement-approve…, EXHIBIT A: Approved Services, pages 40 and 41. Please also see the web page at: https://www.icann.org/resources/pages/registries/registries-agreements-en Overview of Registry Services: -- Important to take a step back and do make sure everyone's on the same page so that when we go through the comments will see why some of the comments may be a little bit off the mark because they are not operating from the same page, or they may think that we're talking about something that we're not. -- “Registry Services” has a very specific definition in the agreement. -- Definition of “Registry Services” is defined in Specification 6: “a) those services that are operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry DNS servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by this Agreement; (b) other products or services that the Registry Operator is required to provide because of the establishment of a Consensus Policy as defined in Specification 1; (c) any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator; and (d) material changes to any Registry Service within the scope of (a), (b) or (c) above” -- See Exhibit A, Approved Services, page 40, number 1 is DNS Service – TLD Zone Contents. -- As an example, look at .family. -- On the chat people are indicating internationalized domain names. So there were two ways to get internationalized domain names into the agreement if a registry operator had proposed in its application that it was going to have languages as part of its service offering. Then at the time of signing the contract registries were given this language which is pretty much a template for all registries. 3.1, 3.2, and 3.3 is where they would list the languages that they have in the application. Now the second way was to have or subsequently to submit a request at a later point in time to add additional languages. -- And the way that I can add internationalized domain names is through a what's now called and very recently called sort of a fast track: Registry services evaluation requests. The reason it's fast track is it's a service that's pretty easy to add to a contract. -- A lot of amendments are done to add languages. -- So the services that fall under Category C and the definition of registry services are all going to be here in Exhibit A either initially because it was proposed in the contract or be because it's gone through one form or another of the registry services evaluations process. -- RSEP: Can be used in a bunch of different ways. Request for new services to be added, such as IDNs, lock service at the registry level, protected marks. Many of these are standard, such a registry lock. So many registries have requested them that approval is pretty routine. -- So one of the key discussions at work track for had and made it into the initial report was should some of these very standard services, just be considered pre-approved, meaning that registries did not have to have those evaluated during the application process. Nor did they have to have it evaluated through a subsequent registry services evaluation requests, with the caveat that they are proposing doing that service in the same standardized way that has already been approved. Registry Services -- Summary Document, page 46: -- First proposal was to allow for a set of pre-approved services that don't require additional registry services evaluation, either through the application process or through a subsequent our Sep this had support, not surprisingly, from the brand registry group the registry stakeholder group new star and you started also proposed, including the list that was provided in the initial report. -- Example: A number of registries because of the unique laws that China has there is a standardized mechanism that's been developed for registries to conduct their business there and is called that the “China gateway.” That is one of the most highly used validated services that are typically added by registries. -- There was divergence from the Non-Commercial Stakeholder Group: “In this section, the WG has buried rights to extend content control and excessive intellectual property protection into the evaluation and registry agreement. “The Globally Protect Marks List is viewed by NCSG and many others in the ICANN Community as a bastardization of the Policy Development Process. The NCSG -- and the GNSO -- and the ICANN Board flatly rejected the proposal of the Intellectual Property Constituency that certain strings be considered so sacred that they would protected across all New gTLDs regardless of the meaning and context of that gTLD. We rejected that idea as an ICANN Community because it is completely inconsistent with trademark law as we know it. . . That a few registries were able to slip in these widely-disputed and highly-controversial proposals via the Voluntary Public Interest Commitments and later the RSEP technical modification process does not make them technical, financial or operational commitments in any way, shape or form. These are in fact clear violations of the ICANN Bylaws and the limits that ICANN set to itself and the Community when it entered the transition from US government control.” -- ACTION: re: NCSG Comment -- Interpreting that the NCSG divergence is not with the inclusion of certain services as approved registry services, it is it is an objection to one particular service – the Globally Protected Marks List -- under rights protection. Maybe discussed in the RPMs PDP WG, but we should follow up. -- The general notion is that certain services are so standard that they should be in this sort of pre-approved bucket, that should be added to the that could be added to the agreement without undergoing additional evaluation. -- With the protected marks lists this is really an objection to the substance of the service. Not sure this is the right place to have that debate, meaning in the pre-approved services, but it is certainly something that the Non-Commercial Stakeholder Group wants to have a discussion on. -- Split the recommendation into two parts: Part 1 -- there should be certain pre-approved services and list the ones that don't have any kind of controversy around them. Part 2 -- if any services in general are allowed to be introduced, or have been introduced and there's no policy preventing them from being introduced, then there is not an issue from the policy perspective. -- We understand the Non-Commercial Stakeholder Group’s concern with the globally protected marks list, but the debate should not for this particular section. If they want to oppose that type of service that's certainly within their rights to do that. But if someone is proposing to release it in a standardized way that's been approved for other registries, and there is not a policy preventing that then that's one that should be on the list of standardized services. -- But as long as that service exists, and as long as a registry is implementing it in a standardized way that one should be added to the list. But we can certainly put a note saying that there is a philosophical objection to this particular service from the Non-Commercial Stakeholder Group and put the reasons why in a footnote, but that doesn't really relate to this particular section. -- ICANN Org comment: if an applicant chooses to offer one of the pre-approved registry services, the applicant would still need to go through an evaluation process to ensure that the applicant is capable of providing that pre -approved service. It would be helpful if the PDP working group can confirm this understanding is correct. -- Also, ICANN Org understands that this evaluation is not RSEP, which is only used for evaluating registry services that are not approved as per preliminary recommendation 2.7.7 from our initial report, but rather as another form of evaluation that is limited to assessing the applicants ability to perform the pre-approved registry service. It will be helpful, the PDP working group could also confirm if this understanding is correct. -- Applicants are asked to describe the registry services that they would like to provide and the manner in which they are going to provide it. That is all subject to the technical evaluation, a technical operational evaluation if the registry passes that evaluation then that is the only evaluation we're saying is needed for these quote pre-approved services -- that you would not need to separately go through a registration services evaluation panel and you would not have to do you know go through that entire process, but you would still like for all the registry services, you still have to show ICANN and the evaluators that you have a capability of offering the service. -- To confirm, they are all subject to evaluation in the standard technical operation evaluation as part of the application process. It's just they wouldn't have to go to a separate panel. -- There's a proposal to include one additional item and what we would do is list those as examples and perhaps then ask an implementation review team to confirm that that would be the right set and to see if there are additional ones. -- Re: RSEP should only be used to assess services that are not pre-approved: The main point of this recommendation is that it should be consistent, whatever processes used to evaluate new registry services for the new entrant should be consistent with the evaluation process of the existing to these and vice versa. -- Re: applications proposing non-pre-approved services should not be required to pay a higher application fee, unless an RSTEP is required: If the new entrant proposes a non-pre-approved service and it does not require constituting a technical panel because maybe the technical aspects are limited or understood then new applicants similarly, it should not have to pay a fee. This clause was added in order to foster innovation by not making it more expensive for the new entrance than it would be for existing registries. -- ACTION: Possible new high-level agreement: (ICANN Org comment) it would be helpful for us to make the recommendation that the implementation team revise the RSEP workflow to fit within the new gTLD processes and timelines and then put these as a couple of the examples -- (i.e., using priority number to order evaluation, using clarifying questions to address issues). Proposed draft language for Registry Services Evaluation: 2.7.7.17<https://www.google.com/url?q=http://2.7.7.17&sa=D&ust=1567696630863000&usg=…>: “Applicants will be encouraged but not required to specify additional registry services that are critical to the operation and business plan of the registry. The list of previously approved registry services (IDN Languages, GPML, BTAPPA) will be included by reference in the Applicant Guidebook and Registry Agreement. If the applicant includes additional registry services, the applicant must specify whether it wants it evaluated through RSEP at evaluation time, contracting time, or after contract signing, acknowledging that exceptional processing could incur additional application fees. If the applicant has not included additional registry services, RSEP will only be available after contract signing.” -- Some support, some divergence. A lot of different comments that we've already addressed by saying that they are going to be evaluated as part of the application anyway. -- Question: Can we refine the reference to previously approved registry services that will be included by reference in the applicant guidebook and registry agreement to make it clear which services will be included in the applicant guidebook and which will be included in the RA? Answer: Certainly in the RA which is included with the AGB, ACTION: we need to decide one way or the other. Suggestions for additional registry services that could be pre-approved: -- WG could include a non-exhaustive list and leave for refinement in IRT Perspectives on whether the proposed registry services language changes the 2012 implementation of asking for disclosure of services versus disclosure being required. -- IPC: Language of Question 23 required disclosure of new services. That requirement should not be changed since it is essential to evaluation. ACTION: Check with IPC. Potential drawbacks of consolidating registry evaluations: -- RySG: Strongly supports batched evaluations for identical or nearly-identical applications by an RO (and its Affiliates). ACTION: Check to see if batching is mentioned elsewhere. Other Topics: Additional fees associated with evaluations: -- MARQUES: Supports a base application fee which all applicants should pay for standard evaluation with supplementary / top up fees paid for more detailed evaluation. ACTION: Move to the discussion on fees. ICANN Board: The Board is interested in recommendations for a mechanism that can be used when there are issues that block an application moving forward. -- Maybe more appropriate for objections or appeal mechanisms? b. Role of Application Comment (page 51) High-Level Agreements (see page 51) -- Confirm if it's being done already. If it's not, it may not be captured already by the applicant guidebook or elsewhere, so we should note that were re-confirming something that's it’s already done. But the reason we're stating it as a high level agreement is because we think it should be explicitly stated. Also, we should also indicate the high-level agreement on new stuff. -- Don’t position something that is already done as new. -- Start with Outstanding Items on the next call. Note about Name Collisions (upcoming topic): -- One of the things we're going to cover on that call is the interrelationship between the NCAP study and our work, and to the extent that we think that the study may cover some of those areas. We can defer to the studies or we can set some policy until such time that the studies, unless and until the studies produce some different result. 3. ICANN66 Schedule: -- Note that when the schedule is published it will say that the first two sessions are for WT5, but those are likely to be changed to full WG meetings, so note that in your travel plans. -- So the first two sessions are on Saturday and the other two sessions are on Monday.

1 0

Post call | New gTLD Subsequent Procedures Working Group call | Thursday, 05 September 2019 at 03:00 UTC
by Julie Bisland Sept. 5, 2019

Sept. 5, 2019

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 05 September 2019 at 03:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/ZYTkBg> (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, Julie

1 0