June 2020 - Gnso-newgtld-wg

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 08 June 1500 UTC
by Julie Hedlund June 8, 2020

June 8, 2020

Dear Working Group members, Please see below the notes from the meeting on 08 June at 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-06-08+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: a. Community Applications (independent research, GAC input) [Recommendation xx (rationale 6): ACTION ITEM: Accept the additional text and clarify who is able to respond (applicant). ACTION ITEM: Change the language from “verify the community status of the applicant” to “evaluate the application”. b. Application Queuing (IDNs proposal), ACTION ITEM: Accept the new text and include in the “Can’t Live With” package #6. c. Applicant Support (multipliers at auction) in 2.1 Auctions: Mechanisms of Last Resort & 2.2 Private Resolution of Contention Sets (Including Private Auction), page 6 c. New issues raised in deliberations since publication of the Initial Report, if applicable. [The Working Group considered a proposal that a fixed multiplier should apply to bids submitted by certain qualified applicants in sealed-bid auctions of last resort. As an example, applicants that have qualified for support under the Applicant Support Program (ASP) could have their bid automatically upgraded by a fixed multiplier, such as factor of 1.5. As an illustration of this example, an applicant’s bid of $400,000 would count as a bid of $600,000 in the auction. Some Working Group members believe that a multiplier would “level the playing field” for qualified applicants who might not otherwise be in a position to submit winning bids. The Working Group did not reach a conclusion on this proposal.] ACTION ITEM: Add as recommendation under Applicant Support. There must be a bid credit in the form of a multiplier or other mechanism, but that bid credit should be established by the IRT with public comment. Integrate research component to be completed in implementation. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Discussion of Final Report Topics: a. Community Applications (independent research, GAC input), pages 129, 131, and 133 Page 129: [Recommendation xx (rationale 6): If the Community Priority Evaluation Panel conducts independent research while evaluating an application, limitations on this research and additional requirements must apply. The Working Group recommends including the following text in the Applicant Guidebook: “The Community Priority Evaluation Panel may perform independent research deemed necessary to verify the community status of the applicant (the “Limited Research”), provided, however, that the evaluator shall disclose the results of such Limited Research to the applicant and the applicant shall be provided 30 days to respond before the evaluation decision is rendered. When conducting any such Limited Research, panelists are cautioned not to assume an advocacy role either for or against such community status.”] Discussion: -- Not sure how ICANN would determine compliance. -- At the end of the day we have to rely on the integrity of the panelists. -- Question: What is the timing of the reveal of the research/sources to the applicant? Answer: Before the evaluation decision is rendered, whether positive or negative. The applicant has 30 days to respond. It was the intent that the applicant would have the information before the ruling so the applicant could see what might need to be rebutted. -- Question: Does anyone other than the applicant see this? Wouldn’t it have to be publicly available? Answer: This is a one-party proceeding. Opening up would make it too complicated. This isn’t an objection proceeding. -- Question: What if the applicant wanted someone else to comment? Answer: The applicant can include that in the response. -- Question: Can we make the language more specific about who is involved in this process? If we don’t specifically say that this is a one-party process then it can be opened up to others. Answer: If you look elsewhere in this recommendation we have details about the public comment period, etc. We need to look at it in context. The opponent has the opportunity to appeal. -- "Relevant" or "adopted" material to be appended to determination. Provides material for establishing grounds for challenge / appeal. -- Anything relied on by the evaluator to make the decision needs to be disclosed. -- Question re: the “status of the applicant” -- is research limited to this option or applied to all 4 elements of the evaluation or is Nexus an option? Answer: Concern was that the panelist shouldn’t act as an advocate. As far as the elements, it would be strange to limit it to a single element. -- Change the language from “verify the community status of the applicant” to “evaluate the application”. ACTION ITEM: Accept the additional text and clarify who is able to respond (applicant). ACTION ITEM: Change the language from “verify the community status of the applicant” to “evaluate the application”. b. Application Queuing (IDNs proposal), page 50 Given that no agreement has been reached in the Working Group, the status quo as implemented controls, meaning continued prioritization of IDNs in future application rounds. Recommendation xx: For Subsequent rounds, the Working Group recommends that the following formula must be used with respect to giving priority to Internationalized Domain Name applications…[See details on page 50, 51, and 52 of https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…] Discussion: -- Question: Why assume batches and 500? Answer: Because that is what the AGB already has to keep it simple. -- It doesn’t matter if it is batches of 500, if you maintain the principle (the percentages). -- Question: If we have 10,000 applications, what would be the batch for IDNs? Answer: See the example in the rationale on page 52. -- The only thing that is limiting is the number of IDN applications. -- Concern about the use of the term “batch” as that was not what was done in 2012. ACTION ITEM: Accept the new text and include in the “Can’t Live With” package #6. c. Applicant Support (multipliers at auction) in 2.1 Auctions: Mechanisms of Last Resort & 2.2 Private Resolution of Contention Sets (Including Private Auction), page 6 c. New issues raised in deliberations since publication of the Initial Report, if applicable. The Working Group considered a proposal that a fixed multiplier should apply to bids submitted by certain qualified applicants in sealed-bid auctions of last resort. As an example, applicants that have qualified for support under the Applicant Support Program (ASP) could have their bid automatically upgraded by a fixed multiplier, such as factor of 1.5. As an illustration of this example, an applicant’s bid of $400,000 would count as a bid of $600,000 in the auction. Some Working Group members believe that a multiplier would “level the playing field” for qualified applicants who might not otherwise be in a position to submit winning bids. The Working Group did not reach a conclusion on this proposal. Discussion: -- We should limit the multiplier to a maximum, and leave the IRT to pick a number between 1 and ceiling. -- From a policy perspective we support a multiplier but leave it up to the IRT to determine the multiplier. -- Question: Do we want this to be a recommendation or implementation guidance? Answer: Change to a recommendation. -- Need to have something in here to prevent transfer of ownership from being gamed, such as a time period. ACTION ITEM: Add as recommendation under Applicant Support. There must be a bid credit in the form of a multiplier or other mechanism, but that bid credit should be established by the IRT with public comment. Integrate research component to be completed in implementation.

1 0

Post Call / New gTLD Subsequent Procedures Working Group / Monday, 08 June 2020 at 15:00 UTC
by Michelle DeSmyter June 8, 2020

June 8, 2020

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

Deadline 16 June - Comments on Revised Draft Recommendations - Package 5
by Steve Chan June 6, 2020

June 6, 2020

Dear all, The leadership team is releasing the fifth set of revised draft recommendations for your review. There are 9 topics in package 5 here, beginning on page 74: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [docs.google.com] Note that the Geographic Names report from Work Track 5 is provided separately, below. · 2.2.7 Metrics and Monitoring (This topic is intended to serve as an aggregation point for the metrics based recommendations from the various topics. Deliberations occurred in the context of the directly related topic.) · 2.5.4 Applicant Support (last discussed 26 Mar) · 2.4 Application Change Requests (last discussed 14 Apr) · 2.7.1 Reserved Names (last discussed 23 Apr) · 2.8.1 Objections: GAC Early Warning and GAC Advice (last discussed 7 May) · 2.8.2 Limited Challenge/Appeal Mechanism (formerly Accountability Mechanisms) (last discussed 20 Apr). Note, an Annex is referenced in this section which will eventually mean the spreadsheet the WG developed here. · 2.8.2 Post-Delegation Dispute Resolution Procedures (formerly Accountability Mechanisms) (last discussed 23 Apr) · 2.10.1 Base Registry Agreement (last discussed 9 Apr) · 2.7.1.2 Geographic Names (last discussed by the full WG at ICANN66 in Montreal on 2 Nov 2019). The WT5 report is available here, unchanged from when it was delivered to the full WG on 22 October 2019. 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. Because of the size of this particular package, the deadline for comments is Tuesday 16 June at 23:59 UTC Comments will be tracked here: https://community.icann.org/x/JDKJBw. Best, Steve Steven Chan  Policy Director, GNSO Support Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  Email: steve.chan(a)icann.org Skype: steve.chan55 Mobile: +1.310.339.4410 Find out more about the GNSO by visiting: https://learn.icann.org/ Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar

2 1

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Monday, 08 June at 15:00 UTC for 90 Minutes
by Julie Hedlund June 5, 2020

June 5, 2020

Dear all, Please find below the proposed agenda for the call on Monday, 08 June 2020 at 15:00 UTC for 90 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Discussion of Final Report Topics – See: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… * Applicant Support (multipliers at auction) in 2.1 Auctions: Mechanisms of Last Resort & 2.2 Private Resolution of Contention Sets (Including Private Auction), page 6 * Application Queuing (IDNs proposal), page 50 * Community Applications (independent research, GAC input), pages 129, 131, and 133 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

1 0

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

June 5, 2020

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

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