Dear Working Group members, Please see below the notes from the meeting on 13 February 3:00 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-13+New+gTLD+Subsequent+Pro... Kind regards, Emily Notes and Action Items: 1. Review Agenda/Statements of Interest 2. Working Group working methods 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... * 2.3.4 Universal Acceptance (page 6) * 2.11.1 Registry System Testing (page 7) 4. AOB 1. Review Agenda/Statements of Interest - No SOI updates 2. Working Group working methods - Discussion – we have begun reviewing sections of draft recommendations. What are the next steps? - Work Plan was discussed in the last meeting: https://docs.google.com/spreadsheets/d/1SN8GX1nVER30p_VmX1fAEJUTRLByXhrI96kp... - Leadership team will start a new document containing revisions for the topics that have been covered on calls so far. - These will be released in logical batches with material that is related to each other, for example by report segment. - The leadership team would like to adopt procedures that have worked well for the EPDP. - There will be a template for WG members to comment on revised text. Any future revisions to topics should be of necessity, something that you would “die in a ditch” for. The template will ask you to quote the language of concern in the report and propose and edit. These comments will be circulated on the mailing list. - Leadership team will put out a note that explains the process in writing. - Question – member brought up concerns about specific meeting dates. What is the status of these? They still appear in the work plan that was sent to Council with the Project Change Request. - Answer – leadership is still discussing. The Council’s main concern is about the end date for the project and not all of the specific meeting dates. There may still be adjustments to meetings themselves, including scheduling extended sessions. - Leadership team met today with Council leadership team to prepare for the presentation of the Project Change Request to Council during the GNSO Council February meeting. - Council leadership asked how Council can support the WG. WG leadership said that Councilors can go back to their respective groups and remind those participating in the WG to be collaborative and work hard towards compromise where this is necessary. ACTION ITEM: Staff to send Project Change Request to the WG mailing list. 3a. Review draft final recommendations – 2.3.4 Universal Acceptance - Review of text of the two affirmations. ACTION ITEM: Add a footnote to the first affirmation with links to information about the Universal Acceptance Initiative and the Universal Acceptance Steering Group. - Question regarding first affirmation, does affirming their work in effect make policy? - Answer – that is not the intent. Members can suggest adjustments to the text to make that clear if they would like to do so. - Review of recommendation with revision of Principle B. ACTION ITEM: Consider restructuring recommendation text. Sentence is currently very long. - Review of Implementation Guidance. ACTION ITEM: Change “may want to” to “should” in Implementation Guidance. In the corresponding rationale, change “The Working Group encourages ICANN to. . .” to “The Working Group believes that ICANN should. . .” 3b. Review draft final recommendations – 2.11.1 Registry System Testing - The leadership team further discussed the possibility of re-naming the RSP Pre-Approval Program and is proposing RSP Pre-Evaluation Process (PREP). Some support expressed on the call. ACTION ITEM: Replace RSP Pre-Approval Program with RSP Pre-Evaluation Process (PREP) throughout the report. - Review of recommendation 8 from 2007 and affirmation with modification of recommendation 7. - Note from the leadership team that we are making a distinction between registry evaluations and registry testing. Registry evaluation includes answers to questions – it relates to capabilities that cannot be demonstrated until the registry is up and running. Testing is what ICANN does to test certain capabilities of a registry. - As an example, when we talk about a registry being able to scale, you can’t test scaling capabilities, but you can evaluate the ability to scale by looking at responses to questions. - Both testing and evaluation could be part of both the pre-evaluation and regular process. Part of what was in PDT will be in the testing that is applied during the pre-evaluation and regular application process. The recommendations also call for additional testing based on feedback from the SSAC and the Work Track. - In 2012 there was a theoretical exam and then testing to confirm ability to manage the registry from a technical perspective. The evaluation component is like the exam and the testing component is the actual demonstration of abilities. Both parts will be part of pre-evaluation and regular evaluation process. - Question – Why do we have a recommendation to develop registry system tests designed to minimize SLA violations. Shouldn’t the tests be about the technical capability of the RSP? - Language came from SSAC recommendation and/or discussion. WG looked at SLA statistics. Recommendation could be edited to include elements of both. - Comment – it may be difficult to minimize violations of SLAs in practice. Suggestion to instead that they should “take into account service level requirements.” ACTION ITEM: Edit recommendation xx (rationale 2) to state: “ICANN must develop a set of Registry System tests designed to demonstrate the technical capabilities of the Registry Operator [in order to reduce the likelihood for registry violations of SLAs / taking into account service level requirements].” WG members to provide input on the two bracketed options. - Review of IG in connection with rationale 2. No additional comments. - Review of recommendation in connection with rationale 3. - Question – is this more appropriate as Implementation Guidance? - Leadership team suggested this as a recommendation because it is overarching, with more specific guidance included under it. - Suggestion to remove “as possible” language. Support from the group for this suggestion. ACTION ITEM: Edit recommendation xx (rationale 3) to read: “Registry System Testing must be efficient.” - Question from ICANN org on the first piece of IG connected to rationale 3 – in the sentence “To the extent an applicant is proposing tables that are not pre-vetted by the community, the tables should be reviewed prior to RST and should utilize IDN tools available at the time of review.” ICANN org’s interpretation is that this should be done as part of the evaluation and not that this is something the applicant should do with these tools. Suggestion to edit text to make that clear. ACTION ITEM: Change sentence to read: “To the extent an applicant is proposing tables that are not pre-vetted by the community, the tables should be reviewed during the evaluation process and the evaluator should utilize IDN tools available at the time of review.” - Review of second piece of IG related to rationale 3 – suggestion to change “to the extent possible” to “to the extent practical.” - Review of recommendation in connection with rationale 4 – feedback that this recommendation without context is challenging. There is an assumption that the current modeling isn’t robust, but how do you make it more robust? - The EBERO threshold incidents should be referenced as background for the recommendation. - Question – does ICANN publish service level statistics in their reports? - Additional question – depending on the response to the above question, does the WG want to affirm the publication of these statistics if ICANN is doing it already or put as a recommendation that ICANN publish this information going forward if it is not already? - Suggestion that ICANN should make readily available information about the results of the monitoring that is taking place. ACTION ITEM: Add under Recommendation xx (rationale 4) a new recommendation or IG that ICANN regularly publish aggregate, anonymized data on all SLA violations that result from monitoring conducted by ICANN org. - It could also potentially be beneficial to publish responses given in relation to these SLAs to provide context for the statistics, for example if there was an error in the monitoring process. This would also need to be anonymized. This could potentially be added as IG. 4. AOB - none