Dear Working Group members, Please see below the notes from the meeting on 27 February 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-02-27+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Affirmation xx (with modification) (rationale 3): ACTION ITEM: Replace “use a pre-evaluated RSP” to "use an RSP who has successfully completed the Pre-Evaluation Program. (Pre-evaluated RSP)". Implementation Guidance xx (rationale 5): ACTION ITEM: Consider integrating the Module 2 elements from Q30b. Implementation Guidance xx (rationale 6): ACTION ITEM: Re: “may only need to be performed once as opposed to being evaluated for each individual application” -- Explanatory text or clarifying text might be needed here. Implementation Guidance xx (rationale 10): Re: “iii. If the applicant is an Affiliate (as defined in the current Registry Agreement) of a current Registry Operator that is not in default on any of its financial obligations under its applicable Registry Agreements, and has not previously triggered the utilization of its Continued Operations Instrument.” ACTION ITEM: Add the Registry Operator (RO) itself: It intended all options: RO, Affiliate of an RO, parent company etc. Rationale for Recommendation xx-xx (rationale 2): ACTION ITEM: Revise the last sentence to, “Accordingly, there is support for a thorough examination [during the implementation of these policy recommendations] of why there were so many CQs in 2012 and how they can be significantly reduced in future rounds[, prior to the finalization of the Applicant Guidebook].” (new text in brackets) Notes: 1. Review Agenda/Statements of Interest: 2. Working Method: From Jeff’s email at http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002553.html: * We are currently using the following Working Document to support initial review and discussion of draft recommendations: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit#<https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit>. This will continue to be the document where you will find newly drafted recommendations that have not yet been discussed on a call. You are encouraged before each call to review the sections on the upcoming agenda and insert comments into the document and/or raise questions/concerns on the mailing list. Staff will continue to note preliminary suggested edits in the Working Document during the call as items are discussed. * Once a section has been discussed on a call (or multiple calls), the leadership team will work on revisions in redline in the Working Document. * 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, for example all sections related to Pre-Launch Activities. The leadership team will send an email to the group with date by which any comments on those sections should be provided. 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: -- This is what the EPDP used. -- Question: Is this just to get us to agree on the document to go out for public comment, right? Answer: Yes. You also can file comments in the public comment period. -- After we get the public comment in we may use this method to produce the Final Report. -- Re: the Work Plan -- We have added meetings the week before and after ICANN67 so we’ve revised the Work Plan to with the possibility of publishing the report sooner. 3. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52...: 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services (page 43) -- First section is the general notion of applicant reviews. -- First affirmation is affirming several principles from 2007. Overall Evaluation: Recommendation xx (rationale 1): Evaluation scores on all questions should be limited to a pass/fail scale (0-1 points only). Discussion: -- Comment from Jim Prendergast: “as I recall there were some questions worth more than 1 point in the 2012 round because of their importance. As an example, are we suggesting that description of purpose is on par with efforts to address DNS abuse if we limit point values to 1?” -- This evaluation is performed for everyone RSP if they don’t participate in the pre-evaluation or if they didn’t pass. -- ICANN’s PIRR recommended eliminating the 2-point questions. Technical and Operational Evaluation Affirmation xx (with modification) (rationale 3): The Working Group affirms recommendation 7 from the 2007 policy with the following proposed additional text in italics: “Applicants must be able to demonstrate their technical and operational capability to run a registry operation for the purpose that the applicant sets out, either by submitting it to evaluation at application time or agreeing to use a pre-evaluated RSP. Discussion: -- Comment from Jim Prendergast: “suggest alternative language. "use an RSP who has successfully completed the Pre-Evaluation Program. (Pre-evaluated RSP)" Then link back to the section of the recommendations for reference.” ACTION ITEM: Replace “use a pre-evaluated RSP” to "use an RSP who has successfully completed the Pre-Evaluation Program. (Pre-evaluated RSP)". Implementation Guidance xx (rationale 5): A mechanism(s) should be established to meet the spirit of the goals embodied within Q30b - Security Policy without requiring applicants to provide their full security policy. Discussion: -- Comment from Jim Prendergast: “We need to ensure that the AGB clearly defines what the "spirit of the goals embodied within Q30b" actually are. Otherwise that it may be open to interpretation by applicants new and old.” ACTION ITEM: Consider integrating the Module 2 elements from Q30b. Implementation Guidance xx (rationale 6): ICANN org or its designee should aggregate and/or consolidate the technical and operational evaluation across applications to the extent feasible where the applications, for all intents and purposes, share identical responses to the relevant questions, particularly as it relates to the proposed registry services. This is intended to apply even when an applicant indicates that it will not use a pre-evaluated RSP. For example, if an applicant submits multiple applications or multiple applications are submitted from different applicants that share a common technical infrastructure, the technical and operational evaluation may only need to be performed once as opposed to being evaluated for each individual application. Discussion: -- Is this consistent with recommendations on how applications get prioritized? -- What this is saying is the first time you evaluate an RSP whether during pre-evaluation or after, the results of the first evaluation will carry over to every time that RSP is used in an application. -- Don’t think there is an impact of the RSP technical evaluation in the queuing of applications. -- Priority is process-wide, so when it comes to technical evaluation, it ends up being publish priority, in order to gain from cost-savings at evaluation. -- There may be circumstances when the same technical infrastructure may be evaluated again, which is only where this applies. -- Only evaluate the new elements of the application. ACTION ITEM: Re: “may only need to be performed once as opposed to being evaluated for each individual application” -- Explanatory text or clarifying text might be needed here. Financial Evaluation: Implementation Guidance xx (rationale 10): Re: “iii. If the applicant is an Affiliate (as defined in the current Registry Agreement) of a current Registry Operator that is not in default on any of its financial obligations under its applicable Registry Agreements, and has not previously triggered the utilization of its Continued Operations Instrument.” ACTION ITEM: Add the Registry Operator (RO) itself: It intended all options: RO, Affiliate of an RO, parent company etc. Rationale for Recommendation xx-xx (rationale 2): The Working Group believes that in service of transparency, the Clarifying Questions (CQs) and responses to those CQs should be published for all publicly posted application questions. However, the Working Group recognizes that CQs and their responses for publicly posted application questions may inadvertently share private information. Respecting the privacy and confidentiality of responses is important. The Working Group believes that the number of CQs in the 2012 round were excessive, indicating a lack of clarity in the way that the application questions were phrased and/or presented. Accordingly, there is support for a thorough examination of why there were so many CQs in 2012 and how they can be significantly reduced in future rounds. Discussion: -- Comment from Jim Prendergast: “Is there a deadline for when this must be done?” ACTION ITEM: Revise the last sentence to, “Accordingly, there is support for a thorough examination [during the implementation of these policy recommendations] of why there were so many CQs in 2012 and how they can be significantly reduced in future rounds[, prior to the finalization of the Applicant Guidebook].” (new text in brackets)