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+Pro.... 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/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7OG... 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.