Dear EPDP Team: Please find below notes and action items from today’s EPDP meeting. The next EPDP meeting will be Thursday, 23 July at 14:30 UTC. Best regards, Marika, Berry, and Caitlin -- 1. Following today’s call, Support Staff to update 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. 2. EPDP Team to review the updated version of Rec. 8<https://docs.google.com/document/d/10xb5eE3CxTvx5tFNmhsO_F7OdOIRMJFH/edit> and note if any groups cannot live with the updated text by COB today, 22 July. If so, groups to propose updated text they can live, factoring in the discussions to date. 3. EPDP Team to review proposed language for items 37 – 41 (Priority 2)<https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit> and see what text (if any) is acceptable for inclusion in the Final Report. (Note that how these issues are reflected does not change the policy recommendations, nor does it change what the Council is expected to vote on.) 4. EPDP Team members to flag any Category 2 items<https://docs.google.com/document/d/1E7NQQpXob_2Rmsq5UbNyxtySsJVUUzH4/edit> that would benefit from plenary discussion by COB today, 22 July. EPDP Phase 2 - Meeting #73 Proposed Agenda Wednesday 22 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) * The group did make significant progress on resolving most of the ‘cannot live with items’ that were discussed during yesterday’s meeting. * Hopeful that the constructive and pragmatic approach displayed yesterday can be continued for today’s meeting * As noted yesterday, if time remains at the end of today’s call, I will ask you to prioritize which category 2 items should be considered in a plenary setting so we can focus on those. However, as it is likely that we have limited time left we may not be able to get to many or any. As a result, I’ve discussed with the staff support team and we would like to propose to offer additional online time for you to resolve category 2 items. We know this is not ideal, but as the category 2 items did not amount to ‘cannot live with’ items, these should not impact the consensus designation or finalization of the other parts of the report, as long as everyone is clear that further changes would only be applied if there is online agreement between the proposer and those that have expressed concerns (and of course, anyone else that may have concerns once they see the final result). The onus will be on those having proposed the changes to engage in a dialogue with those having expressed concern to find an agreement. Agreement will need to be clearly flagged in the google doc so others can also review and flag if the proposed changes have resulted in cannot live with items. We hope this is acceptable to you as a way to allow for further time to continue dialogue while not jeopardizing our overall timeline. We will share the proposed deadlines for this online dialogue at the end of the call. 4. Continue review of cannot live with items: Recommendation #9 – Automation 1. Item #21 & 22 * Both comments concern the same section in the automation recommendation, namely 9.4 which addresses the use cases that meet the legally permissible criteria based on the input from Bird & Bird. * The first comment from the BC/IPC notes normative language is missing which should be reinstated. Staff support can confirm that as this language originally moved from the policy section to the implementation section, the normative language had been removed, but now that it is back in the policy section, it seems appropriate to reinstate the ‘MUST’. * The second comment from the RySG concerns this same section, and revisions have been suggested to more accurately reflect the analysis provided by Bird & Bird on the automation use cases. As the RySG stated in a follow up comment, their issue is with the misstatement of what the legal opinion states. The legal opinion is not a confirmation of legality but an indication of legality. * Possible compromise combining these two points could be: * “9.4 Per the legal guidance obtained (see here), the EPDP Team recommends that the following types of disclosure requests, for which legal permissibility has been indicated legally permissible under GDPR for full automation (in-take as well as processing of disclosure decision), These disclosure requests MUST be automated from the start:” * Possible footnote that would state: “The EPDP team notes that the advice received was based on several specific underlying assumptions and any derogation from such conditions may affects the validity of the advice received”. * For Item 22, the ICANN org comment is important. The legal permissibility term is dependent on 9.4, but if this is revised, 9.4 would also need to be revised. * The compromise version still references legal permissibility, but now says indicated instead of confirmed * B&B memo mentions lowered risk, not if something is legal. This language is not getting at what the B&B memo talked about. It’s potentially dangerous for the EPDP Team to make a comment about what is and is not legally permissible in this context. What would happen, for example, if something is proven to be legally impermissible? * Want to make sure that we have taken local law into account and data flow. Legal permissibility under GDPR does not take into account any charter requirements. * If we leave legal permissibility to CPs, that will be a problem. * Dealing with a worldwide policy, and B&B was applying a GDPR analysis. It is correct that B&B only provide an indication. For us to say that this is legal everywhere is not correct. Moving forward, it is assumed that what B&B said is probably legally implementable but not in every situation for every contracted party. * Ry comments are not meant to say Rys would not rely on B&B input, but having the policy state categorically what is or is not legal is problematic. * Articles 44 – 49 of the GDPR deal with cross-border transfers. There will always be risk, irrespective of automation. There is no such thing as no risk. 1. Item #23 * Proposed addition by the BC/IPC: “9.X Per the legal guidance obtained the EPDP Team recommends that the following types of disclosure requests are legally permissible under GDPR for centralized disclosure evaluation (in-take as well as processing of disclosure decision) at the Centralized Gateway Manager when subject to manual processing and review from the start: * Automated disclosure decisions for clear-cut “domain matching trademark” requests * Automated disclosure decisions for clear-cut cases of phishing ICANN org is the controller when processing this disclosure decision.” * Question for the group: is there support for adding this new paragraph to the report? * Not clear on what IPC/BC are asking for. The two use case bullets – no input on clear-cut cases of phishing – not sure how that would be achieved. Second bullet regarding trademark requests – this is not a high enough bar for centralized decision-making or automation. Domain names that match trademarks, even an exact match, is not, in itself a clear-cut issue on anything. UDRP requires bad faith, for example. * It is too late to bring in these use cases at this hour – these require subjective review. Who will certify that there is clear-cut phishing? * This is not new; the group has been discussing this for a while. Concerned now re: how evolution would look. This tracks with B&B advice. As long as there is manual intervention (by the gateway), these could be automated. This is very important to the BC/IPC. * The DNS abuse framework is distinct from disclosure of data. The discussion of the DNS abuse framework is a red herring and should not be further discussed in this context. * This aligns with the B&B memo. * Tried a number of times to use centralization, and for better or worse, the group defined automation as possibly including manual steps. Support these use cases. * There does not appear to be enough support within the Team to add this language. 1. Item #24 * Proposed deletion by IPC / BC of 9.14 “In the context of further consideration of potential use cases that are deemed legally permissible in the context of recommendation #18, legally permissible is expected to be determined, in the absence of authoritative guidance (e.g. EDPB, European Court of Justice (ECJ), new law), by the party/parties bearing liability for the automated processing of disclosure decisions”. * The deletion of this section was discussed last week, and there was no agreement to delete it. Has this changed? * Do not support this deletion. Recommendation #8 – Contracted Party Authorization 1. Review of proposal (Amr) to address items #12, #13 #14 * If small team comes up with proposal, consider introducing proposal and giving group 5 minutes to review / consider? * This proposal was worked on by Amr, Chris, and Alan Woods. Concern was that the language mandates differentiation based on geographic location of registrants. The update lets CPs to differentiate but does not obligate them to. GAC raised a concern in response to some of the fixes, which may have resulted in the presumption that the balancing test is to be performed for every request. There are other lawful bases in Article 6. There is now text that references Recommendation 16 – this creates a distinction b/w CPs who differentiate and those who do not. For those who do choose to differentiate, these CPs would not be subject to 8.8 and 8.9. Additionally, a number of changes were made later in the document. Instead of referencing applicable law, it references the lawful basis of the CP. This is important to NCSG b/c there seemed to be a suggestion that if a CP is not required by law to provide a lawful basis, then CP would be obliged to disclose requested data. This is problematic b/c it depended on location of CPs and registrants. The lawful basis should be either lawful bases in GDPR or the applicable law of the CP. * Have these changes resulted in “cannot live with” items? * ALAC cannot support the addition at the top of the policy re: Rec. 16. EPDP Team should not express preferences in this report, especially b/c there is no consensus on this. Propose to strike this sentence, or strike everything after “although” or change the EPDP Team to “some members of the EPDP Team” * The last sentence in the first paragraph expresses a sentiment of the NCSG but may not be representative of the EPDP Team, but was under the impression that since we are building a standardized system that disclosure decisions should be treated as uniformly as possible * In light of the fact that there is no differentiation, have an issue with this statement. Striking the second half of the sentence addresses the main concern. * Status quo in Phase 1 – allows CPs to differentiate. This statement should be included here as there is no work currently planned. * First part of sentence does need to stay in – text after although needs to be stricken * Question from ICANN Org – 8.17 – when reviewing Rec. 8 to define a lawful basis in reference to implementation guidance. The change to this guidance is confusing – what does “lawful basis under ICANN policy” mean? * The ICANN policy referred to is this one. Under terms of this policy, what should be applied is what is under ICANN policy – it would only be when ICANN policy contradicts with local law, that local law would trump * This is an admirable position to take, but it is not within the Team’s charter. * Support Staff to post this recommendation after the call and groups can respond by COB today. 1. Item #16 * BC/IPC proposal to modify 8.7.1 as follows: “Replace the first sentence of 8.7.1 with the following: “8.7.1. If, following the evaluation of the underlying data, the Contracted Party determines that disclosing the requested data elements would not result in the disclosure of personal data, the Contracted Party MUST disclose the data, unless the disclosure is expressly prohibited under applicable law. For clarity, if the disclosure would not result in the disclosure of personal data, the Contracted Party does not have to further evaluate the request. * Staff follow up question asked who would be responsible for making this assessment if the proposed edit is applied and the CP reference is removed. * The BC has responded noting that: “this is an example where ICANN Compliance can evaluate whether the initial assessment by the CP is accurate. * How that would work in practice? Would a CP send its assessment to ICANN org for review / audit? Also, by removing it here, it just leaves it vague who would do the implementation so if the intent is to also have a role for ICANN org, and there is agreement on that, it might be better to specify that instead of taking out who is responsible for this specific part here. * This is not a question of CPs evaluating it; the question is can the determination be subsequently raised with Compliance re: if there is no personal data? This is a factual question as to whether the record includes personal information. If the determination is factually incorrect, then it gives the ability for the requestor to make a request through ICANN Compliance. * What will this complaint be based on? How would the requestor know if the data is legal/natural – this does not make sense. The language as proposed needs to stay. * If you look at the WHOIS record, you could look at the WHOIS record whether there is personal information or not. This is different than the balancing test, which is different than an on-its-face determination. * Not sure how this proposed deletion would prevent complaint submission * This should be a factual determination. The CP reasonably determines instead of determines * Margie to propose an update in the chat * “the Contracted Party reasonably determines that disclosing the requested data” * No objection to this change Recommendation #6 – Priority Levels 1. Item #8 * We briefly touched upon this yesterday. There is a proposal from the GAC and BC to change from MAY to MUST ability for CP to prioritize requests that have been flagged by requestors as concerning a consumer protection issue (phishing, malware or fraud). * As a reminder, the ability for requestors to indicate a consumer protection issue and allow the CP to prioritize it accordingly is included in this way as the EPDP Team did not agree on a definition and criteria for consumer protection issues. It is the expectation that experience gained following implementation might help inform further evolution of a possible priority designation which could be tied to certain requirements. Staff noted that without these criteria and specificity on what a CP is expected to do, it may not possible to enforce a MUST requirement. * The GAC team provided further input noting that: “When CP’s review requests (which they likely must do to assess whether or not to disclose), they would need to flag requests that relate to consumer protection, (including phishing, malware, fraud) and then prioritize these requests ahead of other Priority 3 requests. Another option would be to create another priority level for consumer Protection requests (Priority 3) and let the remaining requests go to Priority 4. BC/IPC may have additional thoughts.” * First question is whether there is concern about this change from other groups and a second related one is whether, if there is support for making this change, there is sufficient information for CPs to know what is expected of them and for ICANN org to enforce this obligation. * Disagree with this new category addition at the last minute. The terminology of what constitutes a consumer protection complaint does not exist. * There is little benefit to allowing requestors to indicate priority requests – just how we have zzz participants go to the bottom of the line, there should be an easy way to move them to the top of the line. The new priority isn’t as important as an obligation to deal with requests flagged in this way first * Thought these requests are coming from accredited consumer protection organization – this should already be flagged in accreditation, so this should not be problematic to implement this. * Timing for dealing with these requests is the same for priority 3, but these requests would jump to the top of the queue * If MUST is not acceptable and MAY is not enough, could SHOULD be a midway – there is an expectation that contracted parties prioritize these requests? * Should in unenforceable – opposed to SHOULD. * There is a concern with deadline to respond to disclosure requests even if the priority doesn’t change. * Uncomfortable with this concept – there seems to be an attempt to micromanage the queues of contracted parties. Agreed to three priority levels, and this is about the request for disclosure of data. Abuse can also be dealt with in other ways (abuse queue, phone, etc.) * There could be, during implementation, where there are timelines within which to do sorting so that that there is no paying Paul and robbing Peter. This is speculative to assume that you’re sorting consumer protection requests over other requests. * Can change to “should” but that is not enough for some. This will be reflected in terms of the consensus designation. Recommendation #7 - Requestor Purposes 1. Items 10 & 11 * Proposed deletion by RySG of “obligations applicable to digital service providers (DSP)” from “Requestors MAY submit data disclosure requests for specific purposes such as but not limited to: (i) criminal law enforcement, national or public security, (ii) non law enforcement investigations and civil claims, including, intellectual property infringement and UDRP and URS claims, (iii) consumer protection, abuse prevention, obligations applicable to digital service providers (DSP) and network security”. Rationale: from a practical perspective, we think naming one specific regulated entity while omitting all others creates confusion and implies that we are intending to favor the requirements of this regulation above all others (in fact, as written we are even omitting other regulated entities under the same NIS regulation that may have similar obligations, e.g. Operator of Essential Services). There are numerous regulated entities globally that may assert that they require data to fulfill regulatory obligations and future laws will almost certainly create ones that don’t exist today. A categorical approach that captures the types of obligations that regulated entities have (e.g. network security, consumer protection, abuse prevention) provides greater flexibility and future-proofs the policy. * Subsequently, BC provided a proposed footnote: ““For the purposes of this Recommendation, the obligations of DSPs are specified under EU NIS Directive of 2018 <https://ico.org.uk/for-organisations/the-guide-to-nis/key-concepts-and-definitions/.> However, RySG has noted that BC addition does not address the RySG concern stated. * BC/RySG to discuss how this concern can be addressed. * Important to remember that this is a ‘MAY’ as well as ‘such as but not limited to’ phrase. * Important to reference this, even though it is a may * There a number of regulations that create obligations for parties that request data – by including one and omitting all others, we are implied that the entities under this one statute are differently situated than others. Should not have to enumerate all entities, and should not enumerate one at the exclusion of others * Nothing in the policy is preventing anyone from submitting a request * This is a last-minute request by the CPs to take this out. The specification of internet security requests is important * BC and RySG to take this issue offline Recommendation #5 / #8 – footnote re. ICANN org compliance review 1. Items #7 & 18 * Discussed during yesterday’s meeting. * Note ICANN org liaisons proposal: ICANN org suggests deleting footnotes 22 and 29 to avoid confusion with the requirements in this report. The footnotes were intended to add clarity to these recommendations, but now seem to contemplate new obligations or reinterpret existing obligations. For clarity in implementation, ICANN org would recommend deleting both of these footnotes. * Could live with the removal of the footnote – just want to make sure this is covered elsewhere * Agree with removal of footnote Recommendation #10 – SLAs 1. Item #25 * Discussed during yesterday’s meeting – RrSG proposal to change SLA for urgent requests from ‘1 business day, not to exceed 3 calendar days’ to ‘1 business day, not to exceed 5 calendar days’. * Proposal put forward after yesterday’s discussion: Addition of Footnote (based on Laureen’s proposal) for Priority Requests: During the implementation phase, ICANN org should consider an exemption process for smaller registrars for whom it may be difficult to meet the Priority 1 SLA requirement. In considering an exemption process, note that the CP may recategorize a request if it determines that the request does not meet the criteria for Priority 1 (urgent requests). When the CP determines the criteria for an urgent request have not been met, it is not required to respond under the Priority 1 SLA requirement. * If this is not acceptable, possible compromise approach is to make it 4 calendar days? * There is a provision that allows a CP to recategorize the request. If they do that, they need to provide an indication of why it was recategorized. * Registrars cannot agree to 3 calendar days. * If we cannot come to agreement, this previous agreement will stand, correct? * Yes. * Doubtful that this very narrow category of requests will create a problem. Recommendation #14 - Financial Sustainability 1. Item #27 * Proposed addition by ALAC and supported by BC, IPC and SSAC: "The prospective users of the SSAD, as determined based on the implementation of the accreditation process and Identity Providers to be used, must be fully involved in the discussions on setting usage fees for the SSAD. In particular, those potential SSAD requestors who are not part of the ICANN community must explicitly be included.” * This was also one of the proposals flagged in the yellow items and at the time, opposition was noted from RrSG and ISPCP. Furthermore, the ICANN org liaisons had noted that “The proposed new language seems to be phrased as Implementation Guidance. ICANN org notes that fees are typically derived from a variety of sources, including financial analysis, projections, and others. This could include consultation with potential users as described here; however, it may not be possible to arrive at a fee model supported by all potential stakeholders”. * Could groups live with this addition? In order to address the concern expressed by ICANN org, the group may want to consider adding something like: “however, involvement in the discussions does not mean that the final model must be supported by all before it can be implemented.” * The IRT will go on a long time, the vast majority of issues have nothing to do with the costs. * A reasonable suggestion – these people join the IRT, even if only for the financial sustainability discussion, or to provide public comments. * “should be consulted” or “may be offered the opportunity to comment” seems fine * This system has to pay for itself – the only definite form of income we have identified is the users of the system. There should be a consultation process and users can provide comment on. * The word comment is weak – would prefer “comment and interact” – the issue here is not whether they will pay or not, but it’s really about the payment structure – is it per use or a yearly subscription. * Proposed updated version: The prospective users of the SSAD, as determined based on the implementation of the accreditation process and Identity Providers to be used, should be consulted on setting usage fees for the SSAD. In particular, those potential SSAD requestors who are not part of the ICANN community must have the opportunity to comment and interact with the IRT. This input should help inform the IRT deliberations on this topic. * NCSG can live with this if 14.2 is not altered 
 Recommendation #18 – GNSO Standing Committee 1. Item #34 * Proposed addition by ALAC / BC to this section: “Recommendations concerning implementation guidance shall be sent to the GNSO Council for consideration and adoption, after which they will be sent to ICANN for further implementation work. Recommendations which require changes being made to existing ICANN Consensus Policies shall be recorded and maintained, to be used in the issues scoping phase of future policy development and/or review.” Proposed addition: For avoidance of doubt, recommendations related to disclosure decisions to be made by the SSAD in accordance with Section 9.3 are deemed to be implementation and do not require policy development." * Input already provided: NCSG: In our deliberations there was an explicit recognition that some recommendations may require policy changes. Insofar as this request says that anything the Standing Committee recommends is not a policy change, it is a non-starter” Response from ALAC: “The sentence does NOT say that ANYTHING recommended by the Standing Committee are not policy. The Standing Committee may discuss anything and some of that may indeed be a recommendation to the GNSO to initiate a PDP (or other policy process). Recommendations that are in line with the Policy from this PDP and in accordance with the strict limitation of 9.3 should not be among those.” * The staff support team also noted that this addition seems to preempt the ability for the Standing Committee to determine what aspects are deemed operational / implementation, and limit the ability for the GNSO Council to provide oversight over this distinction. * All this says – if a recommendation is about a use case for disclosure, it is not policy. * This is a critical issue for ALAC support * BC’s view of hybrid model is that it could move from decentralized decision-making to centralized decision-making without a policy change * IPC also agrees that this is needed in order for IPC support of this recommendation * The absence of this clarification * Seems to be one disagreement with current formulation – chair to take note for consensus designation 1. Item #36 * Do not disagree in principle, but concerned about this implementation of this – who makes this determination, is there an escalation path, etc. * Members could appeal to the chair of the GNSO Chair – that goes for any ruling, and especially rulings re: consensus. * Not everything can be escalated to the GNSO Council. The original proposal was for full consensus; the change in this was a compromise. This would be an additional compromise, and do not agree with this. Prefer full consensus. * There is not agreement to add this language. Priority 2 related items 1. Item #1 2. Item #37-41 * All these items concern priority 2 topics, and especially legal/natural and accuracy and how these are (or aren’t reflected in the report). From reviewing the comments, it is clear that members have different perspectives of what the status or perceived agreements / conclusions are, as such, the proposal here as to clarify in the report which topics are not addressed (legal / natural & feasibility of unique contacts) and clarify that the Council is already discussing how to address these topics, in addition to accuracy, but leave it at that. Of course, if you are all able to agree on a way to summarize the status of these issues, we have no problem to include this, but from what we’ve seen, versions are far apart. * Note that how these issues are reflected does not change the recommendations or what the Council is expected to vote upon. * Group to review the proposed language and see what they could live with. * For tomorrow’s meeting, we may have limited time to discuss Category 2 items. We hope to give people additional online time to see if compromise can be reached. If some items would benefit from plenary discussion, members to flag them. If time remains: 1. Category 2 items (groups to prioritize which items they would like to flag / discuss) * If time allows, consider tackling items #95 and #101. * Groups should be asked to identify which items they consider a priority. 5. Wrap and confirm next steps (5 minutes): 1. Expected approach for consensus designation (Chair) 2. Remaining timeline: * 22 – 26 July – continuation of online dialogue on category 2 items * 27 July – confirmation in google doc of proposed agreements on category 2 items by staff support team – by 28 July groups to confirm if they cannot live with the proposed agreements (if cannot live, proposed agreements will NOT be applied) * 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