Dear Working Group members, Please see below the notes from WG Session #2 on 10 March at 1700 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-10+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Recommendation xx (rationale 2): ACTION ITEM: Re: “Specification 11 3(a)-(d) of the Registry Agreement” -- Include footnote with text of these mandatory PICs. ACTION ITEM: Add Closed Generics to the dependencies. Recommendation xx (rationale 4): ACTION ITEM: In rationale 6 reference changes to applications and processes associated with those changes, including public comment. ACTION ITEM: Add that any RVCs that are agreed to are considered an application change and reference that section of the report. Recommendation xx (rationale 6): ACTION ITEM: Instead of “reviewed by ICANN” change to whatever entity or panel is reviewing whether the RVC addresses the underlying concern that resulted in the RVC. Recommendation xx (rationale 8): ACTION ITEM: Add a comment/question as to whether “all TLDs” refers to all gTLDs or only to new gTLDs. ACTION ITEM: Staff will check to see if the Board referred 14/15/16 to the GNSO Council and thus to SubPro. ACTION ITEM: Need to include the status of the pending CCT-RT recommendations as to whether this should be a WG recommendation. Check to see if there is another way to reword this instead of as a recommendation. 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... and attached as a PDF. Overarching Question: -- Question: Seek clarification on what is the status of the document we are discussing? Answer: These are draft final recommendations based on a lot of work that the WG has done. These are not final recommendations and everything is going out for public comment. a. Public Interest Commitments (aka Registry Commitments) (in 2.3.2. Global Public Interest) -- Change the title “Global Public Interest” to something clearer. This is a historical title. Keep a reference to the former title. Perhaps call it Registry Commitments. -- Need to keep the term "Public Interest" because the enforcement tool at present is the "Public Interest Commitment Dispute Resolution Procedure" Call it "Registry Public Interest Commitments?" -- Not covering enforcement here, that is in the section covering PICDRP. Recommendation xx (rationale 2): Mandatory Public Interest Commitments (PICs) currently captured in Specification 11 3(a)-(d) of the Registry Agreement must continue to be included in Registry Agreements for gTLDs in subsequent procedures. No additional mandatory PICs are needed at this time. Noting that Mandatory PICs were not included in the 2007 recommendations, this recommendation codifies existing practice into policy. One adjustment to the 2012 implementation is included in the following recommendation (Recommendation xx (rationale 3)). Discussion: -- Single-registrant is a TLD with a waiver on code of conduct (Spec 9). Those can be either Spec 9-only or Spec 9+Spec 13. All Spec 13 RAs are also exempted from Spec 9. -- Need to flag a dependency that goes back to Closed Generics. Check to make sure that we are consistent with what we are waiving in the mandatory PICs. -- Suggest changing voluntary PICs to “Registry Voluntary Commitments”. ACTION ITEM: Re: “Specification 11 3(a)-(d) of the Registry Agreement” -- Include footnote with text of these mandatory PICs and note that the recommendation doesn’t apply to Specs 11 3(c) and (d). ACTION ITEM: Add Closed Generics to the dependencies. Recommendation xx (rationale 4): ICANN must continue to provide applicants with the opportunity to submit Registry Voluntary Commitments (RVCs) (previously called voluntary PICs) in subsequent rounds. Applicants must be able to submit RVCs at the time of application submission as well as at any other time prior to the execution of a Registry Agreement. RVCs will 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: -- Question: Are we still saying that anyone can put anything into a registry agreement? Answer: We do discuss the issue of changes to applications in the deliberations section. ACTION ITEM: In rationale 6 reference changes to applications and processes associated with those changes, including public comment. ACTION ITEM: Add that any RVCs that are agreed to are considered an application change and reference that section of the report. Recommendation xx (rationale 5): Applicants must also be allowed to commit to additional RVCs, or modify proposed RVCs, in response to public comments, objections, GAC Early Warnings, and/or GAC Advice. -- Question: What is the public comment after the commitment to additional RVCs? Answer: We are saying these are application changes and are governed by those recommendations. Reference the application change request section rather than duplicating language. 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 such that the commitment can adequately be reviewed by ICANN, 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). Discussion: -- Comment from ICANN Org: “Note request from ICANN org to clarify what is meant by “reviewed by ICANN” (i.e., an evaluation, a completeness check, or something else)” -- Put in a note as to whether that review can be reviewed by the public. -- Don’t think it is appropriate for objections to be resolved through private voluntary commitments on which there is no public comment. -- Note that rationale 7 says, “Recommendation xx (rationale 7): Any proposed changes to RVCs, including additions or changes, must be subject to public comment.” ACTION ITEM: Instead of “reviewed by ICANN” change to whatever entity or panel is reviewing whether the RVC addresses the underlying concern that resulted in the RVC. Recommendation xx (rationale 8): The Working Group acknowledges ongoing work in the community on the topic of DNS abuse and recommends that the community continues to take steps to address CCT-RT recommendations 14, 15, and 16 through community-wide discussions that address DNS abuse in all TLDs as opposed to dealing with these recommendations with respect to only the introduction of subsequent new gTLDs. Discussion: -- Don't think it's necessary to say "address the CCT recommendations." The Board is doing that. It feels obvious. -- Question: What does this exactly mean? Where would this policy work need to happen? Would there need to be another PDP? Answer: If the community works out this issue on DNS abuse then it would be included in new registry agreements and into existing agreements. The intent is not to say that this issue isn’t important, but that we need to take a holistic approach to DNS abuse. So, whatever the community does to resolve DNS abuse issues that it is included in existing and new registry agreements. -- SUGGESTION: Text in Rec xx (rationale 8) - …."that address DNS abuse in all TLDs" …. but the CCT-RT refers only to the newgTLDs, no? -> should the text be amended to …."that address DNS abuse in all new gTLDs" …. -- Note sure we need to say this, “and recommends that the community continues to take steps to address CCT-RT recommendations 14, 15, and 16 through community-wide discussions” since this work will keep going. -- Is it all gTLDs or does it only apply to new gLTDs. -- Question: Are 14/15/16 in the current implementation? -- Question: Is this really a recommendation? Is there another way we want to communicate this other than as a recommendation. -- For 14 and 15, the Board resolution action was: Place this recommendation in “Pending” status. The Board directs ICANN org to facilitate community efforts to develop a definition of “abuse” to inform further action on this recommendation. To negotiate “anti-abuse measures”, a common understanding of what “abuse” means must first be reached. For 16: part of the recommendation was passed through the relevant groups. Here is the scorecard: https://www.icann.org/en/system/files/files/resolutions-final-cct-recs-score... -- Need to consider the status of the pending CCT-RT recommendations as to whether this should be a WG recommendation. -- Need to make sure we track to the Board resolution. -- Need to take DNS abuse and the Board resolution very seriously, particularly the GAC Montreal advice. -- We are saying that our PDP is not the right vehicle to solve that issue. -- Question: What happens if SubPro PDP WG doesn’t address this issue? How will it be resolved? Answer: We are agreeing that the Board said that the PDP should address this issue but we are saying that it is not for this PDP to solve it. -- What was forwarded to the WG -- CCT-RT recommendations were directed at a number of groups including this one, and just a portion. That is in the context of 14 and 15 being pending. Need to provide that context. ACTION ITEM: Add a comment/question as to whether “all TLDs” refers to all gTLDs or only to new gTLDs. ACTION ITEM: Staff will check to see if the Board referred 14/15/16 to the GNSO Council and thus to SubPro. ACTION ITEM: Need to include the status of the pending CCT-RT recommendations as to whether this should be a WG recommendation. Check to see if there is another way to reword this instead of as a recommendation. The Working Group is further considering additional recommendations and Implementation Guidance in line with CCT-RT recommendations: Potential Recommendation: Applicants must provide a rationale for any RVCs proposed. Potential Recommendation: In support of the principle of transparency, RVCs must be readily accessible and presented in a manner that is usable, as further described in the Implementation Guidance below. Potential Implementation Guidance: The Working Group notes the CCT-RT’s recommendation 25 has recommended developing an “organized, searchable online database” for RVCs. ICANN org should evaluate this recommendation in the implementation phase and determine the best method for ensuring that RVCs are widely accessible. Discussion: -- No objections to rationale applying to all RVCs (first bullet). -- No objections to RVCs being readily accessible (second bullet). -- Question: What is the intent of requiring the rationale? Answer: This came out of RVCs that responded to public comment or objections, so that public commenters could understand why this commitment is being made. c. New issues raised in deliberations since publication of the Initial Report, if applicable. The Working Group is discussing whether to affirm the framework adopted for Category 1 strings in the 2012 round and/or provide guidance on rules for sensitive strings in future rounds. The Working Group considered that it could potentially develop a framework and/or set of criteria for determining what is sensitive or in a "highly-regulated" sector. For example, an applicant could be asked to self-identify that they are applying for a string that is sensitive or in a "highly-regulated" sector. An expert panel could then review that self-designation, as was the case with geographic names in the 2012 round. Discussion: -- Staff comment: Reminder of questions from ICANN org: If mandatory PICs are to be codified as policy recommendations, it would be helpful if the PDP Working Group could provide guidance on (i) What the categories of strings are; (ii) The process and criteria for applied-for strings to be put into those categories, including who makes the decision, implications on the evaluation and string contention processes; (iii) What the contractual obligations are for each of the categories. -- Question: Seek clarification on what is the status of the document we are discussing?