Dear EPDP Team: Please find below the notes and action items from today’s meeting. The next plenary meeting of the EPDP Team will be Thursday, 11 June at 14:00 UTC. Best regards, Marika, Berry, and Caitlin Action Items 1. EDPP Team to review draft final recommendations<https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2> and provide "cannot live with items" and minor edits by COB Friday, 5 June. 2. GAC reps to send updated Rec. 2 to EPDP Team ASAP to allow time for review. 3. Staff Support Team to update Rec. 15 and draft an alternative proposal for Rec. 19 based on today's discussion. (Rec. 19 Small Group to discuss the alternative proposal during small team call on Monday, 8 June at 14:00 UTC.) 4. EPDP Team to review the discussion tables for the addendum topics<https://community.icann.org/pages/viewpage.action?pageId=126430750> and provide input by Friday, 5 June, with a focus on recommendations that could be included in the Team's Final Report. EPDP Phase 2 - Meeting #62 Proposed Agenda Tuesday 2 June 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) 1. Reminder – homework assignments are due Friday 5 June (see https://community.icann.org/x/K4LsBw for updated recommendations and https://community.icann.org/x/Hi6JBw for priority 2 discussion tables) * Proposed language for all recommendations has been posted * You will notice tables at the top of the recommendation for “cannot live with” and “minor edits” * Following the tables, there is a clean version of the recommendation, followed by a color-coded version, which tracks edits. Yellow highlighting = new edits as a result of public comments. Blue highlighting = grammatical edits/reorganization * In some of the recommendations, there is a table that tracks the edits to note when these changes were discussed. * GAC hopes to get updated Rec. 2 out today or tomorrow 1. Note response received from ICANN Org (see https://mm.icann.org/pipermail/gnso-epdp-team/2020-May/003368.html) 4. Recommendation #15 Financial Sustainability (20 min) 1. Review remaining discussion items<https://community.icann.org/download/attachments/126430750/Recommendation%20...> gleaned from input provided on Financial Sustainability<https://docs.google.com/document/d/1e2kdKDoLH04OqNfZLJMd1qbDM07an2tZFs9rJOPo...> discussion table * Staff already took a stab at updating the recommendation based on questions 1-5 – will make further updates based on what is discussed today * Should ICANN incur the development and set up costs? Support Staff’s understanding is that “based on CPs” was mainly related to resources that CPs are expected to dedicate to implement and design their own systems, rather than a payment CPs would make to ICANN for the SSAD. * This assumption is correct – this is about CP’s integration with the SSAD system * The differentiation was to make clear that CPs will not be charging requestors on a per-request basis in addition to what the SSAD is charging – CPs will be responsible for paying for their own natural costs. * Requiring CPs and registrants to pay for this is not beneficial for the community and is not sustainable * Question 7 * Already answered/similar question * Question 8 * Number of questions that asked for further clarity with respect to how fees are to be differentiated. Fees may align with volume, type of user, or other factors that would come into play. There are comments about giving preferential treatment to certain types of users. * At this time, we do not know how many users will use the system. We do not know how many requests will be put in the system. As a result, it is proposed that the fee structure will be one of five topics to be reviewed by the evolutionary mechanism. * Arguing against preferential treatment for academic research and similar nonprofit endeavors. This list could get larger and larger and will punch holes into the financial support structure of this system. Many have stated that the whole system is in the public interest, so do not punch holes in the fee structure – this will lead to arbitrary distinctions. * No changes should be made based on Q8 * One issue the Team has never discussed is the extent the fees should be commensurate with the effort involved. If, for example, we decide that academic research is something worthy of having. With the proper restrictions, the information could be released automatically and therefore would cost less. * Q10 – is this something the EPDP Team is willing to consider at this stage – as this would make accreditation potentially no longer necessary and would have a cost implication? * A statement under penalty of perjury is probably not enough since this statement may not mean much depending on the jurisdiction. While it may not require the same level of background screening as for registrars, we should not do away with accreditation entirely. * One benefit of the SSAD system is that we are providing a way to accredit an entity looking for nonpublic registration data is who they say they are. There is a lot of value in this. Changing this would undermine the work the team has done up until now. * This policy has a number of safeguards in it. The idea that you would take out the accreditation (a safeguard) with an assertion is absurd and do not support this change. * Regarding the benefits of accreditation, this doesn’t seem to reflect the operational decisions in the balancing test. * Q10 – in reference to conversation the group had a couple of meetings ago regarding ICANN’s paper, - is there anything that needs to be changed or added to the recommendation? * The Team should send a formal thank you to ICANN org for its work on this. * The accreditation part does not need to be well-funded since we have looked at not excluding the possibility of self-organized groups taking over the accreditation part. Anything beyond ICANN’s review of this would not need to be costed. * Q11 – suggestion that was made in the comments received – this is not a typical policy recommendation. Is there any concern in making clear that this is guidance that is expected to be considered in the implementation phase? * Object to this – these are clearly policy recommendations and are meant to bind the SSAD * There is probably no way the IRT escapes discussing this, but presumably they will discuss the finer points and details. The IRT, however, needs to understand the pillars of how this system is to be paid for. 1. Confirm next steps * Support Staff to update the recommendation based on this discussion 5. Recommendation #19 Evolution Mechanism (20 min) 1. Review input received on updated draft recommendation<https://docs.google.com/document/d/1-npFkABPc-u3To6uYe2v6MTFHlrEOUD5i6x8LrHA...> * This evolutionary mechanism is part of the compromise and is an essential part of the whole package. It should ensure that the functionality of the system is improved in clearly-defined areas. This text was developed by a small group – it should be seen in light of existing mechanisms. There are safeguards built in whereby if this mechanism is not efficient, it will be reviewed. * Main concern goes to the final decision being made by the GNSO Council * As Janis noted, this was raised in the discussion with the small team, and went through the existing processes that are currently in play and based on that, the group determined that the GGP may be the best or only fit for what the group is trying to achieve here. * The IPC referenced SPRIT, which is being looked at in the SubPro WG – but this is not something that has been agreed or finalized yet. As that mechanism is foreseen, it is a triage committee; it is not a group that will make decisions. It would work under the oversight of the GNSO Council. * At this point, we are being asked to take it on faith that the size and composition of the GGP group will be acceptable to non-GNSO groups. We may have no say over the composition of the group. This is an evolutionary process – the evolution will not change the policy, and yet the GGP requires a supermajority of the GNSO to approve it. That means a single stakeholder group + 1 other member could veto anything coming out of the GGP. * Need to have faith in the GNSO Council that it will act in the best interest of all. The membership of EPDP will be reflected in the GGP, so non-GNSO groups will be present in this mechanism. If there is consensus in the mechanism, there is a good chance the Council will accept this. * What we are concerned about – when you talk about modifications of the SSAD, is the line b/w policy and implementation is very thin. There are concerns that this group could bypass the policy process. Therefore, it’s entirely appropriate that these recommendations have to have supermajority support in the GGP itself. Otherwise, there is the risk of capture. Re: the role of the GNSO, this is the way ICANN is structured. * What consensus are we looking at? If ACs do not have a vote, the meaning of consensus is different. The EPDP is a break from previous operational practice. For the EPDP we tried to do something different, and that is what we’re trying to do here. Do not think we should lock ourselves into existing structures. We need to be agile. If the only solution is to spin up new EPDPs, this will be unwieldy. * There seems to be general frustration with the model. Innovation is laudable and expected in tech companies, but that is not the purpose or function of ICANN. Saying we need to try something different is concerning. Operationally, the SSAD should not be static or carved in stone, particularly if the ground shifts again from a regulatory perspective. Anything that creates new obligations for CPs or data subjects has to go through the GNSO. This is not up for negotiation within a PDP. * The group was not able to come up with any alternatives to the GGP proposal * We are not in a state of discomfort with the GGP, but as we have made clear – our support for the notion that we will not have centralization or a number of things we wanted to see in the policy – is that there would be a mechanism for evolution. The evolution needed to be chartered and explicit. That was how we were willing to negotiate around the hybrid model, but this does not exist in the current draft. * Re: the five areas of the mechanism that are defined – are these not the correct areas for evolution? * The GGP could say no on evolution on each of these topics – these are not goals that need to be reached. * Should not be afraid of creating something new * What is in scope that would make evolution a policy development matter vs. not a policy development matter. An example – the concept of proximate cause with fully-automated decision making. Use cases that B&B were not comfortable saying could be automated today may be clearer in the future. Why would we need another PDP to change this? The GGP is not lightweight and fast enough to make that happen in a reasonable timeframe. We need a policy recommendation that says when legal guidance is received that makes it lawful to centralize, this should be allowed. * The issue is – once new guidance is received or all are in agreement that things should be further automated – how is this implemented and who decides? Is the suggestion that this should go straight to ICANN org instead of the GNSO Council? * Yes. * Do not agree to this – this circumvents policy-making process. There is already something that allows voluntary automation. Support anything that is voluntary, but anything that is mandatory needs to go through the proper processes. * SSAC did issue a report – SSAC 111 has a significant section on the evolutionary mechanism and notes there is not an existing mechanism that meets the need. * Centralization is not, but should be, in the list of topics the MfE should be charged with. * The Team probably needs some guardrails to ease the concerns of the contracted parties. Do need to recognize that the concept of centralization does not mean full automation. * Based on this conversation, invite those who are interested in continuing this conversation on the evolutionary mechanism to note this in the chat so that the conversation on the MfE can be done in parallel. 1. Confirm next steps 6. Review of public comments received on the addendum (15 min) 1. High level overview (see discussion tables<https://community.icann.org/x/Hi6JBw>) * High-level overview of comments/concerns received on the addendum * Display of information for affiliated vs. accredited P/P providers – main concerns did not relate to the recommendation – many expressed concern over the continued pausing of the PPSAI IRT. Specific proposal put forward that the recommendation should include a PP customer ID to correlate registrations. There are also questions on whether the EPDP Team should consider underlying PP customer data in its deliberations. The group sent a letter to ICANN org that it had concluded its work on PP. * Legal v. natural persons – no recommendation included in the addendum. Group is still waiting for the results of the study. Input focused on opinions on this question. * City field redaction: some groups believe city field should not be redacted * Data retention: number of concerns regarding data retention period – some argued it should be longer but no details were provided for that foundation. There are also two perspectives = CPs – data that is retained can only be used for the TDRP while others want to be clear that the data can used for compatible purposes. * OCTO purpose: there is general agreement for the conclusion reached, but some groups noted that support for this conclusion is tied to Purpose 2 * Feasibility of uniform anonymized email address: this was based on legal guidance from B&B on this topic. A number of commenters noted the group did not have time to fully consider this topic. Suggestion to continue discussing this topic and asking for further guidance * Accuracy and WHOIS ARS: this was removed by the Council from the EPDP Team’s consideration – many comments were related to disagreeing with the Council’s characterization * Purpose 2: there are a couple of commenters that suggested the group should go back to the original purpose 2 language. The NCSG has suggested that the recommendation should be deleted b/c it is not clear enough and worksheets, similar to Phase 1, should be developed. There is a worksheet that was developed for Purpose 2 in Phase 1 that is included in the Phase 1 Final Report. * Ask from the groups: this was a high-level overview. Please review the discussion tables that have been posted and provide your input. Please focus on items where issues could be resolved and included in the Final Report. * Data retention: misrepresents what was being said by CPs – want to clarify that this is what the recommendation stated – the only identified retention period is the TDRP. You can hold the data for the TDRP. * We did not say that data was retained for the TDRP, but the TDRP sets the outer limit. The TDRP sets the outer limit but it is not the only thing it may be used for while it is being retained. 1. Confirm next steps * Small Team will meet on Monday, 8 June at 14:00 UTC. 7. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Thursday 11 June at 14.00 UTC (tentative). Topic to be addressed: ‘cannot live with’ items and draft Final Report. 2. Confirm action items 1. Confirm questions for ICANN Org, if any