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. EPDP Team Members to review the remaining yellow items<https://docs.google.com/document/d/10IQOJDwEpHj5meIb4P8JAIW2qb2A0oVp/edit>, provide additional information in response to questions, and indicate items that are still “cannot live with” and provide alternate text that is acceptable by COB Friday, 3 July. EPDP Phase 2 - Meeting #71 Proposed Agenda Thursday 2 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) 4. Consider outstanding items / questions in relation to recommendation 7/16 (automation) [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> * The draft on the screen was developed by the Staff Support Team after the Team’s last discussion of this item * A small team worked with staff on this version but did not come to any agreement on this version * The first change was to number the various paragraphs here * Updating processed in an automated manner instead of automatically disclose * In 16.4, the footnote now appears in the text and explains how a CP can notify ICANN org of a situation where the CP cannot automate a certain category of use cases * Following the notification, some members suggested a notice and comment process * As soon as CP becomes aware that the exemption is no longer applicable, it is required to notify ICANN org to resume the processing * Updates to implementation guidance – updated to make the text clearer. In this specific recommendation, four use cases have been identified. a. Review outstanding items / questions b. EPDP Team Feedback * Footnote 3 conflicts with text regarding decisions where there may be some manual review – suggest deleting footnote 3 * On 16.4, confused why a waiver only addresses the legal permissibility issue and not the technical or commercial feasibility issue – these should be included in the exemption process. * For 16.5 – all that is required is for a CP to get this waiver is to send a notification to ICANN. How did the small team envision this working? In the spirit of automation, this should be automated as well. * Regarding a data subject’s rights to object to processing based solely on automation – where would that fit into all of this? * Have to resolve the conflict b/w footnote 3 and 16.11 in the recommendation. The “may” is unclear as to when it is invoked. Would envision that a use case could be approved, subject to there being human intervention, but the wording does not seem to allow for the fact that human intervention must be required. * The last sentence of 16.8 seems to belong in 16.5 * This can be put in a separate section for the sake of clarity * Need confirmation from ICANN org that it can refuse exemption requests that are not deemed to be reasonable * Confused as to how we ended up with processing of disclosure decisions instead of automated disclosure decisions – this text changes fundamentally what this section means – suggest automated disclosure decisions and related processing. * Regarding determination of permissibility and feasibility – this needs to be made by the contracted party. For 16.4 – there is the word “demonstrates,” this conflicts with 16.5 and the word notifies. 16.4 should be changed to notified. 16.5 is a good solution – had originally objected to a process akin to the data retention waiver process. * By having CPs prove to ICANN that it has a legal issue, it puts the onus on a CP to prove that something is not legally permissible, and this should be the other way around. Could “demonstrate” in 16.4 be changed to “determine”? * If there has been an exemption request that has been determined and notified, and that exemption request is granted – there should be a mechanism where similarly-situated contracted parties could get the same exemption. * Re: automated disclosure and automated processing, it sounded like terms were redefined. Where we talk about legally permissible, and technically and commercially feasible, technically feasible and commercially feasible need to be broken out. There could be standardization for automation. Overall concern regarding Org’s agility to facilitate this waiver process. * Automation is technically feasible – full stop. Legally permissible – we’re on the right track with a jurisdictional opt out. For commercially feasible – this is a chance to improve this and not leave it to the sole discretion of contracted parties. What types of scenarios would make it not commercially feasible for a contracted party to automate? If CPs are not commercially able to connect to the SSAD, that is a problem. We need some guardrails around commercial feasibility. * In this final report we determined a few areas where automated disclosure must be done, and then recommendation 19 kicks in. Do not see a place where CPs can opt out of commercial feasibility. * Agree that if you are not up to the task to be contracted party, there are other options (like becoming a reseller). For when a registrar that is not commercially feasible, it could be a registrar with no registrations or only has a small number of corporate registrations * For 16.1 and 16.2 – any problems with proposed text? * No. * For 16.3 – any problems? * No problem with 16.3 if commercially and technically feasible could be added to 16.4; otherwise, the “must” is problematic * Prefer the obligation to be to demonstrate that what is proposed is not legally permissible * The right for data subjects to object is already covered under legal permissibility * Footnote 3 is a footnote to the title of the section – when will we discuss this? * In 16.4, would the technical and commercial feasibility apply in the same way that legal permissibility is captured here? * If “demonstrates” becomes “determines,” this would be OK * On 16.4, could we say “the CP can get an exemption from automated processing but must notify ICANN” – the current language implies that ICANN will decide whether the exemption applies or not. * With the language in 16.5, this is OK. * IPC has a concern with changing demonstrates to determines – the right to unilaterally determine whether they are going to follow the policy or not is unacceptable without the ability to follow some guardrails. Technically and commercially feasible is too subjective. * The potential with abuse here is not negligible, but uncomfortable with ICANN determining what is commercially feasible for a contracted party. * Suggest doing a copy/paste including demonstrate with commercial and technical feasibility (without the DPIA clause) * Do not know why we are adding commercially and technically feasible * Could live with determine for legal feasibility, but the technical/commercial, it needs to be demonstrated due to the subjective nature of this For implementation purposes, how would the CP demonstrate this is not technically and commercially feasible, who would they demonstrate this to and how? * For clarity, if a Contracted Party demonstrates that automated processing of disclosure decisions for the use cases specified in this recommendation or through the processes detailed in Recommendation #19 is not commercially or technically feasible, the Contracted Party MUST notify ICANN Org it requires an exemption from automated processing of disclosure decisions of the identified use case(s). * The technical and commercial feasibility is determined in 16.3 and in Rec. 19 – do not agree to adding this paragraph. The CP would need to demonstrate this to ICANN. * Couple of issues to address: the technical feasibility needs to go – it will be technically feasible full stop. For commercially feasible – before we can agree that there is some reason for it to be NOT commercially feasible, there needs to be guardrails * Do not think we should make a determination now over what would be technically or commercially feasible * Have a problem with a unilateral determination of commercial feasibility. Smaller registrars in developing countries may have commercial issues. Could we create a special exemption based on economic hardship in developing countries? * Can the group live without 16.4bis? * Do CPs really need exemptions for commercial and technical feasibility? * Yes, but we need to find a way so that this is not abused. * Suggest adding in 16.4bis – after contracted party, especially small in size, operating in developing economies * Small in size is not a guardrail – how small? How is that defined? How is developing economy defined? If you can’t do this, it’s a key part of the DNS, so you can’t be a registrar. Cannot live with this as is. Alternative proposal is to deleted 16.4bis. * Small registrars have the option of automating this – they could voluntarily ask the CGM to automate decisions for them. * Small in size is not the right number. Not sure how to close the gap between now and the day where someone releases an opensource AI. * CPS may or may not automate their own decision processes on whether to disclose. Thought we were talking about disclosure when SSAD has made the decision. * 16.5 * All that CPs are asking for a path or open door – what about through implementation and allowing for the opting out of edge cases and remove 16.4 * For 16.5 – if this is for a legal reason, this would be the only way to do this * Question from ICANN org – the language in 16.6 seems to contemplate a notice and comment process – regarding the supporting information, what is the supporting information? * If a CP determines that there is a legal impermissibility, they have to provide the supporting documentation. * MUST the DPIA be included for public comment? * The CP needs to provide the documentation that led them to determine that there is a legal issue. * Concerned about the language in this exemption, particularly the language regarding DPIA. This sounds like a WHOIS Conflicts procedure. There shouldn’t be a DPIA to stop disclosing. All the CP needs is short text with a sound argument as to why it can’t release the data. Do not need to overcomplicate this. If ICANN org is willing to perform a mediation process, that is fine – but have to remember that the burden is on the CP to comply with law. * "Supporting documentation" that is, what information supports the claim that the automation is no longer legally permissible. * This only kicks in if a CP exemption is challenged – goes to reason that CP that sought the exemption has their supporting rationale, and the CP would provide the supporting information as part of the process in 16.6 * If input needs to be replaced by supporting information, that could be helpful. * This language leaves out important questions – must the CP provide the supporting information to ICANN – may ICANN publish it? Can the Rr mark it as confidential? What if the parties cannot come to agreement, then what happens? * For 16.6, instead of input, say supporting documentation. Add further details will be developed during the implementation phase. * Affected stakeholders want to see the supporting documentation, but there is no clarity on whether ICANN org can publish this or share it with affected stakeholders. * Consider adding in case of challenge, ICANN must provide notice and comment process. * ICANN providing a notice and comment process is how affected stakeholders would become aware of this. * Intent under 16.4, and this may not have been clear enough, as part of notification, supporting information would be provided. There may need to be questions worked out in implementation regarding confidentiality. ICANN received this notification, for these reasons, are there concerns with this? * MUST the info be presented to ICANN, can it be marked as confidential, must it be published, how would disputes be resolved? Need further information. * Could this be sorted out in implementation? * Helpful that it would be published and there would be an opportunity for comment. If everything is left to implementation, this would be a years-long process. * Regarding changing input to supporting information – this change was likely made in error. Supporting documentation is more restrictive than input * In 16.4, make clear that notification to ICANN org also includes supporting information and move 16.6 back to its original state * 16.7 * No issues. * 16.8 * Last sentence of 16.8 – what is subject to review? What action could be taken by ICANN org in response? * This last sentence should be separated from 16.8 * 16.8bis “Unreasonable notifications may be subject to review,” * As a structural drafting matter – this probably belongs higher and attach onto 16.4. The MAY language needs to be changed. This is an exemption to ICANN Consensus Policy – language “ICANN Compliance MUST review exemption notifications” * How is ICANN to make a determination on what is a reasonable exemption? * ICANN Compliance should be ICANN org to allow more flexibility * Under what circumstances would a review take place? * Based on this policy, it’s not clear what ICANN is to do if an exemption is unreasonable? * How does ICANN enforce this? This is enforced by ICANN Compliance. * ICANN org MUST reverse the exemption if it is found by ICANN to be incorrect, abusive, or no longer applicable. * This will be added to 16.4 * 16.9 * No issues. * 16.10 * No issues * 16.11 * Delete footnote 3 when 16.11 is endorsed * Instead of 16.4bis, consider: add a footnote in 16.3 where it says ‘commercially’ that says something like: “During implementation, further consideration will need to be given to the commercial feasibility for registrars that may receive a very limited number of requests that will meet the criteria for automated processing of disclosure decisions and whether the financial burden of enabling this automated processing is of such a nature that an exemption may need to be provided. As part of this consideration, the CGM also should consider how it can facilitate the integration of a CP’s system with the SSAD to reduce any potential burden of automated processing of disclosure decisions.” * Is this footnote acceptable to everyone? * All can live with this. * It is conceivable that we have use cases but they can only be automated with human intervention at the SSAD. Propose the following text: "The SSAD MAY use human review for any automated SSAD decisions, but there may be specific classes of disclosure requests approved for automation where human review MUST be included" – proposed footnote to 16.11 * ALAC put in a comment that the SSAD should allow for centralized decisions – 16.11 said which may involve non-automated review at the central gateway. The SSAD could make a decision, but there must be human review at the SSAD. Not saying they will do this, just allowing for it * Do not read 16.11 for the CGM to involve itself in the automated disclosure or intervene in the disclosure process itself – the above-proposed footnote for 16.11 is confusing * The confusion here may be over the word “making a decision”. For use case on UDRP verification, the legal guidance said there is a legal effect on data subject, so it cannot be automated. Maybe a way to address the concern – could the CGM see that there is a legitimate request and since the CGM confirmed the criteria are met, but by allowing a human to review whether the criteria for automation have been met, but the disclosing of the data is directed and automated. * What is confusing is we are not actually spelling out who is accountable for the disclosure decision in these hybrid decisions. At the end of the day, this needs to be decided in controllership agreements. The relevant question – who is the controller that made this decision, and does it require intervention from the contracted parties * Expectation – there could be personal data transferred as part of this * This is not a prohibition, but it is the expectation. * This was added for a concern by contracted parties – it’s a MAY and there is nothing from prohibiting a CP from sending over personal data * Implementation guidance – remove parenthetical in first paragraph (no human intervention) * Support Staff to number the implementation guidance * If the use cases move into policy, this could complicate Rec. 19 * When the conversation happens on particular use cases, the responsible parties would need to say yes or no * Leave it to Contracted Parties until there is definitive guidance the CGM would be solely liable * The purpose of the mechanism is to address this – this language makes it seem that one party can decide on its own outside of the mechanism. The mechanism is intended to look at the law, determine if there is a use case for automation, and if the CPs agreed as a whole, that would stand. * Seem to be batting the automation issue b/w Rec. 16 and Rec. 19. Automation rec says if it meets the requirements, it must be automated * 16.4 is about individual contracted parties believing something is not legally permissible * This language was added what is legally permissible and by whom * Does anyone object to leaving the language as is? * No. * Should 6(1)(e) automation be taken out? * GAC reps asked for this inclusion – 6(1)(e) lawful basis – this was accepted by the rest of the team * If this part of the policy, should specify that we’re talking about GDPR c. Confirm next steps 5. Continue run through of yellow items [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> (items identified for further discussion / clarification) a. Consider yellow items identified for recommendations (continuing with rec #15 and moving down the list) * Suggest going to Rec. 8 * Alternative language provided for Rec. 8 * Team has decided that it’s up to the CP to determine the request – the new language is confusing. What is Compliance supposed to do exactly and how is this supposed to work * Wanted to preserve a roll for ICANN compliance to investigate disclosures from a single entity that are problematic * ICANN org – ICANN compliance can only enforce what the policy says, and the policy just says to evaluate – what is compliance supposed to do about that? * Conflict b/w first and second sentence – if you can’t do the first sentence, you can’t do the second sentence. * There are plenty of things ICANN Compliance can do in terms of metrics * If a reporter makes requests of a similar nature, and one registrar always accepts them and another denies them, Compliance could ask for a reason of how you did the balancing test. * There are some things in the recommendation that compliance should be able to act on request is denied solely based on x, for example * Concerned that the language that is highlighted is of two minds – will not address the merits but will address unreasonable denials * Could ICANN enforce MUST provide reasonable access? Would it help if the language is updated to say “typically” * MUST provide access where reasonable instead of must provide reasonable access * Proposal to accept Laureen’s proposed updated language * Recommendation 2, Accreditation of Governmental Entities – 86 suggestion from ICANN org to replace data controller to relevant contracted party or Central Gateway Manager, or applicable * OK with this change. * Item 87 – footnote that says IGOs and how they could get accredited. * Would the current wording allow for the host to accredit the IGO? * Next list of items deal with Logging Recommendation * Are identity providers required to log, or is this something that could be determined in the implementation phase? * Leave as is. * Isn’t the general category of denial sent to the gateway and the requestor under Rec. 6? * Item 82 – question for the BC – change that was made that says disclosure decisions including a written rationale must be stored. Is written necessary? * Concern can be addressed now that rationale = reason for decision b. EPDP Team feedback c. Confirm next steps * All other yellow items should be handled online – provide written input and focus on what you “cannot live with” that needs to get addressed in the report. 6. Wrap and confirm next steps (5 minutes): i. 5 July: distribution of updated draft Final Report. ii. 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). iii. 14 July: tentative EPDP Team meeting to address any issues that may require EPDP Team input / guidance. iv. 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. v. 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. vi. 24 July: deadline for minority statements. vii. At the latest by 31 July: submission of Final Report to the GNSO Council