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

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

Post call / New gTLD Subsequent Procedures Working Group call on Monday, 16 March 2020 at 15:00 UTC
by Michelle DeSmyter March 16, 2020

March 16, 2020

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

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Monday, 16 March 1500 UTC
by Julie Hedlund March 12, 2020

March 12, 2020

Dear all, Please find below the proposed agenda for the call on Monday, 16 March 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 the documents at: https://docs.google.com/document/d/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7O… and attached as a PDF. * 2.9.1 Community Applications * Topics Previously Discussed: 2.7.3 Closed Generics (discussed on 09 March); Public Interest Commitments (aka Registry Commitments) (in 2.3.2. Global Public Interest) (discussed on 10 March); 2.8.1 Role of GAC Early Warnings/Advice (discussed on 12 March); 2.5.4 Applicant Support (discussed on 12 March) 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

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

March 12, 2020

Dear Working Group members, Please see below the notes from WG Session #3 of 3 on 12 March at 1545 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-12+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.8.1 Role of GAC Early Warnings/Advice Recommendation xx (rationale 1): ACTION ITEM: Consider omitting the bracketed text and only referencing section 12.2.a of the Bylaws. Recommendation xx (rationale 2): ACTION ITEM: Rewrite the language to focus more on the operational problem vis-a-vis the timing of GAC advice, the need for predictability, and the desire to enable applications to be judged on their merits and not just as part of a class of applications. Consider also rationale 1 and 3. Recommendation xx (rationale 3): ACTION ITEM: Reference the applicable sections of the Bylaws and rewrite in consideration with recommendations-rationale 1, 2, and 3. Recommendation xx (rationale 4): ACTION ITEM: Separate the recommendation into two sentences. ACTION ITEM: Consider deleting the text, “and specific action requested of the applicant.” ACTION ITEM: Re: “include both a written rationale/basis” with more collaborative language, such as “reason” or “explanation”. Recommendation xx (rationale 5): ACTION ITEM: Accept and include the text in brackets “and GAC Advice”. ACTION ITEM: Rewrite to clarify the opportunity for dialog and recognizing that some governments may not have the ability to engage in that dialog. Recommendation xx (rationale 6): ACTION ITEM: Consider whether the language can be rewritten to allow a balance with the GAC Early Warning and/or GAC Advice. 2.5.4 Applicant Support Affirmation xx with modification (rationales 1 and 2): ACTION ITEM: Consider rewriting as a recommendation. ACTION ITEM: For affirmation 1 and 2, make it clear what is the original affirmation and what is new language. Recommendation xx (rationale 4) and Implementation Guidance: ACTION ITEMS: Review and rewrite the Implementation Guidance per the comments. Consider deleting the term “middle applicant”. ACTION ITEM: Reference the definitional work being done by ICANN. 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.8.1 Role of GAC Early Warnings/Advice Recommendation xx (rationale 1): GAC Advice must include clearly articulated rationale, including the national or international law [and merits-based public policy reasons] [or merits-based public policy reasons] [and/or merits-based public policy reasons] upon which it is based. Discussion: -- Question Re: the bracketed text -- do we have to choose one of these options? Or can we decide on something else? Answer: No we don’t have to include any one of these. -- Don’t think we should accept any of the options. -- This recommendation should only refer to the Bylaws. -- The bracketed text was suggested in the public comments. -- Bylaws: Section 12.3. PROCEDURES of the ICANN Bylaws, which states that “. . .each Advisory Committee shall ensure that the advice provided to the Board by such Advisory Committee is communicated in a clear and unambiguous written statement, including the rationale for such advice.” -- Including the bracketed text would limit the scope of GAC advice as opposed to what is provided in the Bylaws. -- From section 12.2.a defining GAC role: "(i) The Governmental Advisory Committee should consider and provide advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues." -- Come back to this issue. -- FYI: Someone reminded me that in the .amazon IRP, it states: "The Panel recommends that the Board of ICANN promptly re-evaluate Amazon’s applications in light of the Panel’s declarations above. In its re-evaluation of the applications, the Board should make an objective and independent judgment regarding whether there are, in fact, well-founded, merits-based public policy reasons for denying Amazon’s applications. " I believe this is where the language from Rec 1 came from. By posting this I am not taking a position one way or the other. Just publishing the source for that rec. ACTION ITEM: Consider omitting the bracketed text and only referencing section 12.2.a of the Bylaws. Recommendation xx (rationale 2): To provide predictability to applicants as well as the Internet community, future GAC Advice for categories of gTLDs (if any), and Board action thereupon, must be issued prior to the finalization of the next Applicant Guidebook. Any GAC Advice issued after the application period has begun must apply to individual strings only, based on the merits and details of the applications for that string, not on groups or classes of applications. Discussion: -- GAC understands the need to provide more predictability, there are situations that are not foreseeable. The unpredictability of such situations will be much lower, but we cannot exclude that possibility. There will be classes of applications that will require similar treatment and that can’t be known until after the applications are submitted. We have to balance predictability and that there are policies that require homogeneous treatment where GAC can provide a role. Request more flexibility in this text. It is putting GAC advice in a straight jacket. -- <COMMENT> It is really odd to codify somewhere in a procedure that an AC cannot advise on something in certain circumstances; it is not compatible (again) with the bylaws.<COMMENT> -- We are trying to balance the timing of the GAC advice and predictability for applicants. In 2012 there was advice that came after the fact. Unfortunately the GAC advice tends to put applicants into a straight jacket, after they have submitted an application assuming that their application meets the necessary requirements. -- These recommendations are attempts to solve problems, but in a sense we are talking around the problems. The issue is the problem we are trying to solve: GAC advice just on the basis of timing isn’t fit for purpose -- that is, fitting into the application process. If we are looking for a way for the GAC to participate meaningfully, that is where we need to go. -- The problem is not so much GAC advice, it is that we cannot foresee everything. There are things that appear after the fact; only after we’ve seen all of the applications that have been presented, and some of the advice may pertain to a class of applications. -- We should be more sophisticated in how we approach this, and see the policy problem as the problem -- balancing the need for predictability and the need to allow flexibility to address GAC advice relating to a class of applications. <COMMENT> agree that timeliness is important: maybe the recommendation can be phrased differently; GAC is urged to provide advice, if any, on .... before... <COMMENT> -- A timeline would be helpful for GAC advice but also for the Board response. -- I have no issue with advice as to categories of TLDs. The more that the GAC can contribute during the AGB phase, the better off we will be when the applications are being reviewed. But I don’t think the GAC can be limited to Advice prior to the applications being revealed. -- It would make sense for the GAC to consider each application individually. Even where things come up after the fact, look at the merits of each application. -- A couple of the reasons we were making this recommendation: 1) some applicants who had particular conditions already in their application got held up in a category; 2) there is a danger if global advice is given about a category, unless those strings are set out exhaustively there is a danger that something gets missed. In identifying the category the individual strings should be identified and evaluated on their own merit. -- The problem with the category advice is that it was treated as “one-size-fits-all” advice. This should be resolvable. -- The biggest problem we are trying to address is the issue of delay if an applicant is held too long. The timing of receiving the advice is the issue, but it will depend on the number of applications. -- Part of the problem with the GAC advice was the Board's inability to respond to the GAC advice in a timely manner and that should be addressed as well.  -- So where the application refers to "compliance" with existing GAC Advice, ICANN Org will verify with GAC that that is the case, if not then that is open to GAC Advice for a specified time period and Board reaction also within a specified time period. ACTION ITEM: Rewrite the language to focus more on the operational problem vis-a-vis the timing of GAC advice, the need for predictability, and the desire to enable applications to be judged on their merits and not just as part of a class of applications. Consider also rationale 1 and 3. Recommendation xx (rationale 3): Consistent with the updated ICANN Bylaws, omit in future editions of the Applicant Guidebook language included in the 2012 AGB section 3.1 that GAC Advice “will create a strong presumption for the ICANN Board that the application should not be approved.” The Working Group believes that this language is not only unnecessary in light of the Bylaws, but has the unintended consequence of hampering the ability for applicants, ICANN org, and the GAC to mitigate concerns, which could allow an application to proceed. Discussion: -- GAC advice should not be constrained by the AGB nor should it be expanded beyond what is allowed in the Bylaws. -- Redraft the recommendations-rationale 1, 2, and 3. -- Applicants do need some kind of heads up on what the Bylaws actually say. Need to understand the GAC advice process. May need to include a reference. -- Can just connect this to what the Bylaws say. ACTION ITEM: Reference the applicable sections of the Bylaws and rewrite in consideration with recommendations-rationale 1, 2, and 3. Recommendation xx (rationale 4): To the extent that there is a decision to allow a longer period for the GAC to provide Early Warnings (above and beyond the public comment period), the application process should define a specific time period during which GAC Early Warnings can be issued and require that the government(s) issuing such Warning(s) include both a written rationale/basis and specific action requested of the applicant. Discussion: -- Think that the recommendation is saying two things but it is a bit mixed. The first phrase is about the extended time period for GAC early warnings and on the 4th line up to “require” should be a separate sentence because we don’t want to limit that to a specific time period, but something we want in general. That there is a rationale and specific action requested on the applicant. Separate into two sentences. -- Re: “application process should define” should say, “the Applicant Guidebook should define”. Not meant to imply that there was a separate process. -- This is trying to say that when a GAC member submits an Early Warning they should make themselves available to an applicant to work things out. -- Re: “and specific action requested of the applicant.” -- this could be problematic as the government might simply request that the applicant should withdraw the application. Suggest deleting that text. -- Why require “rationale” from the GAC? Maybe replace with “reason” or “explanation” or some other term. ACTION ITEM: Separate the recommendation into two sentences. ACTION ITEM: Consider deleting the text, “and specific action requested of the applicant.” ACTION ITEM: Re: “include both a written rationale/basis” with more collaborative language, such as “reason” or “explanation”. Recommendation xx (rationale 5): The applicant must have an opportunity to engage in direct dialogue in response to GAC Early Warnings [and GAC Advice] and amend the application during a specified time period. -- Good idea for GAC early warnings and GAC advice. -- The reason why GAC Advice is in brackets is because the original language didn’t include it. The feedback is supportive of including “and GAC Advice”. -- Concerned about the use of the word “dialog” as well as the implication that the applicant has some sort of right. That some governments may not have the ability to engage in that dialog. ACTION ITEM: Accept and include the text in brackets “and GAC Advice”. ACTION ITEM: Rewrite to clarify the opportunity for dialog and recognizing that some governments may not have the ability to engage in that dialog. Recommendation xx (rationale 6): Applicants must be allowed to change the application, including the addition or modification of Registry Voluntary Commitments (RVCs, formerly Voluntary PICs), in response to GAC Early Warnings and/or GAC Advice. Discussion: -- Suggestion changing “in response to GAC Early Warnings and/or GAC Advice” to “which address GAC Early Warnings and/or GAC Advice.” Combine with rationale 5. -- Wondering whether there are any qualifiers about same strings or contention sets and the applicability of GAC Advice. There were circumstances in 2012 where some strings in a contention set were problematic and others weren’t re: GAC Advice. -- To restate: it should not be codified in this recommendation. I was not suggestion that all governments should not have the opportunity, but under no circumstances should the process be held up waiting for 'all' governments to comment. -- Figure out if there is a different way to state the recommendation. ACTION ITEM: Consider whether the language can be rewritten to allow a balance with the GAC Early Warning and/or GAC Advice. b. 2.5.4 Applicant Support Affirmation xx with modification (rationale 2): Discussion: -- Starts as an affirmation but then the language used suggests a recommendation. -- Affirming the modification of the language from 2012. But we can state it as a recommendation if that is less confusing. -- Define the term “non-financial assistance”. For affirmation 1 and 2, make it clear what is the original affirmation and what is new language. ACTION ITEM: Consider rewriting as a recommendation. ACTION ITEM: For affirmation 1 and 2, make it clear what is the original affirmation and what is new language. Recommendation xx (rationale 3): The Working Group recommends expanding the scope of financial support provided to Applicant Support Program beneficiaries beyond the application fee to also cover costs such as application writing fees, attorney fees related to the application process, and ongoing ICANN registry-level fees. Discussion: -- How are we addressing that a registry is able to financially and stably operate their TLD? -- They also may have non-financial assistance such as a back-end operator may agree to run the TLD for them. Recognition that there could be a need for support for ongoing ICANN registry-level fees. Recommendation xx (rationale 4): The Working Group recommends that ICANN seek opportunities to improve outreach, education, application evaluation, and program evaluation elements of the Applicant Support Program, as proposed in the Implementation Guidance below. Also, see related Implementation Guidance. Discussion: -- Don’t need to say “recommends that ICANN seek opportunities to improve outreach” but just “ICANN improves outreach” -- render into active voice. -- Can we bracket the recommendation that registry fees be waived or financial support provided please? -- Replace “education” with “increase awareness”. -- It seems that the point of departure the group is taking is the Application Support program, rather than the report that lead to the implementation documents. There were some recommendations in the report that were not implemented in the last round, but the Board asked that they be considered in future. Do we think the IRT would be the group to look at that? Then we need to point back to the Joint-Applicant Support Report. -- What we are saying here is that the GNSO policy process using has just one implementation team, but we are saying we want two implementation teams, one of which is dedicated to the Applicant Support Program. Also consider regional efforts/documentation. -- Concern about creating a class of registries that will fail. -- GAC Underserved Regions will look at these recommendations and come back with comments. -- Drop “middle countries”. -- RySG comment: The RySG believes that ICANN's support should be limited to financial support for the application fee. Further involvement in the operational, technical and business aspects of a registry/registrar will only serve to unnecessarily involve ICANN in the operations of a registry/registrar and will serve as a de facto endorsement of certain registries/registrars and set a negative precedent for future entities that want to enter the registry/registrar business. ACTION ITEMS: Review and rewrite the Implementation Guidance per the comments. Consider deleting the term “middle applicant”. c. New issues raised in deliberations since publication of the Initial Report, if applicable. In considering public comments, the Working Group discussed prioritization of successful Applicant Support applications. Specifically, the Working Group considered whether there should be any changes to the 2012 approach of establishing priority between applications if there are more qualified applicants than funds available. The Working Group did not come to a conclusion on these points, and therefore did not recommend a departure from the 2012 implementation. Discussion: -- In terms of At Large discussions, there were thoughts about approaching this from a regional perspective -- maybe having a quota based on regions. -- Add something that provides equity among regions. -- Seems that it would be simpler if the ASP was run as a separate operation to the new gTLD program in some way. there needs to be separate before any potential application comes into the ASP. Hard to determine if we don’t know how much funding is available and how many applicants will seek support. -- That’s why we have the recommendation that ICANN should establish a pool. -- Need to reference the definitional work being done by ICANN. Referenced in d. but maybe include in the rationale. ACTION ITEM: Reference in rationale 4 the definitional work being done by ICANN.

1 0

REMINDER re: Schedule and Proposed Agenda for New gTLD Subsequent Procedures PDP WG Sessions at ICANN67
by Julie Hedlund March 12, 2020

March 12, 2020

Dear SubPro PDP WG members, As a reminder, per the ICANN67 Virtual Community Forum Schedule the sessions for the New gTLD Subsequent Procedures PDP WG are as follows and are on the schedule at: https://67.schedule.icann.org/meetings[67.schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__67.schedule.icann.org_…>. Please note the proposed agenda for the sessions below, which also is posted on the wiki pages at the links below. In addition, please note below the related GAC sessions that may be of interest. Please let us know if you have any questions. Kind regards, Julie Julie Hedlund, Policy Director ICANN67 Schedule – New gTLD Subsequent Procedures PDP WG Sessions See the ICANN67 GNSO Remote Participation Details Virtual Meetings<https://community.icann.org/display/gnsocouncilmeetings/ICANN67+GNSO+Remote…> and How to Participate in ICANN67 Virtual Sessions<https://www.icann.org/en/system/files/files/icann67-how-to-participate-virt…> The ICANN67 Virtual community Forum [67.schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__67.schedule.icann.org_…> scheduled session times are all reflected as Eastern Standard Time (MX) for Cancún, Quintana Roo, Mexico [UTC-5]. Important Reminder: On 8 March, Eastern Standard Time (EST) changes in the U.S. and Canada to Eastern Daylight saving Time (EDT), however, there is NO TIME CHANGE in Cancún, Mexico or to the posted Virtual Community Forum schedule on this date. For the EASTERN US this means that the meeting times will be ONE HOUR LATER than the times listed in the local Cancún time. Proposed Agenda – to be adjusted for each session as topics are addressed: 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… and attached as a PDF. * 2.7.3 Closed Generics * Public Interest Commitments (aka Registry Commitments) (in 2.3.2. Global Public Interest) * 2.8.1 Role of GAC Early Warnings/Advice * 2.5.4 Applicant Support * 2.9.1 Community Applications 3. AOB Session Times and Wiki Pages: Monday, 09 March: 17:15-18:45 UTC (12:15-13:45 (Cancún)/13:15-14:45 EDT) – Session 1 of 3 -- https://community.icann.org/display/NGSPP/2020-03-09+ICANN67+Cancun-+New+gT… Tuesday, 10 March: 17:00-18:30 UTC (12:00-13:30 (Cancún)/ 13:00-14:30 EDT )– Session 2 of 3 -- https://community.icann.org/display/NGSPP/2020-03-10+ICANN67+Cancun-+New+gT… Thursday, 12 March: 15:45-17:45 UTC (10:45-12:45 (Cancún)/ 11:45-13:45 EDT) – Session 3 of 3 -- https://community.icann.org/display/NGSPP/2020-03-12+ICANN67+Cancun-+New+gT… Related GAC Sessions of Interest (follow the schedule links for descriptions and times): Monday, 09 March: GAC Capacity Building Workshop: https://67.schedule.icann.org/meetings/1152537 GAC: Update on Current Issues (New gTLD Subsequent Procedures): https://67.schedule.icann.org/meetings/1152538 Tuesday, 10 March: GAC: Follow up Discussions on New gTLD Subsequent Procedures: https://67.schedule.icann.org/meetings/1152541 Wednesday, 11 March: GAC: New gTLD Subsequent Rounds Discussion: https://67.schedule.icann.org/meetings/1152546 GAC: Wrap up on New gTLD Subsequent Procedures Discussions: https://67.schedule.icann.org/meetings/1152547

1 5

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

March 10, 2020

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+Pr…. 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/1xXu7gPKiblS3Vh4MCuK6NWfeRmMolXf9VF5sO7O… 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-scor… -- 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?

1 0