March 2020 - Gnso-newgtld-wg

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 23 March 2000 UTC
by Julie Hedlund March 23, 2020

March 23, 2020

Dear Working Group members, Please see below the notes from the meeting on 23 March 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-03-23+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.8.1 Role of GAC Early Warnings/Advice CLEAN LANGUAGE -- Implementation Guidance xx (rationale 2): To the extent that the GAC provides Advice in the future on categories of TLDs, the Working Group urges the GAC to provide this Advice, and the Board to take any corresponding action, prior to the finalization of the next Applicant Guidebook. Once the application period has begun, the Working Group urges the GAC to limit Advice to individual applications only, based on the merits and details of the application for a particular string, not [only] on groups or classes of applications or string types. ACTION ITEM: Can the clean language be changed in a way that would satisfy the WG? Paul will gather a small group for a rewrite if necessary. Recommendation xx (rationale 3): ACTION ITEM: Re-write to emphasize that the AGB should reference the section of the Bylaws that govern how GAC Advice is addressed by the Board. Recommendation xx (rationale 4): ACTION ITEM: Change the first sentence to: “The Working Group recommends that GAC Early Warnings are issued during a period that is concurrent with the application comment period, as described in the 2012 Applicant Guidebook.” Delete sticken text and footnote. Recommendation xx (rationale 6): ACTION ITEM: Change the text to: “Relevant GAC members are strongly encouraged to make themselves available during a specified period of time period for direct dialogue with applicants impacted by GAC Early Warnings or GAC Advice to determine if a mutually acceptable solution can be found.” Delete stricken text (second instance of “period”). c. New issues raised in deliberations since publication of the Initial Report, if applicable. Re: CCT-RT Recommendation 33: ACTION ITEM: Leadership and staff to gather up categories on which the GAC has already provided advice and see if the WG has addressed or will address them. Notes: 1. Updates to Statements of Interest 2. Discussion of Final Report Topics – see the documents at: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7O… a. 2.8.1 Role of GAC Early Warnings/Advice Affirmation xx -- Suggested change from Paul McGrady: -- Add at the beginning, “The Working Group acknowledges the ability of the GAC to issue GAC Consensus Advice in accordance with the ICANN Bylaws.” ACTION ITEM: Leave in the reference to the section of the Bylaws. Clean Version Text: Implementation Guidance xx (rationale 2): To the extent that the GAC provides Advice in the future on categories of TLDs, the Working Group urges the GAC to provide this Advice, and the Board to take any corresponding action, prior to the finalization of the next Applicant Guidebook. Once the application period has begun, the Working Group urges the GAC to limit Advice to individual applications only, based on the merits and details of the application for a particular string, not [only] on groups or classes of applications or string types. Suggested changes from Paul McGrady -- Change Implementation Guidance to Recommendation: Implementation Guidance xx (rationale 2): Recommendation xx: To the extent that the GAC provides GAC Consensus Advice (as defined in the ICANN Bylaws) in the future on categories of TLDs, the Working Group urges the GAC to should provide this Advice, and the Board to take any corresponding action, prior to the finalization of the next Applicant Guidebook. In the event that such GAC Consensus Advice is issued after the finalization of the next Applicant Guidebook, the ICANN Board must, in the absence of extraordinary circumstances, vote to reject the GAC Consensus Advice. Once the application period has begun, the Working Group urges the GAC to limit should limit GAC Consensus Advice to that which applies to individual applicationsstrings only, based on the merits and details of the applications for a particularthat string, not [only] on groups or classes of applications or string types. [ In the event that GAC Consensus Advice is issued after the application period has begun and the GAC Consensus Advice applies to groups or classes of applications or string types, the ICANN Board must, absent extraordinary circumstances, vote to reject the GAC Consensus Advice.] Discussion: -- Concerns about the suggested edits -- that they would constrain GAC advice. -- Suggest a softer approach to encourage GAC to give its advice earlier. -- The GAC has been trying to look for ways to intercede in ways that are constructive. -- The GAC operates more efficiently now than it did during the early days of the last round. And is more engaged. -- Question: Where did we come out on the timing of public comment depending on the number of applications? Answer: There is a separate section that talks about timelines. Let’s focus on the substance of GAC Advice and Early Warning. -- It might be helpful to focus on the implications, say the advice on closed generics, in terms of a hypothetical -- how the language that Paul is suggesting would work. How do we ensure that the GAC gives the advice before the AGB is published. -- Concerned about trying to time limit when the GAC can give advice -- GAC cannot be expected to predict where it might need to provide advice. -- This would not preclude the GAC from issuing advice on single strings. This applied to GAC Advice for categories or groups of applications. GAC could still give advice on all of the individual strings in a particular category, and just not call it a “category”. -- I don’t think we can say what the Board “must” do -- even if they accept this recommendation. -- We could say that the Board should take into account whether the GAC had a clear opportunity to give this advice before the milestone (not deadline), in considering whether to adopt GAC advice. -- Stick to “urges” and not say “should” or “must”. ACTION ITEM: Can the clean language be changed in a way that would satisfy the WG? Paul will gather a small group for a rewrite if necessary. Recommendation xx (rationale 1): -- Suggestion to delete footnote #18. Recommendation xx (rationale 3): -- Question: How does ICANN Org “mitigate concerns”? I thought they facilitate mitigation between applicants and the GAC. Answer: There were a couple of ways it did in 2012, and we’re not stating how they should do it. They could use PICs. -- When we talk about a “strong presumption” we need another reference to the Bylaws to substitute for this. Need to refer applicants to the Bylaws section that governs this. It is referenced in footnote #19. We aren’t trying to write the AGB here. -- Should be more specific that there should be Implementation Guidance that the AGB has to reference the relevant section of the Bylaws. ACTION ITEM: Re-write to emphasize that the AGB should reference the section of the Bylaws that govern how GAC Advice is addressed by the Board. Recommendation xx (rationale 4): -- Reference to 2012 Applicant Guidebook is confusing. Suggests that the WG might be recommending the same time period as in the 2012 AGB. Delete “as described in the 2012 Applicant Guidebook” and the footnote. ACTION ITEM: Change the first sentence to: “The Working Group recommends that GAC Early Warnings are issued during a period that is concurrent with the application comment period, as described in the 2012 Applicant Guidebook.” Delete sticken text and footnote. c. New issues raised in deliberations since publication of the Initial Report, if applicable. Re: CCT-RT Recommendation 33 states: “As required by the October 2016 Bylaws, GAC consensus advice to the Board regarding gTLDs should also be clearly enunciated, actionable and accompanied by a rationale, permitting the Board to determine how to apply that advice. ICANN should provide a template to the GAC for advice related to specific TLDs, in order to provide a structure that includes all of these elements. In addition to providing a template, the Applicant Guidebook (AGB) should clarify the process and timelines by which GAC advice is expected for individual TLDs.” -- Question: Can we provide a recommendation that encourages the GAC to provide advice to applicants about strings that they would find concerning? What would be really helpful for applicants is to know that they are going down the wrong path. Answer: GAC could say that they have already provided advice on certain categories. It would be good for us to determine whether to incorporate that Advice first and then see if there are other categories that they are currently concerned about. ACTION ITEM: Leadership and staff to gather up categories on which the GAC has already provided advice and see if the WG has addressed or will address them. 3. AOB: Upcoming Meeting Planning -- We are going to keep the calls on the schedule. -- We record all the calls and the email list is open. -- We know this is a dynamic situation that could change rapidly.

1 0

(Corrected body) Post-ICANN67 Policy Report Now Available
by Julie Bisland March 23, 2020

March 23, 2020

Dear all, The Post-ICANN67 Policy Report is now available. Please click here to access it: https://go.icann.org/post67 [go.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__go.icann.org_post67&d=…> . Thank you. Kind regards, Julie -- Julie Bisland GNSO SO/AC Support coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Post-ICANN67 Policy Report Now Available
by Julie Bisland March 23, 2020

March 23, 2020

Dear all, The Post-ICANN66 Policy Report is now available. Please click here to access it: https://go.icann.org/post67 [go.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__go.icann.org_post67&d=…> . Thank you. Kind regards, Julie -- Julie Bisland GNSO SO/AC Support coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Monday, 23 March at 2000 UTC
by Julie Hedlund March 23, 2020

March 23, 2020

Dear all, Please find below the proposed agenda for the call on Monday, 23 March 2020 at 20:00 UTC for 90 minutes: Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Discussion of Final Report Topics – see the redlined documents at: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7O… * 2.8.1 Role of GAC Early Warnings/Advice – see attached PDF for clean version * 2.5.4 Applicant Support – see attached PDF for clean version 3. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie Julie Hedlund, Policy Director

2 1

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

March 19, 2020

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

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 19 March 2000 UTC
by Julie Hedlund March 19, 2020

March 19, 2020

Dear Working Group members, Please see below the notes from the meeting on 19 March 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-03-19+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.9.1 Community Applications -- page 32 on “extra credit” ACTION ITEM: Change “a problem inside a community” to “a problem inside a community to which the TLD relates.” 2.3.2. Registry commitments / Public Interest Commitments (formerly Global Public Interest) Recommendation xx (rationale 5): ACTION ITEM: Add an Implementation Guidance associated with Rationale 5 that the Implementation Team should ensure that for subsequent rounds all provisions of the PICDRP and associated processes shall equally apply to RVCs. ACTION ITEM: Add a footnote that the WG did not review the PICDRP. Also make a note to review this in final drafting. Recommendation xx (rationale 8): ACTION ITEM: Add a footnote that the WG did not discuss the DNS Abuse definition and is referencing the definition provided by the CCT-RT. ACTION ITEM: Leadership Team to draft a letter letting the GNSO Council know what our thinking is on the CCT-RT recommendations relating to DNS Abuse and referring the issue to the Council. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Discussion of Final Report Topics – see the documents at: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7O… a. 2.9.1 Community Applications – but limited to the “proposal to grant ‘extra credit’ in CPE to applicants that help or solve a problem inside a community” in c. New issues raised in deliberations, page 32 “The Working Group discussed a proposal to grant “extra credit” in CPE to applicants that help or solve a problem inside a community. The Working Group noted that if it were to make a recommendation in this regard, it might be helpful to suggest a specific adjustment to the CPE Guidelines and scoring criteria. No specific proposal has yet been put forward.” Discussion: -- Question: What does “community” mean here? Answer: The TLD community where there is a problem -- not the general ICANN community. -- Has there been any analysis of all of the community applications that were submitted to determine whether the cause was a difficulty of applicants in answering the community-specific AGB questions, or the cause occurred through scoring? If the cause of low numbers is that applicants had difficulty with answering the community criteria, then we need to provide guidance, not 'extra credit'. -- Tighten "a community" to "a community to which the TLD relates" . -- Most community applicants when they were submitting an application thought they were solving a problem. Seems like we are solving a problem that we could solve in a different way, such as better evaluation of applications -- the scoring kept applications from being successful. -- Not sure that the evaluators have the skill to determine whether to assign “extra credit”. -- We did talk extensively about the evaluators and recommendations and being careful when it came to letters of support and opposition. What else is meant by “better scoring”. Should there be different criteria or should the scoring be changed? Hard question to answer. We can’t test it until we have another round -- can’t tell if the changes we are suggesting will result in improvements. -- There is a CPE review report where ICANN hired an independent party to see if the CPE evaluator followed the criteria in doing its work and didn’t find any problems. -- Applicants didn’t have all of the information they needed. -- If we are going to accept this proposal it can’t be just for garden-variety problems -- maybe novel or innovative. ACTION ITEM: Change “a problem inside a community” to “a problem inside a community to which the TLD relates.” b. 2.3.2. Registry commitments / Public Interest Commitments (formerly Global Public Interest) Recommendation xx (rationale 4): ICANN must allow applicants to submit Registry Voluntary Commitments (RVCs)(previously called voluntary PICs) in subsequent rounds in their applications and/or to respond to public comments, objections, GAC Early Warnings, and/or GAC Advice. Applicants must be able to submit RVCs at any time prior to the execution of a Registry Agreement; provided, however, that all RVCs submitted after the application submission date shall be considered Application Changes and be subject to the recommendation set forth in Section xx Application Changes Requests. Recommendation xx (rationale 5): RVCs must continue to be included in the applicant’s Registry Agreement. In addition, for subsequent rounds all provisions of the PICDRP and associated processes shall equally apply to RVCs. Discussion: -- We didn’t make any substantive changes, we just moved things around. -- Question: Do we need to change the PICDRP to refer to RVCs? Or will that happen automatically when the Board approves this recommendation? Answer: RPMs did not look at the PICDRP, but the TM-PDDRP. The Implementation Team will make sure the references are changed. -- If it’s expected that the PICDRP would be updated to incorporate RVCs, would be helpful to note this in implementation guidance. -- We need to note this in implementation guidance. This may need to be sent to RPMs Phase 2, since the PICDRP is a (sort of?) RPM. -- Note that the PICDRP has not been reviewed by the PDP WG. -- Re: “associated processes” this refers to everything out there where PICs are mentioned -- that wherever PICs are mentioned they also apply to RVCs. ACTION ITEM: Add an Implementation Guidance associated with Rationale 5 that the Implementation Team should ensure that for subsequent rounds all provisions of the PICDRP and associated processes shall equally apply to RVCs. ACTION ITEM: Add a footnote that the WG did not review the PICDRP. Also make a note to review this in final drafting. Recommendation xx (rationale 6): At the time an RVC is made, the applicant must set forth whether such commitment is limited in time, duration and/or scope. Further, an Applicant must include its reasons and purposes for making such RVCs such that the commitments can adequately be considered by any entity or panel (e.g., a party providing a relevant public comment (if applicable), an existing objector (if applicable) and/or the GAC (if the RVC was in response to a GAC Early Warning or GAC Advice)) to understand if the RVC addresses the underlying concern(s). Discussion: -- Question: Just for clarity, what process is meant to apply if the RVCs do not address the underlying concerns? According to whoever evaluates them. Answer: It depends on the context in which it is submitted as to whether that solves the objection. If it doesn’t satisfy GAC Advice then GAC Advice will stand. If it doesn’t satisfy the objector then the objector’s concerns stands. -- Question: Who will be evaluating the RVCs - how do you pass or fail rationale 6 or 7? Answer: It’s not like we are saying there needs to be a clarity police, but if it is in the application it will be looked at by everyone. But if an RVC has committed to something because of a GAC Early Warning then the only party that needs to be satisfied is the GAC. -- So the "connection" to "until the "reviewer" is satisfied that the RVC addresses their concern" is missing . -- Answer: Where in this draft does it say that all RVCs must go out for public comment and are application changes? Answer: Rationale 4 and also in the Application Change Request section. Recommendation xx (rationale 8): The Working Group acknowledges ongoing important work in the community on the topic of DNS abuse and believes a holistic solution is needed to account for DNS abuse in all gTLDs as opposed to dealing with these recommendations with respect to only the introduction of subsequent new gTLDs. In addition, recommending new requirements that would only apply to the new gTLDs added to the root in subsequent rounds could result in singling out those new gTLDs for disparate treatment in contravention of the ICANN Bylaws. Therefore, this PDP Working Group is not making any recommendations with respect to mitigating domain name abuse other than stating that any such future effort must apply to both existing and new gTLDs (and potentially ccTLDs). The Working Group has reached this conclusion after duly considering the DNS Abuse related CCT-RT recommendations, which includes 14, 15, and 16. Note however that at the time of the drafting of this report, the ICANN Board only passed through a portion of recommendation 16 to this Working Group (amongst several other community groups) and recommendations 14 and 15 remain in a “Pending” status. Discussion: -- Question: Do we want to include a definition of DNS abuse? Answer: It is addressed in the CCT-RT recommendations and we reference them. -- Concern that there will be a bottleneck at the Board if we don’t address what is DNS abuse. -- Could refer this to the GNSO Council for them to address it instead of the PDP. ACTION ITEM: Add a footnote that the WG did not discuss the DNS Abuse definition and is referencing the definition provided by the CCT-RT. ACTION ITEM: Leadership Team to draft a letter letting the GNSO Council know what our thinking is on the CCT-RT recommendations relating to DNS Abuse and referring the issue to the Council. 3. AOB: Framework for Reviewing Draft Recommendations -- When a set of revised sections are ready for review by the WG, the leadership team will add a “clean” version of those sections to a new document, what we are tentatively calling the “Production” document, which will be read-only. -- These sections will be released in logical clusters starting in a week or so, beginning with sections relating to Pre-Launch Activities. --- The leadership team will send an email to the group with the date by which any comments on those sections should be provided -- in 7 days. -- A redline of the revisions will be available in the Working Document for reference, but once the revision is sent out, members should not add new comments or suggestions in the Working Document. Instead, they should follow the process below. -- The Working Group will use the method used successfully by the EPDP Team in the finalization of their Initial Report. -- Specifically, WG members will be asked to limit comments to items in the revised section that they absolutely “cannot live with.” If there is text that they cannot accept, they will fill out a form like the one attached and send it to the WG by email. -- The form asks for the specified text that the WG member cannot accept, a suggested revision, and the rationale for the revision. -- Any issues identified will be addressed and resolved on the mailing list, or if necessary, scheduled for discussion on a subsequent call. Discussion: -- Concerns raised about the ability of WG members to respond to tight deadlines given the added burdens produced by the coronavirus pandemic. -- Note that we have a work plan to follow, but will take it one step at a time and determine whether deadlines need to be extended.

1 0

Updated Subject Line: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 16 March 1500 UTC
by Julie Hedlund March 19, 2020

March 19, 2020

With Correct Subject Line Dear Working Group members, Please see below the notes from the meeting on 16 March 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-03-16+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Recommendation xx (rationale 4): ACTION ITEM: Move the Implementation Guidance into the recommendation. Paul McGrady and Anne Aikman-Scalese will work on developing language relating to “if deemed necessary” in the AGB, paragraph 2, 4.2.3, pages 4-9. Re: Qualifications of Panelists: ACTION ITEM: Note that we had not developed a recommendation relating to the qualifications of the panelists and need to consider the need for a quantitative and qualitative assessment by experts in communities. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Discussion of Final Report Topics – see the documents at: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7O… and attached as a PDF. a. 2.9.1 Community Applications -- Does the WG want to affirm or otherwise address this PIRR recommendation? Recommendation 4.1.a: Consider all dimensions of the feedback received to revisit the CPE scoring and framework before the next application round. Comment from Jeff: Comment from Jeff Neuman: Technically I am note sure we are affirming this whole Guideline F. For example, I am not sure yet whether we will allow mutual agreement resolution...and the last part about giving the ICANN Board discretion, etc. The only thing we are affirming is the priority of communities in a contention set. COMMENT IS ADDRESSED. -- Comment from Staff: Does the WG want to provide any detail here? Request from ICANN org: "It would be helpful if the PDP Working Group could provide more detailed guidance on the specific areas of the CPE process that “must be more transparent and predictable.” Additionally, it would be helpful if the PDP Working Group could provide more specific guidance on what should be changed or added that would enhance transparency and predictability for the CPE process." -- Started a thread on changes to the CPE guidelines. ACTION ITEM: Staff to send the updates to the CPE guidelines based on the WG discussions. DONE: See -- https://docs.google.com/document/d/1Ih_1NARViJXNNewDg-q87sQzQoC1dCtC/edit. Recommendation xx (rationale 4): ICANN must consider ways to improve evaluators’ ability to gather information about an application. Implementation Guidance xx (rationale 4): Evaluators should continue to be able to send clarifying questions to CPE applicants but further, should be able to engage in written dialogue with them as well. Implementation Guidance xx (rationale 4): Evaluators should be able to issue clarifying questions, or utilize similar methods to address potential issues, to those who submit letters of opposition to community-based applications. Discussion: -- Question: Did we get access to the actual research of the evaluators? Answer: We didn’t, but they did refer to research in their decisions. This was not consistent. -- There should be no basis for an independent evaluator to do his or her own research. Worried about how this recommendation was developed. -- Not all of the facts may be in the application, which is different from the UDRP. There should be research that may need to be done. -- Shouldn’t that be on the complaining party to make their case? -- We are saying that if there is independent research that is allowed then ICANN should improve evaluators ability to get information. -- Perhaps it would be helpful to add to the recommendation “as described in the IG below” or “as set out in the Implementation Guidance below.” -- It's okay for evaluators to find independent info - but they should disclose sources when ruling on the CPE. -- The application should be robust and supported.  And the public gets a chance to comment, right? -- If you have support from major organizations, how does an evaluator know that they are real? They aren’t likely to be subject-matter experts. -- If they are going to be doing research they could research who these organizations are to make sure they meet the requirements to support the application. -- Anything that an evaluator is relying on should be disclosed to the applicant, particularly since we’ll have an appeal process. The applicant has to have the ability to challenge any independently developed information. -- Trying to choose between two models 1) that the applicant should put together a robust application, encourages a robust public comment period, and discourages the evaluator from being in the role of a biased researcher 2) evaluators being inadvertently advocating for third parties that didn’t show up. -- If we have all these criteria doesn’t it make sense that due diligence is done provided they give the applicant the ability to do clarifying questions in response. For example, the requirement for the uniqueness of the string would seem to be something that would require independent research. Also, documented support from the recognized community institutions. -- Shouldn’t rely only on the information provided by the applicant. -- The examiner should rely on a fulsome record, rather than create their own record. There is a requirement to gauge opposition from third parties. We should figure out a way to make them narrow, as with the Implementation Guidance -- maybe move those into the recommendation. -- Don’t agree that we ban a panelist from doing outside research. Seems too extreme. -- We are lacking notice to competitors. Need to let the examiners look at opposition. -- Say, “In the event panelist(s) rely on independent research, that will be disclosed to the applicant through a Clarifying Question and the applicant should be allowed to respond prior to ruling. ” -- If we require the evaluator to notify the applicant, isn’t the applicant just going to push back? The applicant should just have to provide a fulsome application. -- If the applicant provides links/sources then at a minimum the evaluator can look at those links. -- But how would an evaluator know that a term is commonly used in other industries without doing research. The Applicant is not going to put that into its own application. -- Needs to be very clear that there isn’t just a request for a string with nothing to support it. It is one thing for the evaluator to confirm the information, but another for an evaluator to seek out opposition to it. -- Need to remember that this is an evaluation -- in other evaluations in ICANN, say financial, does the evaluator only rely on what is provided by the applicant. -- Add “except as needed for verification purposes and should be disclosed”. To verify the information. -- Does the AGB currently allow evaluators to do research? Research is specifically noted. In paragraph 2 in 4.2.3. Bottom of the paragraph, pages 4-9. We are working on putting some guardrails around this. -- Need to figure out what “if deemed necessary” means. -- If we limit the ability of the evaluator to do research we should call that out in the public comment as it is a fairly significant change. -- Important to encourage dialog, but can’t require it. If you have a community application that has overwhelming support, those who are in opposition should step up and encouraged to enter into a dialog. -- The amount of opposition should be compared to the amount of support. 5 letters of opposition might be irrelevant - if you have 500 letters of support. 1 or 2 letters shouldn't automatically cost a point. Opposition should be weighed against support. -- There should be a public and transparent verification of an organization stating opposition in a letter. ACTION ITEM: Move the Implementation Guidance into the recommendation. Paul McGrady and Anne Aikman-Scalese will work on developing language relating to “if deemed necessary” in the AGB, paragraph 2, 4.2.3, pages 4-9. Jamie Baxter also should consider what should be added in order to encourage dialog, and public and transparent verification of statements of opposition. Re: The Working Group notes that CCT-RT Recommendation 34 states: “A thorough review of the procedures and objectives for community based applications should be carried out and improvements made to address and correct the concerns raised before a new gTLD application process is launched. Revisions or adjustments should be clearly reflected in an updated version of the 2012 AGB.” -- Staff Comment: From the CCT-RT recommendations tracking spreadsheet: As the WG refines recommendations on this topic, it may want to consider whether to make additional recommendations regarding objectives. Note that the CCT-RT recommendations consider "a higher rate of success for such applications" to be a measure of success. -- Are we trying to get a higher success rate and what can be done other than the recommendations we’ve already made? -- Need to have a requirement that the evaluators are knowledgeable about the community. Need to avoid the mistakes from the previous round. -- We do have a section on accountability and appeals -- in the section on Accountability Mechanisms. -- The qualifications of the panelists is not something we spent a lot of time on. Need to see if we can improve that. -- Need quantitative and qualitative assessment by experts in communities.  ACTION ITEM: Note that we had not developed a recommendation relating to the qualifications of the panelists and need to consider the need for a quantitative and qualitative assessment by experts in communities.

6 6

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 19 March 2000 UTC
by Julie Hedlund March 18, 2020

March 18, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 19 March 2020 at 20:00 UTC for 90 minutes: Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Discussion of Final Report Topics – see the documents at: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7O… * 2.9.1 Community Applications – but limited to the “proposal to grant ‘extra credit’ in CPE to applicants that help or solve a problem inside a community” in c. New issues raised in deliberations, page 32 * 2.3.2. Registry commitments / Public Interest Commitments (formerly Global Public Interest) – see attached PDF for clean version * 2.8.1 Role of GAC Early Warnings/Advice (time permitting) – see attached PDF for clean version 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

ICANN Community Excellence Award - Nomination Closes 27 March 2020
by Andrea Glandon March 17, 2020

March 17, 2020

https://www.icann.org/news/announcement-2-2020-03-16-en [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_ann…> ICANN Community Excellence Award: Nomination Closes 27 March 2020 LOS ANGELES – 16 March 2020 – The Internet Corporation for Assigned Names and Numbers (ICANN) reminds community members that the nomination period for ICANN's Community Excellence Award is open until 27 March 2020 23:59 Universal Coordinated Time (UTC). The ICANN Community Excellence Award recognizes community members who have significantly invested in consensus-based solutions and have contributed substantively to the ICANN multistakeholder model. The ideal recipient(s) will have: · Participated in the ICANN community for a minimum of five years. · Served in multiple ICANN working groups or committees. · Collaborated significantly with more than one Supporting Organization (SO) and/or Advisory Committee (AC). Candidates will be evaluated by a panel of community members appointed by the SO/AC chairs using a merit-based point system evaluated against three criteria: 1. Demonstrates an ability to work across community lines with both familiar and unfamiliar ICANN stakeholders with the aim of building consensus. 2. Facilitates dialogue and open discussion in a fair and collegial manner through the spirit of collaboration, showing empathy and demonstrating a sincere desire to engage with people from other backgrounds, cultures, and interests. 3. Demonstrates additional support for ICANN multistakeholder model and its overall effectiveness through volunteer service via working groups or committees. Please submit nominations via this nomination form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_forms_…> and include detailed information outlining why the nominee meets the award criteria. Any additional information in support of nominations and/or questions about the award process may be submitted to exellenceaward2020(a)icann.org<mailto:excellenceaward2020@icann.org>. Award recipient(s) will be announced in June 2020 at ICANN68 in Kuala Lumpur. For more information on the award program, please refer to the ICANN Community Wiki.<https://community.icann.org/x/YyOAAw>

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 09 March 1715 UTC
by Julie Hedlund March 16, 2020

March 16, 2020

Dear Working Group members, Please see below the notes from WG Session #1 on 09 March at 1715 UTC at the ICANN67 Virtual Meeting. 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-03-09+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: 1. Updates to Statements of Interest: No updates provided. 2. Discussion of Final Report Topics – see the documents at: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7O… and attached as a PDF. Overview: -- All of these sessions are official sessions of the SubPro WG and being conducted in a manner that we normally conduct our meetings. -- May have non-WG participants. -- The topics we are addressing are ones the WG have addressed many times already. -- Giving preference to WG members, but we’ll end each subject with open comments. a. 2.7.3 Closed Generics a. Recommendations and/or implementation guidelines “Although the Working Group has had numerous discussions about this topic, and received extensive comments from the community, received a number of comments on this, the Working Group was not able to agree as to how to treat these applications in subsequent rounds.” -- Suggested edit: “Edit: “and received extensive comments from the community, received a number of comments on this,” -- second clause is duplicative, suggestion is to delete “received a number of comments on this”. Discussion: -- Asked for proposals to be submitted. Received a couple of proposals. -- I disagree with this approach (and am on record previously with it) I think knowing what the status quo is will help people realized the downside of not trying to reach consensus. And we need to be consistent because it’s very easy to say the SQ is the AGB but in other places, leadership says SQ is "implementation." <QUESTION> Since there is no clear agreement on how to treat closed generics moving forward, is it the case that until a GNSO PDP ultimately (if ever) makes a specific recommendation to change their treatment, they will continue to effectively be prohibited based on the referenced Board resolution? </QUESTION> -- Question: Where is the definition of closed generics so that people know what we are talking about? Answer: It is in the GAC Beijing Communique. They listed a number of strings and whether it is proposed to be open or closed. No extensive review of any of those applications. Some that they indicated were closed generics were not. The definition of closed generics is in Specification 11 of the Registry Agreement. -- The Board specifically asked the WG to look at the issue of closed generics. -- When we talk about serving a public interest goal, what are we talking about? If we look at it from the public interest of being in receipt of the content is that who are talking about? -- Difficult to define and depends on who is defining it. The idea is that the GAC is supposed to define it. A bigger question is what do we want the DNS to be? -- We have tried to define or discussed the public interest for a long time. We have generally come to the conclusion is that we will never have a definition, but just a set of examples of how we would recognize the public interest, or if we can’t agree on that methodology then we can’t come to consensus. -- Maybe we should try to define what we want to avoid. -- Seem to be stuck on the idea that registrants want to register every gTLD. That just doesn’t seem supported by reality. It would be good if we could talk about what we want to avoid. -- We should be looking at what is the adequate governance model for accountability for the affected community. -- Public authorities or non-profit organizations could make better use of a closed generic than a commercial entity could. Could be decided whether the intended use is commercial or non-commercial. Proposed questions from Anne Aikman-Scalese that could be used in an evaluation process by a panel or an objection process: 1. Does the proposed closed registry serve a public good? 2. Is the proposed mission and purpose of the registry innovative in nature? 3. What is the likely effect on competition of awarding the proposed closed registry for the same or similar goods and/or services? Is it minimal or is it vast? 4. Is there more than one proposed closed registry application for the same string and if so, how can these be evaluated for preference, e.g. scoring system. 5. Should there be restrictions on resale of the proposed Closed Registry? 6. What specific Public Interest Commitments are proposed by the registry and how can these be effectively monitored and enforced? Would additional fees be due from such a registry in order to pay for enforcement of these PICs, e.g by ICANN Compliance staff set up for this purpose? -- Important to try to figure out a framework to make this work. -- Example of competitive behavior: mergers are looked at in advance by the US government, but the starting point is not that all mergers are bad. The presupposition isn’t that you can’t do it. -- Defining questions may help us to define what needs to be avoided. -- To the example of mergers, there isn’t a supposition that they are bad, just that there might need to be guardrails. -- Can we identify the harms and problem solve for them? What do we think is anti-competitive or undue discrimination? -- As an example, what if Daimler-Chrysler wants to operate .sedan? What if GM doesn’t want .sedan? We are assuming that everyone else wants to have their name in .sedan. -- Lots of industries have generic terms that represent them and that they want to be closed. -- More concerned with the ability to take recourse action if anything went wrong, if we are able to get to some sort of compromise -- enforcement would be an element. -- If we are talking about anti-competitiveness you can put in specific guardrails -- that is a problem we can solve. -- We are talking about genus versus species. -- Everyone is worried about consumer choice, but some TLDs would like to focus on consumer trust and innovation.

1 1