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

REMINDER: Deadline 4 June - Comments on Revised Draft Recommendations - Package 4
by Emily Barabas June 4, 2020

June 4, 2020

Dear all, As a reminder, the deadline for “can’t live with” input on package 4 is tomorrow, 4 June at 23:59 UTC. Details are below. Kind regards, Emily From: Emily Barabas <emily.barabas(a)icann.org> Date: Thursday, 28 May 2020 at 19:36 To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: Deadline 4 June - Comments on Revised Draft Recommendations - Package 4 Dear all, The leadership team is releasing the fourth set of revised draft recommendations for your review. 1. There are 7 topics in package 4 here, beginning on page 43: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> · 2.3 Role of Application Comment (last discussed 25 Feb<https://community.icann.org/display/NGSPP/2020-02-25+New+gTLD+Subsequent+Pr…>) · 2.7.2 Registrant Protections (last discussed 2 Mar<https://community.icann.org/display/NGSPP/2020-03-02+New+gTLD+Subsequent+Pr…>) · 2.7.4 String Similarity Evaluation (last discussed 30 Mar<https://community.icann.org/display/NGSPP/2020-03-30+New+gTLD+Subsequent+Pr…>) · 2.7.5 Internationalized Domain Names (last discussed 28 Apr<https://community.icann.org/display/NGSPP/2020-04-28+New+gTLD+Subsequent+Pr…>) · 2.7.6 Security and Stability (last discussed 28 Apr<https://community.icann.org/display/NGSPP/2020-04-28+New+gTLD+Subsequent+Pr…>) · 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services (last discussed 27 Feb<https://community.icann.org/display/NGSPP/2020-02-27+New+gTLD+Subsequent+Pr…>) · 2.7.8 Name Collisions (last discussed 30 Apr<https://community.icann.org/display/NGSPP/2020-04-30+New+gTLD+Subsequent+Pr…>) 1. Please limit comments to items in the revised sections that you absolutely “cannot live with.” If there is text that you cannot accept, please fill out the attached form and send it to the WG by email. Please do not provide your input in any other format. 1. Deadline for comments is Thursday 4 June at 23:59 UTC 1. Comments will be tracked here: https://community.icann.org/x/JDKJBw. Kind regards, Emily

5 6

Re: [Gnso-newgtld-wg] REMINDER: Deadline 4 June - Comments on Revised Draft Recommendations - Package 4
by Kathy Kleiman June 4, 2020

June 4, 2020

Good meeting today. My comments on Package 4.Best, Kathy

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 04 June 2000 UTC
by Julie Hedlund June 4, 2020

June 4, 2020

Dear Working Group members, Please see below the notes from the meeting on 04 June at 2000 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-06-04+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Package 2, 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization, page 19: ACTION ITEM: Change the text to: “Registries must use only ICANN accredited registrars in registering domain names, and may not discriminate among such accredited registrars unless an exemption to the Registry Code of Conduct is granted [as stated therein][add citation to the exemption]” 2.3.4 Universal Acceptance c. New issues raised in deliberations since publication of the Initial Report, if applicable. ACTION ITEM: The WG agreed to include the revised text in brackets. Category 1/Verified TLDs ACTION ITEM: Develop a description of the framework. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Discussion of Final Report Topics: a. Review "Can't Live With" comments on packages 1-3 -- comment from Anne Aikman-Scalese on Package 2, 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization, page 19: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [“Registries must use only ICANN accredited registrars in registering domain names and may not discriminate among such accredited registrars, unless an exemption to the Registry Code of Conduct is granted, provided, however, that no such exemptions shall be granted without public comment and further provided that exemption requests seeking approval of the use of unaccredited registrars will not be granted.”] -- AAS2.1 - Anne Aikman-Scalese suggested adding the text in bold. Rationale: "The language appears to permit registries to obtain exemptions from the Code of Conduct to allow them to use unaccredited registrars. I don’t recall this being the thrust of exemptions that were granted in the 2012 round. I believe the exemptions granted in the 2012 round related to issues other than accreditation. Are there currently unaccredited registrars issuing domain name registrations?" -- The intent is clear but the language of the sentence could be clearer. -- Move the comma: Registries must use only ICANN accredited registrars in registering domain names, and may not discriminate among such accredited registrars unless an exemption to the Registry Code of Conduct is granted [as stated therein][add citation to the exemption]. ACTION ITEM: Change the text to: “Registries must use only ICANN accredited registrars in registering domain names, and may not discriminate among such accredited registrars unless an exemption to the Registry Code of Conduct is granted [as stated therein][add citation to the exemption]” 2.3.4 Universal Acceptance c. New issues raised in deliberations since publication of the Initial Report, if applicable. -- JC3.8 - Justine Chew proposed adding text regarding deliberations. Rationale: "There were comments by the ALAC and the BC to the Initial Report that, while have not materialized into standalone recommendations, remain important to include in the Final Report. The basis for these can be derived from an earlier version of deliberations on the topic." ACTION ITEM: The WG agreed to include the revised text in brackets. b. Global Public Interest (2.3.2 Registry commitments / Public Interest Commitments): 1) Review Category 1/Verified TLDs (see also Objections): https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…, page 141; see also the ICANN46 Beijing Communique’ at: https://gac.icann.org/contentMigrated/icann46-beijing-communique; See also the Board Resolution at: https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05… Discussion: -- Wasn’t a good definition of what would be allowed in these types of strings, except that they are verified. -- We need to decide what to do with this: 1) affirm what was done (in registry agreements) and 2) decide what strings in the next round would fit in this category; 3) not adopt but explain why we aren’t adopting it. -- Related to the discussion with verified TLDs -- a few from the 2012 round -- that do the validation up front. There was concern for applications for translations (.pharmacy) that a consumer would assume that there were the same amount of restrictions in the translated string, which might not be the case. If we define Category 1 and keep it in the program that could resolve some of the concerns. -- If we decide these apply to regulated strings we need some kind of mechanism so that applicants know that they could fall into one of these categories. -- If we are going to protect strings we should look at the implementation of it in the Board resolution annex. -- Question: Sounds like we are being asked to affirm a 2012 implementation, one of which is the GAC advice on Category 1/Verified TLDs? Answer: Not asking us to affirm these categories/strings. -- We may need to affirm this NGPC framework implementation in some logical way because they highlight public interest and safety concerns. -- If we do affirm, do we want to provide the same types of headings (from the NGPC implementation document)? -- If we do affirm, how do define the categories and what restrictions do we impose on them? -- How do we rationalise that with the conclusion we've already reached not to create more categories? -- We would be affirming the “framework”. -- What the Board implemented differed from the GAC Advice, so not sure we should affirm the Board’s implementation. -- We can say that there were these types of strings that were highly regulated in the last round that had to agree to these PICs, so if you are classified as one of these you may have to agree to contractual provisions through PICs and be subject to the PICDRP. -- Identify the kinds of strings in the last round, these were the kinds of PICs that were applied to these kinds of strings, so applicant beware. Just look at how it turned out. -- Question: Would we say if you are classified as one of these by the GAC these PICs would apply? Answer: We wouldn’t say if we affirm or not the GAC’s ability to issue consensus advice, but to alert applicants that this is what happened in the last round. Since we don’t know who will apply for what strings, not sure we can go beyond that. -- If you don’t specify that all sensitive strings will get these safeguards (x, y, z) and some will get these (a, b, c) etc. then the GAC could go back to their Beijing Communique’. -- Focus on descriptions and rationale for safeguards, and use examples from this list based on this framework . And explain the process that follows if an applied-for string gets called out for treatment under this framework. -- The GAC did not call these out as an exhaustive list, although that is how they were treated. The GAC intended this to cover any strings in the category types. We can't rule out that there might be other types in future, but we already know that these types are a problem from the GAC perspective and would lead to this type of advice again. I think we have to try to address it contractually up front . -- Affirm framework by focusing on descriptions and rationale for safeguards, and use examples from this list. Based on this framework then explain the process that follows if an applied-for string gets called out for treatment under this framework, including a "safeguard evaluation". -- Could allow an applicant to self-declare as one of the regulated strings and the contractual requirements will apply; if you don’t self-declare you will come under scrutiny by the community/GAC and safeguards may still apply. -- Warning/advisory should be part of the policy solution. -- Could we have a strawman document? ACTION ITEM: Develop a description of the framework. c) DNS Abuse, page 136 and 140 -- Sent a letter to the Council suggesting that there should be a holistic approach; haven’t heard back from the Council (see rationale 8 on page 140). -- GAC did ask us to address it. d) Applicant Support (multipliers at auction) page 6 in 2.1 Auctions: Mechanisms of Last Resort & 2.2 Private Resolution of Contention Sets (Including Private Auction) -- time permitting -- Start on the next call.

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 04 June at 20:00 UTC for 90 Minutes
by Julie Hedlund June 4, 2020

June 4, 2020

Dear all, Please find below the proposed agenda for the call on Tuesday, 04 June 2020 at 20:00 UTC for 90 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Discussion of Final Report Topics: * Review "Can't Live With" comments on packages 1-3 -- comment from Anne Aikman-Scalese on Package 2, 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization, page 19: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… * Global Public Interest (2.3.2 Registry commitments / Public Interest Commitments): * Review Category 1/Verified TLDs (see also Objections): https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…, page 141; see also the ICANN46 Beijing Communique’ at: https://gac.icann.org/contentMigrated/icann46-beijing-communique * GAC Input, page 143 and attached * DNS Abuse, page 136 and 140 * Applicant Support (multipliers at auction) page 6 in 2.1 Auctions: Mechanisms of Last Resort & 2.2 Private Resolution of Contention Sets (Including Private Auction) -- time permitting 1. 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

2 2

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 June 0300 UTC
by Julie Hedlund June 2, 2020

June 2, 2020

Dear Working Group members, Please see below the notes from the meeting on 02 June at 0300 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-06-02+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: PACKAGE 1: RecommendationImplementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should [must] be used to benefit the New gTLD Program and not any other ICANN program or purpose; that includes one or more of the following elements of the New gTLD Program: Re: “(e) other purpose(s) that benefits the New gTLD Program.” ACTION ITEM: Accept the revised text in brackets. 2.5.3 Application Submission Period b. Deliberations and rationale for recommendations and/or implementation guidelines Re: [Namely, if ICANN’s communications and outreach efforts are effective prior to the point at which the window opens, prospective applicants will be prepared to apply and will therefore need less time to actually submit the [application.] ACTION ITEM: Accept the revised text in boldface. 2.5.5 Terms and Conditions a. Recommendations and/or implementation guidelines Recommendation xx (rationale 1): ACTION ITEM: Change the text to: “Recommendation xx (rationale 1): [Unless required under specific laws, [or by the ICANN Board members’ fiduciary duties, or the ICANN Bylaws] or as the Board determines in the exercise of its fiduciary duties as contemplated in the ICANN Bylaws, ICANN must only reject an application if done so in accordance with the provisions of the Applicant Guidebook.]” Consider whether the language can be made more clear. Recommendation xx (rationale 3): ACTION ITEM: Make it clear that “recourse” refers to refunds and differs from the normal refund schedule. PACKAGE 2: ACTION ITEM: Look for comments from Anne Aikman-Scalese and incorporate them into the production document. PACKAGE 3: 2.2.1 Continuing Subsequent Procedures Rationale for Affirmation xx (rationale 1): ACTION ITEM: Accept the revised language in brackets. Re: While the Working Group recognizes that some parties believe the New gTLD market to already be saturated [others have indicated that they are aware of interested potential applicants, including dot Brands. Overall], the Working Group did not agree that a compelling reason was identified to override existing policy. ACTION ITEM: Accept the revised language in brackets. Rationale for Affirmation xx (rationale 2): A major theme that was repeatedly raised throughout the life cycle of this PDP was the need for predictability for all parties involved. The desire for an “orderly, timely and predictable” New gTLD Program is universally supported. [A major theme that was repeatedly raised throughout the life cycle of this PDP was the need for balanced predictability for all parties involved. It is on this basis that the desire for an “orderly, timely and predictable” New gTLD Program is universally supported.] ACTION ITEM: Accept the revised language in brackets. d. Dependencies/relationships with other areas of this report or external efforts Section 2.2.3 Applications Assessed in Rounds Re: [The Working Group Chair has directed a letter to GNSO Council relative to addressing CCT-RT recommendations re DNS Abuse holistically. The letter is dated 27 April 2020 and is attached to this report as ______________.] ACTION ITEM: Accept the revised language in brackets. 2.2.3 Applications Assessed in Rounds Recommendation xx (rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall [must] publish either (a) the date in which the next subsequent round of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent round. ACTION ITEM: Accept the revised language in brackets. Page 30, block of highlighted text: ACTION ITEM: Accept the revised language in brackets and find a more appropriate place for the bullet identified. Recommendation xx (see rationale 3): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of [to administer] the New gTLD Program. ACTION ITEM: Accept the revised language in brackets Rationale for Recommendation xx-xx (rationale 2): ACTION ITEM: Leadership will consider how/whether to call out dissenting views. 2.2.5 Applications Submission Limits c. New issues raised in deliberations since publication of the Initial Report, if applicable. Re: New text from Kathy Kleiman ACTION ITEM: Leadership will consider how/whether to call out dissenting views. At least include the final paragraph. 2.2.6 RSP Pre-Evaluation c. New issues raised in deliberations since publication of the Initial Report, if applicable. Re: [Ultimately, the Working Group did not think a recommendation was necessary.] ACTION ITEM: Accept the revised text in brackets. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review "Can't Live With" comments on packages 1-3: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… PACKAGE 1: 2.5.1 Application Fees & 2.5.2 Variable Fees, page 12 RecommendationImplementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should [must] be used to benefit the New gTLD Program and not any other ICANN program or purpose; that includes one or more of the following elements of the New gTLD Program: -- Neustar 1.1 - Neustar proposed changing "should" to "must" in this sentence. Rationale: "ICANN should not have any discretion regarding excess fees." Re: “(e) other purpose(s) that benefits the New gTLD Program.” -- With this additional category it seems there is a potential for a very large amount of money to be stuck in this category and not really be usable; need to have some level of exception. -- WG agrees to the additional text. ACTION ITEM: Accept the revised text in brackets. 2.5.3 Application Submission Period b. Deliberations and rationale for recommendations and/or implementation guidelines Re: [Namely, if ICANN’s communications and outreach efforts are effective prior to the point at which the window opens, prospective applicants will be prepared to apply and will therefore need less time to actually submit the [application.] -- KK1.1 - Kathy Kleiman proposed adding "ICANN's" to this sentence, as indicated in bold text. Rationale: "It’s unclear in current text who should be reponsivle for the communications and outreach efforts. Since it’s ICANN, we should make that quite clear. It’s ICANN’s outreach into communities around the world, including the Global South, that will help to generate the diversity of applications we are seeking." ACTION ITEM: Accept the revised text in boldface. 2.5.5 Terms and Conditions a. Recommendations and/or implementation guidelines Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN must only reject an application if done so in accordance with the provisions of the Applicant Guidebook. [Unless required under specific laws, [or by the ICANN Board members’ fiduciary duties, or the ICANN Bylaws] or as the Board determines in the exercise of its fiduciary duties as contemplated in the ICANN Bylaws, ICANN must only reject an application if done so in accordance with the provisions of the Applicant Guidebook.] -- AAS1.3 - Anne Aikman-Scalese proposed alternate text (in bold). Rationale: "The language does not account for the fact that the Board is required to act in a fiduciary capacity. For example, you cannot say that the Board has to approve an application made in accordance with the AGB if the Board determines it has a fiduciary duty to reject the application or if it would be permitted by the ByLaws, in the exercise of its fiduciary duty, to reject it. (This is different from saying that the ByLaws require them to reject it.)" -- Seems to open up a huge loophole to basically give the ICANN board complete discretion to reject an application for any reason, it sees fit. -- Seems to give the Board the right to rewrite the AGB. -- Whether or not this language is in here the Board is going to act according to its fiduciary duties. -- It’s part of their fiduciary duties to keep ICANN from harm and they could reject an application if they thought it would harm ICANN. Don’t think you can tie their hands and not allow them to do that. -- Can we have some examples of how the Board would do that? -- The Board has to act in good faith and it could say that it was acting in good faith in rejecting an application. -- For the Board to decide at the last minute to reject an application is contrary to ICANN’s mission and the multi-stakeholder process. -- It could be something that was a danger to the DNS, such as an application that causes name collisions. -- Compromise to change to: “[or by the ICANN Board members’ fiduciary duties, or the ICANN Bylaws] or as the Board determines in the exercise of its fiduciary duties as contemplated in the ICANN Bylaws ACTION ITEM: Change the text to: “Recommendation xx (rationale 1): [Unless required under specific laws, [or by the ICANN Board members’ fiduciary duties, or the ICANN Bylaws] or as the Board determines in the exercise of its fiduciary duties as contemplated in the ICANN Bylaws, ICANN must only reject an application if done so in accordance with the provisions of the Applicant Guidebook.]” Consider whether the language can be made more clear. Recommendation xx (rationale 3): Applicants must be allowed some type of recourse if substantive changes are made to the Applicant Guidebook or program processes if such changes have, or are reasonably likely to have, a material impact on Applicants. [Applicants must be allowed to challenge substantive changes made to the Applicant Guidebook after applications are submitted through an appeals mechanism or Request for Reconsideration or both, at Applicant’s discretion. In such cases, the Applicant will have the burden of proof to demonstrate that the change has, or is likely to have, a material impact on the Applicant.] -- AAS1.4 - Anne Aikman-Scalese proposed alternate text for this recommendation. Rationale: "The recommendation does not specify: (1) What “some type of recourse” means. (2) The timing at which changes are made that result in the “material impact”. (3) The standard of proof for determining “material impact” This language is very confusing and indefinite in many respects. Did we establish a separate appeals mechanism for decisions by ICANN that fit under this recommendation? And how do the Applicant’s rights in this regard fit into the application of the Predictability Framework?" -- Not sure the appeals mechanism or the Request for Reconsideration are the appropriate methods to challenge. -- We originally were thinking in terms of a refund, as opposed to a challenge. -- What would happen if the AGB was changed due to an appeals mechanism which could put in jeopardy previous applications. -- Maybe just solve it my saying that this intended to reference refunds. -- Should we put in “full refund”? Not sure we should in this case. Thought we would leave this to the Implementation Team. ACTION ITEM: Make it clear that “recourse” refers to refunds and differs from the normal refund schedule. PACKAGE 3: 2.2.1 Continuing Subsequent Procedures Rationale for Affirmation xx (rationale 1): The existing policy for New gTLDs states that there will be a “systemized manner of applying for gTLDs to be developed in the long term.” In affirming the continuation of this policy the Working Group applied the consistent approach outlined in Section xx [the introduction] of this report. -- Valideus3.1 - Susan Payne/Valideus proposed changing the second sentence of the rationale. Rationale for proposed change: "The Final Report will contain a number of Affirmations of the existing policy. It makes more sense, and presumably was the intention, to have an overarching/introductory section which explains the Working Group’s overall approach, since this applies not just to this particular affirmation but to all of them. If that is not the case, then the overall approach applied ought to be specified against every other Affirmation the WG makes and not just in this case." ACTION ITEM: Accept the revised language in brackets. Re: While the Working Group recognizes that some parties believe the New gTLD market to already be saturated [others have indicated that they are aware of interested potential applicants, including dot Brands. Overall], the Working Group did not agree that a compelling reason was identified to override existing policy. -- Valideus3.2 - Susan Payne/Valideus proposed adding text to this sentence. Rationale: "Rationale focuses only on the negative opinion of some that the TLD market is “saturated” and does not also acknowledge that there are also areas of demand, including from among Dot Brands who do not rely on sale of second level names and thus are not impacted by any perceived market saturation at the second level (if this even exists), and would challenge the notion of market saturation at the top level." ACTION ITEM: Accept the revised language in brackets. Rationale for Affirmation xx (rationale 2): A major theme that was repeatedly raised throughout the life cycle of this PDP was the need for predictability for all parties involved. The desire for an “orderly, timely and predictable” New gTLD Program is universally supported. [A major theme that was repeatedly raised throughout the life cycle of this PDP was the need for balanced predictability for all parties involved. It is on this basis that the desire for an “orderly, timely and predictable” New gTLD Program is universally supported.] -- JC3.1 - Justine Chew proposed edits to this sentence. Rationale: "It is important to recognize that the need for predictability be balanced for all parties involved and should not necessarily default in favour of or against applicants. The universal support for the affirmation is, arguably, predicated on this understanding. For eg, in Section 2.2.3 Applications Assessed in Round, we expressedly mentioned, “Rounds enhance the predictability for applicants (e.g., preparation), the ICANN community and other third-party observers to the program (e.g., public comments, objections)”" ACTION ITEM: Accept the revised language in brackets. d. Dependencies/relationships with other areas of this report or external efforts Section 2.2.3 Applications Assessed in Rounds Re: [The Working Group Chair has directed a letter to GNSO Council relative to addressing CCT-RT recommendations re DNS Abuse holistically. The letter is dated 27 April 2020 and is attached to this report as ______________.] -- AAS3.1 - Text proposed by Anne Aikman-Scalese. Rationale: In light of all the text in Rationale 1 and references to the March 1, 2019 Board Resolution, Section 2.2.1.d. should refer to Jeff Neuman’s letter to the GNSO Council re DNS Abuse Staff note: Suggest citing this letter instead under Global Public Interest, where the CCT-RT recommendations on DNS Abuse are discussed. Letter is available at: https://gnso.icann.org/sites/default/files/file/field-file-attach/neuman-la…<https://www.google.com/url?q=https://gnso.icann.org/sites/default/files/fil…> Cite in GPI section (where DNS Abuse is discussed). ACTION ITEM: Accept the revised language in brackets. 2.2.3 Applications Assessed in Rounds Recommendation xx (rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall [must] publish either (a) the date in which the next subsequent round of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent round. -- AAS3.3 - Anne Aikman-Scalese proposed changing "shall" to "must." Rationale: "What do we mean by the use of the word, “shall”? Do we mean ICANN “must”? Or ICANN “should”? This is a Recommendation so we need to be very specific. What are the conventions in relation to the use of the terms, “shall”, “must”, and “should” in the draft Final Report?" ACTION ITEM: Accept the revised language in brackets. Page 30, block of highlighted text: -- JC3.3 - Justine Chew proposed reordering the elements of this IG. Rationale: "The phrasing and/or formatting of ths Implementation Guidance is confusing and problematic insofar as the affirmative is mixed with the negative. It starts off with, “It should not be possible to apply for a string that is still being processed from a previous application round, specifically:…” and, • the 1st bullet deals with delegated strings - doesn’t delegation constitute the end of processing? Are delegated strings still be considered as being processed? • by the 3rd bullet, it provides for circumstances where a new application will be allowed. • the 4th bullet deals with a delegated TLD for which an RA has been terminated but no reassigned to a different RO – again would this still be considered as being processed? • the 6th and last bullet refers to a TLD that is “Not Approved” - at what point does a string be referred to as a TLD? Are we using “string” and “TLD” interchangeably here?" Placement of this bullet is awkward; find a different place: “If a Registry Operator has terminated its Registry Agreement and (i) the TLD has not been reassigned to a different Registry Operator, and (ii) in the case of a Specification 13 Brand TLD, it is more than 2 years following the Expiration Date (See RA Section 4.5(a)), then applications will be allowed to be submitted during a subsequent round.” ACTION ITEM: Accept the revised language in brackets and find a more appropriate place for the bullet identified. Recommendation xx (see rationale 3): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of [to administer] the New gTLD Program. -- JC3.4 - Justine Chew proposed changing "as part of" to "to administer". Rationale: "What does “as part of the New gTLD Program” mean?" ACTION ITEM: Accept the revised language in brackets. b. Deliberations and rationale for recommendations and/or implementation guidelines Rationale for Recommendation xx-xx (rationale 2): Re: [Dissenting View: In recognition Principle G, Applicant Freedom of Expression, timely applications for any string previously applied for but not yet delegated should be permitted, but such applications should not be processed further unless and until the matching string from the previous round has been classified as “Will Not Proceed”. The stated rationale for the Dissenting View was that applicants from prior rounds would retain too much power to (a) insist on non-compliance with new policy requirements applicable to subsequent procedures and (b) be able to effectively block later applicants for the same string who are willing to comply with new subsequent procedures policy requirements. Examples provided related to evolving name collisions policy and closed generics policy.] -- AAS3.2: Anne Aikman-Scalese proposed text to replace the paragraph above. Rationale: "Dissenting Views should be noted in the draft final report with more prominence and particularity as to the rationale for the Dissenting View." -- Call this a “dissenting view” since there isn’t a minority report as there is no consensus call. -- Need to decide if we are going to include dissenting views wherever they are and this report is going to capture all of them. -- In the preamble we can add some language with some dissenting views are included where a text was submitted, but this may not include all of the dissenting views. ACTION ITEM: Leadership will consider how/whether to call out dissenting views. 2.2.5 Applications Submission Limits c. New issues raised in deliberations since publication of the Initial Report, if applicable. Re: New text from Kathy Kleiman -- KK3.1 - Kathy Kleiman proposed alternative text for part C. Rationale: "The issue in our discussions wasn’t fairness (I think there was a strong view that allowing a few large players to dominate isn’t fair), but feasibility. How would we enforce limits? How could they be detected if subsidiaries were created? Certainly this issue of ownership has been reviewed and incorporated by other groups – foreign ownership restrictions, for example, on US broadcast stations by the FCC. But it was not something this group found feasible at this time. " ACTION ITEM: Leadership will consider how/whether to call out dissenting views. At least include the final paragraph. 2.2.6 RSP Pre-Evaluation c. New issues raised in deliberations since publication of the Initial Report, if applicable. Re: [Ultimately, the Working Group did not think a recommendation was necessary.] -- JC3.6 - Justine Chew suggested adding a sentence to the end of the paragraph. Rationale: "This last paragraph seems to lack a conclusion." ACTION ITEM: Accept the revised text in brackets.

1 0

Re: [Gnso-newgtld-wg] FW: Deadline April 30 - Comments on Revised Draft Recommendations - Package 2
by Emily Barabas June 2, 2020

June 2, 2020

Thank you, Anne, and my apologies for the oversight. The item is now captured on the wiki, in the tracking spreadsheet, and in the Production Document. Kind regards, Emily From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Tuesday, 2 June 2020 at 19:39 To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] FW: Deadline April 30 - Comments on Revised Draft Recommendations - Package 2 Dear WG members, Below is a description of my question about possible Code of Conduct exemptions to use unaccredited registrars. (This relates to Package 2.) Anne From: Aikman-Scalese, Anne Sent: Tuesday, April 28, 2020 1:43 PM To: 'Emily Barabas' <emily.barabas(a)icann.org>; gnso-newgtld-wg(a)icann.org Cc: Jeff Neuman <jeff.neuman(a)comlaude.com>; Cheryl Langdon-Orr (cheryl(a)hovtek.com.au) <cheryl(a)hovtek.com.au> Subject: RE: Deadline April 30 - Comments on Revised Draft Recommendations - Package 2 Thanks Emily. I am submitting an “issues sheet” comment on Package 2 but need to clarify the question shown in the attachment. The language in 2.10.2 redrafts the affirmation regarding the requirement to use ICANN-accredited registrars. It appears to state that the WG endorses the idea that a registry can get a Code of Conduct exemption that would allow it to use unaccredited registrars. I don’t recall that being a consensus of the Working Group so I am trying to understand why the document implies that we are okay with ICANN granting exemptions from the Code of Conduct to allow registries to use unaccredited registrars. I’m sure Jeff and Cheryl can shed some light on this. It’s possible I’ll have more comments on the Package 2 before the April 30 deadline. Thank you, Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Emily Barabas Sent: Thursday, April 23, 2020 1:13 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] Deadline April 30 - Comments on Revised Draft Recommendations - Package 2 [EXTERNAL] ________________________________ Dear all, As discussed on today’s call, the leadership team is releasing the second set of revised draft recommendations for your review. 1. There are 5 topics in package 2 here, beginning on page 17: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> * 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization * 2.5 Registrar Support for New gTLDs * 2.11.1 Registry System Testing * 2.12.1 TLD Rollout * 2.12.3 Contractual Compliance 1. Please limit comments to items in the revised sections that you absolutely “cannot live with.” If there is text that you cannot accept, please fill out the attached form and send it to the WG by email. Please do not provide your input in any other format. 1. Deadline for comments is Thursday April 30 at 23:59 UTC 1. Comments will be tracked here: https://community.icann.org/x/JDKJBw. Kind regards, Emily Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org [icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.icann.org_&d=DwMGaQ…> ________________________________ 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

Deadline April 30 - Comments on Revised Draft Recommendations - Package 2
by Emily Barabas June 2, 2020

June 2, 2020

Dear all, As discussed on today’s call, the leadership team is releasing the second set of revised draft recommendations for your review. 1. There are 5 topics in package 2 here, beginning on page 17: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… * 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization * 2.5 Registrar Support for New gTLDs * 2.11.1 Registry System Testing * 2.12.1 TLD Rollout * 2.12.3 Contractual Compliance 1. Please limit comments to items in the revised sections that you absolutely “cannot live with.” If there is text that you cannot accept, please fill out the attached form and send it to the WG by email. Please do not provide your input in any other format. 1. Deadline for comments is Thursday April 30 at 23:59 UTC 1. Comments will be tracked here: https://community.icann.org/x/JDKJBw. Kind regards, Emily Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

3 3

Post call | New gTLD Subsequent Procedures Working Group call | Tuesday, 02 June 2020 at 03:00 UTC
by Julie Bisland June 2, 2020

June 2, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Tuesday, 02 June 2020 at 03:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/0AAdC> (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

Pre-ICANN68 Policy Report now available!
by Terri Agnew June 1, 2020

June 1, 2020

Dear all, Just in time for the ICANN68 Prep Sessions, the Pre-ICANN68 Policy Report is now available: https://go.icann.org/pre68 For prep-week webinar dates and times, please check here: https://meetings.icann.org/en/remote68-prep-week Thank you. Kind regards, Terri

1 0

Post call | New gTLD Subsequent Procedures Working Group call | Thursday, 28 May 2020 at 20:00 UTC
by Andrea Glandon May 28, 2020

May 28, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 28 May 2020 at 20:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/0YPsBw> (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 Andrea

1 0