Dear EPDP Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be Thursday, 2 April at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items Brian K., with the help of volunteers (Laureen, Alan G., Marc A.), to propose draft terms of reference for the proposed mechanism (what will it do) and modus operandi (how it will be done) by Tuesday, 7 April. EPDP Team to review the discussion table for Recommendation #9 – SLAs and provide comments prior to the next meeting on Thursday, 2 April. EPDP Phase 2 - Meeting #50 Proposed Agenda Tuesday, 31 March 2020 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) Public comment forum on addendum open: Deadline for input 5 May 2020 Blog post announcing public comment forum and communicating additional opportunity to submit comments on Initial Report published Note that for those still planning on submitting comments on the Initial Report, notification needs to be provided to gnso-secs@icann.org by 31 March. NCSG, RySG and ISPCP already confirmed late submission, but have indicated that they would aim to submit as soon as possible. Format of public comment forum follows the same format as that for the Initial Report. As most topics are (hopefully) non-controversial, it is the expectation that the EPDP Team will be able to review the input in time for including it in the Final Report. In principle, between now and publication of Final Report only 10 meetings remain. This will require a real commitment from everyone. Representatives of groups should know by now the positions of their respective groups and be able to take decisive action when reviewing comments, which shouldn’t require going back on an ongoing basis when compromises are reached. 4. Public comment review by EPDP Team PCRTs and Discussion Tables wiki page - https://community.icann.org/x/Hi6JBw Walk through of discussion table example Feedback from EPDP Team Confirm next steps See wiki page – note that the first entry contains the raw data. For each of the recommendation a public comment review tool (PCRT) and discussion table will be provided to facilitate public comment review.  The discussion tables will link to google docs which are to be used by groups to provide their input in advance of the different meetings. In order to make this approach productive, groups MUST provide their input by the deadlines that will be established shortly. As an example, walk through of the discussion table for recommendation #9 which will be on the agenda for Thursday’s meeting. Identical and/or similar comments have been grouped together. In addition, these have been organized in line with the different sections of the recommendations so it will hopefully become easier for the team to review and determine which changes, if any, should be made to the recommendation. In addition, a label has been attached to the grouped comments such as ‘concern’, ‘clarification’ and ‘proposed edit’. Each group is asked to review the discussion table and fill out the corresponding tables to indicate whether there is agreement with issues flagged as well as proposed changes to address concerns. Note that the only comments that are not included is ‘support’ (without any text) and ‘no opinion’. However, not all comments are copy/pasted – if they are similar, there is no need as the same sentiment is conveyed. The discussion table is not intended to be a quantitative review – it does indicate the # of similar comments that have been submitted, but it is up to the EPDP Team to decide whether additional weight should be given to that. Unless new information is provided by late comments, it will be difficult to go back to comments / issues already addressed. Groups that have not submitted yet should speak up as part of the review to indicate their perspectives. Staff will also aim to flag if issues are raised that have not been considered yet or where new information is provided. Comments that are received late shouldn’t been given less weight, but it would be helpful to have a firm date by when these should be in. Staff will do its best to get comments added as soon as received.  Aggregate data may be another way to address confidentiality. 5. Mechanism for the evolution of SSAD (45 minutes) Consider EPDP Team Input on Brainstorming Proposal Feedback from EPDP Team Confirm next steps SSAD is a conceptual, new environment resulting from restrictions imposed externally. EPDP Team anticipates that this will work in a certain way, but this is based on certain assumptions which may be right, wrong or evolve over time. Recommendations should capture idea of evolution and improvements that do not require changes to the policy. For example, response time – maybe response time is impossible due to number of requests received. How can that be addressed if there is no mechanism but a PDP or contractual negotiations? Evolution is a part of the compromise – not changing the underlying policy but course correcting implementation based on experience and legal guidance that will become available over time. Staff Support Team discussion team outlined 4 different options, based on input received during the public comment period (Standing Committee, (standing) IRT, GGP, contractual negotiations). BC/IPC both support standing IRT, RrSG supports contractual negotiations or PDP, Org Liaisons indicated that GGP is a possible approach. ALAC also supports (standing) IRT, assuming that there is a joint-controllership agreement which would require CPs to agree to additional automation use cases. Mechanism would only focus on implementation related issues – policy recommendations would need to be formulated in such a way to allow for a review of the implementation through an agreed upon mechanism, without a full-blown PDP. NCSG may have a preference for Standing Committee – as long as recommendations go to the GNSO Council. Contractual negotiations would exclude other parties to provide input / participate. GGP was specifically designed to provide implementation guidance. Standing IRT may be difficult as the ground may shift over time. Need to first clearly define what would be in scope for this mechanism. Only way to create binding requirements on Contracted Parties is through policy development or contractual negotiations. Need to be clear on what we need the tools for. Need some kind of implementation review. A guidance process would be a good tool to inform the contractual negotiation process between ICANN and CPs in the form of a contractual negotiations. Different topics may need a different route. May need a tool box that can be used to affect changes. Possible scope of mechanism: Does not create or change policy Evolve aspects of SSAD – SLAs and automation. Consider for each of those what is the best mechanism to evolve, it may be different. GGP may require little work as the mechanism already exists and is intended to provide guidance. No remit for EPDP Team to change existing GNSO processes. Who participates in a GGP – charter developed and approved by GNSO Council, no restriction on what membership could look like. Highly unlikely that GNSO Council would exclude groups that are participating in this EPDP or others that are directly impacted. Action item: Brian K. to put together terms of reference (what will it do) and modus operandi (how it will be done). (other volunteers: Laureen, Alan G., Marc A.) 6. Reporting (Implementation guidance ii) (30 minutes) Consider EPDP Team Input on discussion table Feedback from EPDP Team Confirm next steps Should only define reports that are to be publicly posted on the SSAD system Frequency – may need a bit further thought, although quarterly may be reasonable. Should metrics be produced over SSAD system as a whole or per registry / registrar basis? Public reports should be on overall SSAD system, not per registry/registrar basis as there are some concerns around that. Could also consider operational reporting – data available to assess how SSAD works operationally which would be used by those following the implementation of SSAD. Should consider all reporting – both public and non-public reports. This may be an evolutionary thing – provide first level of things that are needed. System will be collecting statistics all the time so a type of dashboard may be the solution here instead of manually generated reports? Users of SSAD should be able to see their own statistics. Should this be left to the operator of the system as an implementation issue? EPDP Team recommendation should focus its policy recommendation on public reporting. Should not forego individual reports being made available by the implementor but should define the minimum of public reporting to take place. Also consider information per requestor basis. Any compliance should be handled between ICANN Org and Contracted Parties – public reporting does not equate to a compliance report. Also need to consider privacy of requestors, if not legal persons – need to be careful what information is publicly posted. Consider need to know vs. good to know. Consider listing down principles and by what lens they may be used (public, access by CP or Requestor for their own use, Compliance, Audit) and less about creating a list of what should be reported on. LEA requests would likely need to be confidential. Reporting will flow from logging so need to have consistency between the two recommendations. What are objectives of reporting – need to be clear on that. Need to consider impact of data that is reported / published. More data that will be collected than will be publicly shared. 7. Wrap and confirm next EPDP Team meeting (5 minutes): Thursday 2 April at 14.00 UTC. Topic to be addressed: SLAs. Confirm action items Confirm questions for ICANN Org, if any Action item: EPDP Team to review the discussion table for recommendation #9 and provide comments prior to Thursday’s meeting.