Dear EPDP Team: Please find below the notes and action items from today’s meeting. Our next meeting will be tomorrow, Wednesday, 1 July at 14:00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin Action Items 1. As noted during today's call, for any flagged issues that were deemed non-substantive or were of a clarifying nature, the Staff Support Team suggested a proposed approach / clarification for your review (in bold), based on deliberations to date and/or feedback that has been provided by team members. (Please see attached document.) If this has resulted in any ‘CANNOT LIVE WITH’ items, EPDP Team members to flag this by the end of today (Tuesday, 30 June) so that these can be further considered. For any items flagged as CANNOT LIVE WITH, please provide both an accompanying rationale for why this is a ‘cannot live with’ item and specific suggestions for how the concern can be addressed. EPDP Phase 2 - Meeting #68 Proposed Agenda Tuesday 30 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. Proposed timeline for next steps: Leadership counted back from 31 July to plan out the remaining schedule detailed below * 30 June / 1-2 July: finalize review of outstanding cannot live with items, rec #6 (CP Authorization), rec #7/16 (automation) and rec #19 (mechanism). * 5 July: distribution of updated draft Final Report. * 6 - 10 July: silent week – opportunity for EPDP Team to review draft Final Report and flag any minor edits (no reopening of previously discussed & addressed issues). * 14 July: tentative EPDP Team meeting to address any issues that may require EPDP Team input / guidance. * 17 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. * 20 - 24 July: opportunity for EPDP Team to respond to consensus designations, review by Chair of input received, if any, confirmation by Chair of designation. * 24 July: deadline for minority statements. * At the latest by 31 July: submission of Final Report to the GNSO Council * When it comes the SSAD recommendations, they should be seen altogether – either the Team is prepared to live with this or not. It would be impossible to work on a system where only parts are agreed to. * Earlier this year, the GNSO passed PDP 3.0, which includes the implementation of project change requests if a group is going to miss its projected deadline. The Council granted the group’s change request from 11 June target to 31 July. The Council did have consternation over this project change request. As noted above, there is no slack in this schedule. If there is no agreement, there will likely be no appetite for the Council to extend the deadline beyond 31 July. 4. Consider outstanding items / questions in relation to recommendation #6 – Contracted Party Authorization 1. Review outstanding items / questions i. Action item: If the Team is of the view that the bolded proposals result in “cannot live with” items, please flag them by COB today. ii. Leadership boiled remaining questions to four outstanding questions. * In all instances where a request is approved or denied, does the EPDP team intend for the rationale to be documented and communicated to the Central Gateway Manager? * Yes – uploaded to Central Gateway * Disagree – needs to be uploaded to Central Gateway, just need to make sure there is nothing confidential uploaded. * Unless there is a co-controller arrangement, this data cannot be further processed without a separate reason * This is an important part of the recommendation process, so the answer is – every instance needs to be documented at the central gateway * If the SSAD cannot produce statistics on how well this is working, there is no longer even a glorified ticketing system – even what we’re left with is not worthwhile if there can’t be proper reporting * This is a hybrid system and decentralized disclosure decisions – no problem with keeping track of what decisions were made, but have a problem with recommendation system from the central gateway manager which is then going to bypass the hybrid model * Have a problem with full details of why a decision was denied, but reluctant to move ahead with this b/c of bureaucracy, overhead, and how long it will take to review each ticket * Instead of “rationale” use “reason for denial” – communicate reason for denial * If there is a dropdown menu, that could work, but that it isn’t how the recommendation is worded right now. This could result in added costs to registrants * The group needs to reread Recs. 1 – 19 to see how these recommendations interact – for example, for logging and auditing, CPs need to document their reason for denial – for this question – do CPs need to feed the CGM all information? * Problem NCSG has with this rationale documentation is not based only on the cost. The more fundamental issue is the training mechanism for automated decision-making, which takes the team away from the agreed upon hybrid model. * In the sentence of 8.2, CP must document the rationale of its denial – change this to “communicate the reason of denial to the CGM” which is less than the rationale * Reason could be “insufficient data” or “insufficient power” but wary of agreeing to vague, high-level language that will be tossed to the implementation group * The Team seems to be in agreement that what will be conveyed to the CGM will be a reason in a fact-less manner, and the detailed decision will be held at the CP * ICANN org liaisons were really asking – 9.2 – deny the request but not details about the rationale – this was a consistency question – any time the CP denies a request – should they document it? * “indicate the category for its denial” – here, there is no chance there will be personal data in the category * The question – what should be shared with the CGM, and Support Staff has sufficient information here – a simpler reason for denial that is provided to the CGM * This rationale does belong in section 9.2 as well – we may need to get rid of the “not” in the legally prohibited “and indicate the category for denial” * Can the EPDP team please clarify what is meant by “whether further balancing or review is required” in 7.2.3? On what basis would a Contracted Party make this determination? Would “further balancing or review” be conducted in addition to the “substantive review of the request” in Authorization Determination Requirements, paragraph 7? In addition, it is unclear how to enforce Authorization Determination Requirements 8.1 and 8.2 without further clarification on the intent of 7.2.3. * Further balancing or review was used to not be too GDPR specific * 7.2.1 – the CP is going through its decision-making – lawful basis – may need to conduct a balancing test. 7.2.3 now discusses whether further balancing – when is further balancing required when there was already a 7.2.1 balancing * If the lawful basis wouldn’t require you to do a balancing test, this a catch-all for when a balancing test wasn’t done in the first place * Paragraphs 8 and 9 are tied to 7.2.3 – this is only tied to when further balancing is required * A balancing test is implied in 7.2.1 already b/c 6(1)(f) may be the lawful basis, and a balancing test is required at this point * From a staff perspective, the way this was split up – CP would look at lawful basis for disclosure, if 6(1)(f), 7.2.3 would be part of that consideration. As part of 7.2.1, the CP could start the balancing, but this is called out. If this gives more sense of comfort, section 7 could be noted, instead of 7.2.3. * Consider deleting “further” or whether balancing was required as section 7.2.1 * Concern has been expressed about the addition: “MUST determine its own lawful basis, if a lawful basis is required, for the processing related to the disclosure decision.”, which was made in response to a comment by ICANN Org (“As a lawful basis is not always required for a disclosure decision, ICANN org suggests editing the requirement to make this clear”.) The ISPCP noted that: “addition not supported. We are dealing with a global policy and therefore, there should be no distinction between the local laws. That would erode the protection for the users and lead to fragmentation in the marketplace. * Lawful basis for disclosure is a GDPR concept. If I’m processing data in New Mexico, and I’m not required to have a lawful basis, is this now making it a global requirement? * This is supposed to be a global policy. Thought that for each and every disclosure, you need a lawful basis. * If you are in a case where GDPR applies, you need a reason to disclose. If GDPR is not applicable, the concept of lawful basis does not apply. * Modeled the policy around GDPR – having done so, GDPR and the lawful bases are now applicable to registrants throughout the world. We cannot erode the fundamental principles of modeling the policy after GDPR * If the concept of lawful basis does not exist in my jx, do not want to prohibit disclosure – it is appropriate to carve out language for jx where this applies. Compliance may be in a tough position to apply this standard for jx where there is no lawful basis – how would those CPs apply this? * In Phase 1, Rec. 16 allows Rrs and Rys to distinguish based on a geographic basis, so want to be consistent with this recommendation. * This text cannot remain in there – it would allow for forum shopping * The concept of lawful basis is a GDPR concept – how should ICANN explain to a Chinese registrar that it needs a lawful basis? * Do not see a problem here – lawful basis could mean the legal ability to disclose. When building this system and providing advice to contracted parties, can explain what is meant by that. * In compliance with the policy, there is no conflict what we’re looking at now and Phase 1 rec re: geographic differentiation * It’s confusing to use the term lawful basis – could replace with “if applicable” * Add a footnote that notes where the concept does not exist in other jx, not that if it is not legally prohibited * When writing footnote, please make sure that there is not geographic jx assumed * It was proposed that “in content on a website associated” (“nor can the disposition of a request be solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name”) be deleted because “Issues related to content on a website should NOT be addressed with the registrar or registry. (see: https://www.icann.org/resources/pages/spam-phishing-2017-06-20-en & Section 1.1.(c) of ICANN bylaws)”. The BC has noted that the link provided in the RrSG rationale for deletion “is related to abuse notices, presumably leading to take-down requests, whereas the Rec is intended for something completely different (request for data disclosure)”. Does this clarification address the RrSG concern? * If you cannot say the word content within the document, this will be a problem. You cannot always say no for no other reason than if we’re asking about something on a website * Cannot live with word disposition here – this causes a conflict b/w this recommendation and the recommendation to automate requests. Re: content on a website – we’re not talking about abuse – we’re saying in language taken from the PPSAI policy – ONLY b/c of content on a website * Content on a website may be relevant to an infringement proceeding – that is still a domain name case, not a content case – there is nothing risked here by getting rid of this language, and there are risks for keeping it in here. * Content may be relevant – this is not talking about a Rr/Ry to take action – it’s allowing the requestor to find out who is behind a website – purposes are not limited to strings in a domain name – this could be relevant for phishing. * Cannot agree to content being in this. * But if UDRP and URS are based on content, can you agree? * Agree to delete final clause: nor can the disposition of a request be solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name 1. EPDP Team Feedback 2. Confirm next steps 5. Consider outstanding items / questions in relation to recommendation #19 – Mechanism for evolution * Rec. 19 proposal – the outstanding issues are scope, and the delineation b/c policy and implementation issues – how is this to be addressed and further clarified. There is concern around the decision-making process. There is also concern around guaranteeing that ACs are also involved in the scoping of the effort. There are some minor issues that have been flagged whether some of the data is necessary. * Could the standing committee as a method raises any difficulty – can anyone not live with the GNSO Standing Committee model? * The problem from an ALAC side is how it makes decisions and how those decisions are handled – what is the scope, and how are decisions made? * On the scope: the only sticking point was around automation – Amr suggested not limiting the scope of the group only to these items, but having flexibility * There were several motivations behind this proposal – one having a GNSO standing committee instead of an ICANN-chartered group – this should go through the GNSO first. Having it as a standing committee to make sure that the committee’s work is not under the gun to finish its work. With separating the scoping issue out of here and focus on policy disagreements elsewhere and create a low required threshold to introduce topics into the committee – do not mind a few examples being listed here is a problem. Low threshold to introduce topics; a high threshold to adopt them. * By leaving a number of critical issues unspoken here, this process could have the same problems the GGP did; we just do not know at this point. Vagueness may be helpful to get agreement, but not sure this evolve into something that is acceptable. 1. EPDP Team feedback 2. Confirm next steps 6. Continue run through of yellow items (items identified for further discussion / clarification) 1. Consider yellow items identified for recommendations (continuing with rec #15 and moving down the list 2. EPDP Team feedback 3. Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Wednesday 1 July at 14.00 UTC. Topics to be addressed: Recommendation #7/16 (automation), Recommendation #19 (mechanism). 2. Confirm action items 3. Confirm questions for ICANN Org, if any