February 2020 - Gnso-newgtld-wg

Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable?
by Pruis, Elaine Feb. 4, 2020

Feb. 4, 2020

All, I have deep reservations about removing the phrase “collusion” from the subpro goals, and potentially, final recommendations. Jeff stated “I am not sure we can say for a fact that collusion occurred “in order to deceive or cheat someone”” but there is plenty of public information suggesting that is exactly what occurred in the last round, both in private contention resolution as well as objection proceedings. From Circle ID 2016:<http://www.circleid.com/posts/20161107_afilias_cynical_attempt_to_secure_a_…> “Afilias' motivation could not be more transparent: in a private auction, either tens of millions of dollars will be paid to it for losing the auction or, if NDC is disqualified, Afilias stands to secure the .web new gTLD at a much lower non-competitive price. Indeed, it was just such maneuvering that caused Afilias to commit, in writing, a demonstrable violation of the Blackout Period as it sought agreement among the contention set to substitute a private for a public auction a few days before the public auction took place. Pursuant to the express terms of the Guidebook, this violation in and of itself could disqualify Afilias.” From Domain Incite, 2018<http://domainincite.com/23758-verisign-says-afilias-tried-to-rig-web-auction>: “Afilias and other bidders proposed that a private auction be performed pursuant to collusive and potentially illegal terms about who could win and who would lose the auction, including guarantees of auction proceeds to certain losers of the auction.” The solution to this problem is to not suggest support for, or even allow for, private auctions. ICANN IRP filings<https://www.icann.org/en/system/files/correspondence/omahoney-et-al-to-klit…> “To make matters worse, it appears that Donuts is acting in collusion with another similarly-situated “group registry” applicant to magnify the adverse impact of these tactics on the Sport Communities. The timing of Donuts’ actions before the Ombudsman and this present IRP filing shows that Donuts and Famous Four Media (“FFM”, the second group registry applicant in the .sport/.sports and .rugby contention sets) collude in their strategy of procedural harassment. Donuts waited for the multiple frivolous proceedings submitted by FFM to be dismissed and then took over. These two portfolio applicants thus managed to maximize the delays suffered by the Sport Communities. IRB Letter at 2-3. As both are funded by venture capital and both are engaged in private and ICANN auctions for many TLDs they have applied for, they have an interest in perpetuating uncertainty as to the status of TLDs that target communities. In this way, they maintain artificial financial valuation for the applications in their portfolio which target communities and were prevailed upon by way of ICANN’s Community-based objections or ICANN’s Community Priority Evaluation.“ Famous Four Media Limited and Donuts Inc. Abusive, Baseless and Harmful Actions Concerning the .Rugby gTLD<applewebdata://ED9A75A6-5E60-4EB2-9E61-0BDFC75BDB27/Famous%20Four%20Media%20Limited%20and%20Donuts%20Inc.%20Abusive,%20Baseless%20and%20Harmful%20Actions%20Concerning%20the%20.Rugby%20gTLD> “The secret, ex parte nature of the actions of Famous Four and Donuts exacerbates their pernicious impact on the IRB.” And, “Now, in a repeat of their earlier strategy, Famous Four has followed the apparent dismissal of the CEP complaint of Donuts with perfectly coordinated timing.” In fact, the classic Vickrey model with bids at application would eliminate contention sets altogether, which could further minimize the tactical use of objection proceedings. For the preservation of ICANN’s reputation and the longevity of the MSM, we as a community need to do everything we can to remove any opportunities for, or even the perception of, misconduct or inappropriate behavior. With the recent .org transaction now widely covered in the mainstream media, there is a lot of focus and attention on ICANN. And many detractors are looking for any excuse to delegitimize the organization. Let’s not give them any more ammunition. Jeff asked, “Are Private Auctions (whether done legitimately or not) undesirable for resolving contention sets? Does it harm the reputation of ICANN or the program?“ YES (see above) Elaine From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Tuesday, January 21, 2020 at 11:21 AM To: Jeff Neuman <jeff.neuman(a)comlaude.com>, "lists(a)christopherwilkinson.eu" <lists(a)christopherwilkinson.eu>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [EXTERNAL] Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable? I have suggested replacing the word “collusion” in the Google doc – see suggested language there. Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Jeff Neuman Sent: Monday, January 20, 2020 3:13 PM To: lists(a)christopherwilkinson.eu; gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable? [EXTERNAL] ________________________________ Thanks Christopher. Collusion is defined<https://dictionary.cambridge.org/us/dictionary/english/collusion> as “agreement between people to act together secretly or illegally in order to deceive or cheat someone.” I am not sure we can say for a FACT that collusion occurred “in order to deceive or cheat someone.” Yes, parties did work in secret and came up with “agreements”, but the second element or deceit or cheat is just as important. In the last round the Applicant Guidebook not only allowed working in private to resolve contention sets, but it encouraged it. The mere act of having private auctions does not equate to there being collusion. That said, we still may want to list collusion as an “undesirable activity”; but collusion would include the “in order to deceive or cheat someone.” The second question, however, is do we believe that private auctions, in and of themselves, for the New gTLD Program, should be considered “undesirable activity.” Although not “collusion”, we could still attempt to disallow them. That is what we are trying to get a sense of from the group. Are Private Auctions (whether done legitimately or not) undesirable for resolving contention sets? Does it harm the reputation of ICANN or the program? Please note, as one of the Co-Chairs, I am not taking a position on this, other than to note that many of the comments (including from the GAC, ICANN Board, NCSG, some registries, BC, Gov’t of India, etc.) stated in their comments that private auctions where funds are distributed back to the losing applicants, may not be desirable. Other groups, including some registries, the RrSG, the IPC, Neustar, BRG, etc. however, did support private auctions where are applicants agree to participate. Thanks. 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 lists(a)christopherwilkinson.eu<mailto:lists@christopherwilkinson.eu> Sent: Monday, January 20, 2020 3:44 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable? Good evening: I strongly 'suggest' that we do not want to replace the word 'Collusion' in this context. 1. Collusion took place in the last round, otherwise there could not have been any private auctions. 2. The fact that we are discussing this at all strongly suggests - to the outside world - that we would prefer to dissimulate that fact. 3. ICANN is the regulator of the conditions of competition in this sector; if we cannot deal with this matter, it severely undermines the original rationale for having ICANN at all. Regards CW On 17 Jan 2020, at 17:30, Aikman-Scalese, Anne <AAikman(a)lrrc.com<mailto:AAikman@lrrc.com>> wrote: I put some suggested language in the Google doc to replace the word “Collusion”: https://docs.google.com/document/d/16qDoiK6vydQp6a0v9tMvU2l5fcypJY24hCzTIVT… Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Rubens Kuhl Sent: Friday, January 17, 2020 2:58 AM To: Dorrain, Kristine <dorraink(a)amazon.com<mailto:dorraink@amazon.com>> Cc: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable? Kristine, This is a not a reasonable business adjustment. If the contention set seems "unbeatable", one could withdraw or simply wait the appropriate refund. A similar way to see #2 is a participant in a race that starts extorting other racers when it realises it won't win the race. It doesn't matter that the original intent had good faith; if someone switches to a bad behaviour on the fly, then it's now up for a new assessment of its attitude. Rubens On 16 Jan 2020, at 20:57, Dorrain, Kristine <dorraink(a)amazon.com<mailto:dorraink@amazon.com>> wrote: Hi Rubens, with respect to #2, you admit good faith intent at the time of application. At what point would an applicant’s reasonable business adjustment reacting to the unforeseen business impact of third party applications and business decisions switch the first applicant’s good faith to bad faith? It seems like the community would get to use the benefit of hindsight to judge the reactionary business decisions made by other applications in their business strategy. Kristine From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Rubens Kuhl Sent: Thursday, January 16, 2020 1:14 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable? <Leadership Hat Off> I will start with two different although similar bad behaviours: - Apply with no intention to actually run the TLDs, just to get into private auctions and profit from losing them. - Apply with intent to run the TLDs, but after contention sets are revealed, change strategy to profit from losing some TLDs instead of fighting to get them. Rubens On 16 Jan 2020, at 17:17, Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>> wrote: All, On the call early this morning (for some of us), while we were discussing the goals/objectives to consider when selecting a mechanism of last resort to resolve string contention, a very important question was asked by a participant on the call. The question demonstrated that what one person believes is “Bad Faith” other people may not believe is “bad faith” with respect to mechanisms to resolve contention sets. So, with the e-mail chain, I would like for members of the Working Group to discuss what behaviors they would consider to be of the type that we would like to preclude? And by the same token, what are the types of activities that we know we would like to allow. For example, we believe from most of the comments that have come in as well as in our discussions, that some forms of private resolution have been deemed acceptable. This includes the creation of joint ventures between applicants (assuming public comment, etc.), potentially revising applications to address concerns (eg., trademark owner agrees to withdraw its application if other applicant agrees to mitigate trademark abuse), 2 trademark owners agree to modify strings to enable both to have their own TLDs (eg., .deltafaucets or .deltaair)), etc. We have also heard from the ICANN Board that they may believe that participating in private auctions with the sole purpose of losing and using those to fund other auctions may not be as desirable. Though the next call with not be on this topic, we did want to put this issue out on e-mail. Please discuss. Thanks. Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<http://www.comlaude.com/> <image003.jpg> ________________________________ 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/> _______________________________________________ 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. ________________________________ 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. _______________________________________________ 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.

4 3

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 06 February 2020 at 20:00 UTC
by Julie Hedlund Feb. 4, 2020

Feb. 4, 2020

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

1 0

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

Feb. 3, 2020

Anne, Thank you for the helpful clarification. Kind regards, Julie From: "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Monday, February 3, 2020 at 5:10 PM To: Julie Hedlund <julie.hedlund(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 February 1500 UTC Julie, There appears to be an error in ACTIN ITEM 2. The word “only” was not supposed to be deleted. The word “only” should remain in the text or it does not express what the WG was agreeing on the call. The meaning is to limit the grounds for rejection to the provisions of the AGB. The deletion is “be permitted to”. Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Julie Hedlund Sent: Monday, February 3, 2020 9:45 AM To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 February 1500 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 03 February 1500 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-02-03+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.5.3 Application Submission Period: ACTION ITEM 1: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] 2.5.5 Terms and Conditions: ACTION ITEM 2: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Implementation Guidance xx: If the true risk of name collisions will be determined after the application is filed, ICANN should provide a full refund to applicants in cases where a new gTLD is applied for but later is disqualified because of risk of Name Collision. ACTION ITEM 3: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. Re: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. ACTION ITEM 4: Add Implementation Guidance language on confidentiality. ACTION ITEM 5: Add “Application Changes” to the list of dependencies. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkR… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>. Overview: -- Question: What was the relationship between “affirmations” and “consensus”? Answer: These are two different concepts. We will be taking consensus calls on everything -- whether it is an affirmation, recommendation, or implementation guideline. -- Question: Affirmation seems quite intertwined with the concept of consensus. How does that relate to people who don’t agree with that affirmation? Answer: We hope you would let us know prior to taking a consensus call -- perhaps by changing the language, or changing it to a different type, such as a recommendation. We’ll also have a preamble that will explain what are the different categories. -- Think of it as an affirmative recommendation. Default to the 2012 round will be stated differently -- noting that not everyone agreed. -- Question: If we have default where we don’t agree, what about things we didn’t discuss? a. 2.5.3 Application Submission Period Recommendation xx: The Working Group recommends that for the next application window and subsequent application windows, the application submission period must be a fixed period of three (3) months. -- We aren’t really affirming what happened last time (as we don’t agree), but making a recommendation. -- What we talked about and had agreement in the comments we said at least 3 months, but that leaves open a whole bunch of different possibilities. This recommendation says 3 months, but there was discussion about longer periods. Discussion: -- In this discussion there might be a dependency relating for time for translation of the AGB in all of the different languages -- it should be consistent. -- On the translations issue we had implementation guidance that the non-English version should come out at or the same time as the English version. -- It should be a fixed period of time and should be consistent. -- Not just due to circumstances — it should changeable based on policy considerations and objectives -- 90-120 day. -- If it's not a fixed time, then who decides and when? -- Agree not less than 90 nor more than 120. -- Hence 12 weeks works and applies a reasonable structure . -- The implementation guidelines could say that the period should not end over a weekend, or say that it ends on a Wednesday. Say that the week runs from a Wednesday to a Wednesday. ACTION ITEM: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] b. 2.5.5 Terms and Conditions Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN must only be permitted to reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization must cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaw for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round. Discussion: -- Question: If we say “must” instead of “should” are we putting the Board in a position of not adopting a recommendation subject to GAC advice. Answer: The GAC advice led to unpredictability so this is a pretty strong recommendation from the comments that we got in on the Initial Report. -- Question: Are we able to accommodate name collisions, or things that we didn’t think about? Answer: That is in the first sentence. -- This should be viewed as a compromise position since ICANN shouldn’t be able to avoid having it’s decisions challenged in court. -- If ICANN acts inconsistently with the AGB or the Bylaws there are ways to challenge the decisions. This is all challengeable in some way and allows for accountability. -- Should we delete “be permitted” in the first sentence? ACTION ITEM: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Discussion: -- What does the “where applicable” comes from - is it because of the difference between those who may not get a full refund. -- Putting in a full refund for any change to the AGB could be challenging. Not sure the WG could decide where a full refund should be made available. It is a qualifier that a full refund is not provided in all circumstances. -- Does the WG have a suggestion for the types of changes that would require a full refund? This doesn’t take into account that there are portions of the program that don’t get implemented until the end so there is a potential for changes. -- When we talk about application changes we provide more detail. Where and ICANN change materially changes the nature of an application, for example. ACTION ITEM: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. c. New issues raised in deliberations since publication of the Initial Report, if applicable: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. The Working Group considered feedback received through public comment regarding who should have access to this information provided by ICANN org. The Working Group reviewed one perspective that this information should be completely confidential and only available to the applicant, as well as the perspective that disclosure should be to the applicant exclusively if confidential information of the applicant might otherwise be revealed. The Working Group did not put forward a specific recommendation on this issue and notes that it may be considered further in the implementation phase. Discussion: -- This seems to make sense. This is a good inclusion. -- The reason for rejecting an application should be confidential, but binding on ICANN, not on the applicant. -- Question: Is that for any reason an application be rejected? Or just based on confidential information submitted by the applicant? Answer: It seems practically that the confidentiality would flow from the confidential disclosure. ACTION ITEM: Add Implementation Guidance language on confidentiality. -- Question: Should we link to the NCAP on name collisions as an “external effort”? Answer: Staff will determine the most efficient way to include links. ACTION ITEM 5: Add “Application Changes” to the list of dependencies. ________________________________ 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.

2 5

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

Feb. 3, 2020

Dear Working Group members, Please see below the notes from the meeting on 03 February 1500 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-02-03+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.5.3 Application Submission Period: ACTION ITEM 1: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] 2.5.5 Terms and Conditions: ACTION ITEM 2: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Implementation Guidance xx: If the true risk of name collisions will be determined after the application is filed, ICANN should provide a full refund to applicants in cases where a new gTLD is applied for but later is disqualified because of risk of Name Collision. ACTION ITEM 3: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. Re: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. ACTION ITEM 4: Add Implementation Guidance language on confidentiality. ACTION ITEM 5: Add “Application Changes” to the list of dependencies. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkR…. Overview: -- Question: What was the relationship between “affirmations” and “consensus”? Answer: These are two different concepts. We will be taking consensus calls on everything -- whether it is an affirmation, recommendation, or implementation guideline. -- Question: Affirmation seems quite intertwined with the concept of consensus. How does that relate to people who don’t agree with that affirmation? Answer: We hope you would let us know prior to taking a consensus call -- perhaps by changing the language, or changing it to a different type, such as a recommendation. We’ll also have a preamble that will explain what are the different categories. -- Think of it as an affirmative recommendation. Default to the 2012 round will be stated differently -- noting that not everyone agreed. -- Question: If we have default where we don’t agree, what about things we didn’t discuss? a. 2.5.3 Application Submission Period Recommendation xx: The Working Group recommends that for the next application window and subsequent application windows, the application submission period must be a fixed period of three (3) months. -- We aren’t really affirming what happened last time (as we don’t agree), but making a recommendation. -- What we talked about and had agreement in the comments we said at least 3 months, but that leaves open a whole bunch of different possibilities. This recommendation says 3 months, but there was discussion about longer periods. Discussion: -- In this discussion there might be a dependency relating for time for translation of the AGB in all of the different languages -- it should be consistent. -- On the translations issue we had implementation guidance that the non-English version should come out at or the same time as the English version. -- It should be a fixed period of time and should be consistent. -- Not just due to circumstances — it should changeable based on policy considerations and objectives -- 90-120 day. -- If it's not a fixed time, then who decides and when? -- Agree not less than 90 nor more than 120. -- Hence 12 weeks works and applies a reasonable structure . -- The implementation guidelines could say that the period should not end over a weekend, or say that it ends on a Wednesday. Say that the week runs from a Wednesday to a Wednesday. ACTION ITEM: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] b. 2.5.5 Terms and Conditions Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN must only be permitted to reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization must cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaw for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round. Discussion: -- Question: If we say “must” instead of “should” are we putting the Board in a position of not adopting a recommendation subject to GAC advice. Answer: The GAC advice led to unpredictability so this is a pretty strong recommendation from the comments that we got in on the Initial Report. -- Question: Are we able to accommodate name collisions, or things that we didn’t think about? Answer: That is in the first sentence. -- This should be viewed as a compromise position since ICANN shouldn’t be able to avoid having it’s decisions challenged in court. -- If ICANN acts inconsistently with the AGB or the Bylaws there are ways to challenge the decisions. This is all challengeable in some way and allows for accountability. -- Should we delete “be permitted” in the first sentence? ACTION ITEM: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Discussion: -- What does the “where applicable” comes from - is it because of the difference between those who may not get a full refund. -- Putting in a full refund for any change to the AGB could be challenging. Not sure the WG could decide where a full refund should be made available. It is a qualifier that a full refund is not provided in all circumstances. -- Does the WG have a suggestion for the types of changes that would require a full refund? This doesn’t take into account that there are portions of the program that don’t get implemented until the end so there is a potential for changes. -- When we talk about application changes we provide more detail. Where and ICANN change materially changes the nature of an application, for example. ACTION ITEM: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. c. New issues raised in deliberations since publication of the Initial Report, if applicable: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. The Working Group considered feedback received through public comment regarding who should have access to this information provided by ICANN org. The Working Group reviewed one perspective that this information should be completely confidential and only available to the applicant, as well as the perspective that disclosure should be to the applicant exclusively if confidential information of the applicant might otherwise be revealed. The Working Group did not put forward a specific recommendation on this issue and notes that it may be considered further in the implementation phase. Discussion: -- This seems to make sense. This is a good inclusion. -- The reason for rejecting an application should be confidential, but binding on ICANN, not on the applicant. -- Question: Is that for any reason an application be rejected? Or just based on confidential information submitted by the applicant? Answer: It seems practically that the confidentiality would flow from the confidential disclosure. ACTION ITEM: Add Implementation Guidance language on confidentiality. -- Question: Should we link to the NCAP on name collisions as an “external effort”? Answer: Staff will determine the most efficient way to include links. ACTION ITEM 5: Add “Application Changes” to the list of dependencies.

2 1

FW: New gTLD SubPro WG Liaison Announcement
by Jeff Neuman Feb. 3, 2020

Feb. 3, 2020

All, Welcome Avri and Becky as Liaisons from the Board to our Working Group. I believe this is a great development and will certainly help us as we move forward towards implementation. Please see the note below from the ICANN Board Chair on the role of the two Board Liaisons. As most of you are aware, Avri was one of the original Co-chairs of the group before moving onto the ICANN Board. Becky, as most of you know, has had many roles in the ICANN community, both from the Private Sector as well as from the US Government, and was at Neustar during the last round of New gTLDs. Both of them are well versed in the New gTLD process and we are glad to have them as liaisons. Best regards, 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: Wendy Profit <wendy.profit(a)icann.org> Sent: Monday, February 3, 2020 11:26 AM To: Jeff Neuman <jeff.neuman(a)comlaude.com>; langdonorr(a)gmail.com; gnso-secs(a)icann.org Cc: Maarten Botterman <maarten.botterman(a)board.icann.org>; Board Ops Team <board-ops-team(a)icann.org>; Secretary <secretary(a)icann.org> Subject: New gTLD SubPro WG Liaison Announcement SENT ON BEHALF OF MAARTEN BOTTERMAN Dear Cheryl and Jeff, I’m writing to notify you that two liaisons from the ICANN Board have been appointed to the New generic Top-Level Domain (gTLD) Subsequent Procedures Policy Development Process Working Group. They are Avri Doria and Becky Burr; and you may already be in communication with them in this regard. This email serves as official notification of their appointments. I also wish to confirm that the role of the two Board liaisons for the New gTLD Subsequent Procedures Working Group is consistent with the expectation of the GNSO Council, that Board Liaison(s) will share on a regular basis any input the Board may have that will inform the SubPro PDP team deliberations and ongoing work. Similarly, Board Liaison(s) are expected to keep the Board informed concerning the status of the SubPro PDP Team deliberations. The Board Liaison(s) are not expected to advocate for any position and/or participate in any SubPro Team consensus calls. Please inform the GNSO Council accordingly. Best regards, Maarten Wendy Profit ICANN Board Operations Senior Manager 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>

2 1

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

Feb. 3, 2020

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

1 0