Dear EPDP Team: Please find below the notes and action items from today’s meeting. Thank you. Best regards, Marika, Berry, and Caitlin -- Action Items 1. Following today’s call, Support Staff has updated the Google Doc<https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit> to reflect (i) EPDP agreements reached on the call, and (ii) proposed updated text based on the Team’s discussions. EPDP Team to review updates, and items flagged during today's call (1, 7, 8, 10, 11, 13, 14, 16, 18, 21, 22, 23, 24, 25, 27, 34, 37, 38, 39, 40 and 41) and come prepared to tomorrow's meeting with constructive ideas. 2. EPDP Team members to flag any Category 2 items<https://docs.google.com/document/d/1E7NQQpXob_2Rmsq5UbNyxtySsJVUUzH4/edit> that, if applied, would result in “cannot live with” by COB today, 21 July 2020. EPDP Phase 2 - Meeting #72 Proposed Agenda Tuesday 21 July 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) a) Recap of proposed approach * Focusing on questions within this doc: https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit 4. Commence review of cannot live with items: 1. Introduction of proposal for item #1 (Staff Support Team) * This issue relates to the executive summary and the conclusions related to Priority 2 items. GAC noted this summary did not address legal vs. natural persons. No agreement was achieved on some topics, so those topics are not reflected here. However, later in this document, there is a suggestion for text re: topics not covered in this report. 1. Deliberate on question for item #2 & #3 (EPDP Team) * These topics relate to the introductory section of Chapter 3. This text is not part of the recommendations. It references that the EPDP considered various models. NCSG put forward additional language that should be included. Comment 3 from the ALAC/BC added additional language. Some members do not agree with these comments. Question – are there concerns about this addition. Please keep in mind this is the intro, and not part of the recommendations. * There is no need for the change suggested, but if we do make it, need to have the addition in 3. * Some members believed a centralized model was not technically or legally possible in the timeframe given. * All groups except NCSG prefer the centralized model. The language here is factually inaccurate and cannot go into the report. We have not rejected the other options; we just do not have sufficient legal clarity at the time of the report publication. * This is not policy, it is a description of what happened. The Team reached a compromise on a hybrid model. To say that everyone but NCSG opposed the centralized model is demonstrably false. To say that a hybrid model is one step away from a centralized model is incorrect. Can live with striking the word “typically”. Did not have agreement on a centralized or decentralized model, but compromised on the hybrid model. * The Team only agreed to discuss the hybrid model as a step to get us to a step to as much centralization and automation as possible. The question remains if this language would remain – cannot live with characterizing this report that is the result of consensus and everyone agreeing to reject the centralized model. * This is not about what the Team prefers but what the legal realities are. The centralized model is never going to happen; the hybrid model may have centralized elements to it, but it will never be fully centralized. * If you take a look at the room – there is not consensus on one view vs another. * Support Staff to put forward language based on the comments and suggestions from the group. 1. Deliberate on question for item #4 (EPDP Team) * Following the last call, and based on Janis’ suggestion, Support Staff added language re: recommendations being interdependent and considered as a package. If this makes the group uncomfortable, should this language be removed? This doesn’t change the fact that there are interdependencies in the report. * If we decide to pass the report to the Board without the evolutionary mechanism, that would be a problem for ALAC. There are strong reasons why the group cannot pick and choose. * Apart from how the EPDP Team considers the interdependencies, is the last sentence correct? Can the Team tell the GNSO Council how to consider the report? * If we tell the Council the option to pick the recommendations apart, would have to advise councilors that if certain recs are pulled, support will have to be pulled. The recs should be considered as a package. * This would be a suggestion to the Council, not a requirement or mandate * Registries raised this procedural concern b/c were surprised to see this in the language, as this was not discussed or agreed to. Not all recommendations are interdependent. Rec. 22 deals with Purpose 2, for example. Agree with points others have made that the recommendations about the SSAD should be a package. * Staff to put language in to reflect input received. 1. Introduction of proposal for item #5 (Staff Support Team) * For those items where there is a proposal, Staff will introduce the proposal but there will be no discussion at this stage. Groups are asked to note which proposals they cannot accept or which require further conversation. * In the introduction, there are many principles and concepts that underpin the development of the SSAD. GAC asked if these should be part of the policy recs. Staff noted that each of these principles can be found in the recommendations as these principles are translated into a number of recommendations. 1. Introduction of proposal for item #7 & 18 (Staff Support Team) * Many comments have been made on these proposals. This relates to a footnote regarding what ICANN org can do. ICANN org has been clear from the start that it cannot address the merits of the request or the CP’s determination. This footnote was also discussed on the last call. BC/IPC have requested to delete text re: the merits of the request or the CP’s decision to disclose or note. Removing this from the footnote may create a false expectation, so propose to leave footnote as it was. Encourage groups to note what is missing here and what is not reflected in the footnote. 1. Introduction of proposal for item #8 & #9 (Staff Support Team) * Recommendation 6 – priority levels re: Priority 3 requests. The group discussed if there should be a separate category for consumer protection issues. There was a debate about what the criteria would be. The conversation ended up with CPS MAY prioritize, and experience gained could lead into a consideration of another category in the Rec. 18. Proposal made by GAC and BC/IPC is to change MAY to prioritize to MUST. From an implementation perspective, this could introduce many challenges. Would be helpful for others to weigh in, particularly Contracted Parties – would this provide sufficient guidance on how to enforce this? 1. Introduction of proposal for item #10 & 11 (Staff Support Team) 2. Deliberate on question for item #12, #13 & #14 (EPDP Team) * Do the same requirements apply to the review of disclosure requests by contracted parties? NCSG proposed to remove a number of sections. CPs have submitted similar proposed additions here. Ry language narrows the scope where it only applies to the disclosure of third parties. Are there any objections to adding this language? If so, what does this mean for sections 8.8 or 8.9, or does 8.9 disappear, and every request is subject to balancing and review? ICANN org noted that this seems to conflict with the Phase 1 rec re: geographic differentiation – would the proposed addition override this requirement? * This is directly counter to a Phase 1 recommendation without explicitly saying this. We have been repeatedly told that we cannot add something because someone wants them. To introduce this on the second to last day is unacceptable at this point. * Do not support the removal of 8.9 – there are different protections based on the legal basis. 6(1)(f) balancing is not required for all requests. 8.9 is crafted where we have to protect data subject’s data, but the balancing test is not required. Is there an extra safeguard that could be added? This is not about removing protections; it is to apply proper data processing rules based on the applicable lawful basis. * NCSG is not proposing that a balancing test is required for each disclosure. If a legal basis is being used other than 6(1)(f), there will be no required balancing test. Trying to have a policy that is globally consistent – just b/c a registrant is not based in the EEA does not mean they should not be entitled to GDPR protections. NCSG has been consistently advocating for not differentiating on a geographic basis. * Could there be a clarification on this – the comments seem to be focused on the geographic distinction. Maintain the philosophy from Phase 1 that a registrar may apply a geo distinction if they so choose. * The language does not make a geographic distinction – there is an overarching policy that provides protection to the data subject. As a way forward, could add something to say that the purpose of this rec is to restrict. * The language does not say what the consensus was – the agreement was that there would be a global policy that would apply. The charter provides human rights, and if this Team fails to consider this in the context of a policy, we will end up in court. * What needs to be emphasized here is that the specific 8.9 is not what was agreed. The idea is that there will be a global policy. The language needs to be changed – if it’s not prohibited, you are required to disclose. That needs to change – that is a cannot live with. 1. Deliberate on question for item #16 (if input is received) (EPDP Team) 2. Deliberate on question for item #20 (if input is received) (Staff Support Team) * Is there any concern for Ry proposed addition? * No concern – recent court decision has made it clear that cross-border transfers are important – * Agree to add 1. Introduction of proposal for item #21 & possible question for item #22 (if input is received) (Staff Support Team – EPDP Team) 2. Introduction of proposal for item #23 (Staff Support Team) 3. Introduction of proposal for item #24 (Staff Support Team) 4. Deliberate on question for item #25 (EPDP Team) * Any concern with business day requirement change? * Do not agree – keep as 1 business day, not to exceed 3 calendar days * These are urgent requests – 3 calendar days was a reasonable concession. Do not buy that smaller registrars cannot operate 24/7 for certain issues as the RAA already has 24/7 requirements for certain items. * Many registrars feel strongly about this. 3 calendar days is a make-or-break – this is not doable. * Asking for more than 3 calendar days is not something other groups can live with. Perhaps there could be implementation guidance a way for small registrar faced with an actual urgent request that it cannot fulfill within 3 days, they could seek a waiver of this requirement. Assumption is this will not happen very often. * Support Staff to write up this compromise. * Had we known we could reopen issues or suggest completely new items, ALAC would have added in more items. * Will take note of registrar disagreement 1. Deliberate on question for item #26 (EPDP Team) * No additional comments. 1. Introduction of proposal for item #27 (Staff Support Team) 2. Deliberate on question for item #28 (EPDP Team) * Does this new requirement mean that all costs of SSAD need to be passed down to accredited requestors? * It’s difficult for gov’t and law enforcement agencies to pay for access. Changing this to a “must” brings up the same issue. * Recognizing this is an issue for law enforcement and public sector users of the SSAD – not trying to revisit this issue. Trying to avoid a situation where there are 1000 accredited users of SSAD and 995 say they cannot pay for access. For the most part, or in general, the operating costs will be borne by accredited users. * Staff to work on language based on this. * The language needs to make clear that there is no prohibition from ICANN funding part of it. * Problem with victims of DNS abuse bearing the brunt of the fees. Proposal to leave the language as is. To bear the brunt of it is not what was agreed and is objectionable. * The Team did agree on this very watered-down language. There is already language regarding exceptions. * Consider changing “may” to “should” – all paid by users in a nonstarter * Changing must to should raises more questions than answers 1. Deliberate on question for item #29 (EPDP Team) 2. Deliberate on question for item #30 (EPDP Team) * First proposal – add a sentence – for purpose of determining level of consensus, each of the 9 groups must have equal weight. This may contradict the language regarding contracted party having a veto. * No intention for there to be a contradiction – if there is, can add “subject to requirement for have CP support” after the word weight * Not sure what the edits will accomplish * In terms of where it needs to be placed, that is OK * Agree to add this language. 1. Deliberate on question for item #31 (EPDP Team) * Proposal from IPC and BC to add to the scope “may include the word centralization” in addition to other topics – is there any concern to adding this? * Do not object to adding centralization to the language but concerned with the rationale and the use of the word “ensure”. There is no certainty that use of this mechanism will result in centralization. * The proposed language is probably OK. * The proposed language will be added (note “ensure” will not be part of the recommendation) * Suggestion to address – update the text to say “this may include but is not limited to…decentralization…” This could capture that this could swing either way and is not a deterministic evolutionary mechanism. 1. Deliberate on question for item #32 (if input is received) (EPDP Team) 2. Deliberate on question for item #33 (EPDP Team) * Proposed addition “if seconded by one other group’s committee member” – any concerns with this addition? * Good clarification. Idea is – if one group wants to talk about a specific topic, that is a really low bar. 1. Introduction of proposal for item #34 (Staff Support Team) 2. Introduction of proposal for item #35 (Staff Support Team) 3. Introduction of proposal for item #36 (Staff Support Team) 4. Introduction of proposal for item #37, #38, #39, #40, #41 (Staff Support Team) If time remains: 1. Groups to indicate which items are flagged for further discussion * Staff proposals were inspired by conversations to date. Ask groups to flag which proposals need to be discussed further in a plenary setting. In certain cases, the groups may have to agree to disagree. The Team can begin its discussion during today’s meeting, and more discussion can take place tomorrow. Will also consider Category 2 items where groups have expressed concerns. * Proposal to save Priority 2 items for tomorrow’s meeting. * Item 12 * Need more time for this particular issue * Item 7 * Question to IPC/BC – by removing this language, what is this intended to achieve? * Trying to develop a policy that can evolve over time – the footnote raises a current issue, but what if this evolves in the future? * There is a problem if ICANN can’t or won’t enforce the policy. * What is the goal of IPC’s comment here? * Disagree with Org interpretation – for example, if there is a legal person’s data, that can be enforced. * ICANN org is OK with deleting procedural. Probably safer if we discuss what ICANN will and will not enforce. ICANN will enforce anything that registrars explicitly MUST do. ICANN can’t second guess the decision making of a CP. * Proposal to add the decision to disclose or not to disclose is not unreasonable. It cannot be an enforcement of procedural aspects of the requirements. 1. Consideration of category 2 and 3 items that have been flagged * Homework to Flag Cat 2 items that you cannot live with. 5. Wrap and confirm next steps (5 minutes): * 22 July – EPDP Team meeting to finalize review of outstanding items and discuss next steps, including further details re. consensus call. * 23 July: distribution of Final Report and consensus designations. As a reminder, the Chair will make an evaluation of the support achieved for the recommendations and publish its designation for the group to review. * 23 - 27 July: opportunity for EPDP Team to respond to consensus designations, review by Chair of input received, if any, confirmation by Chair of designation. * 27 July: deadline for minority statements. * 31 July: No later than date for submission of Final Report to the GNSO Council