Trying this again with the Council List as a CC. From: John McElwaine Sent: Monday, March 16, 2020 1:02 PM To: Drazek, Keith <kdrazek@verisign.com> Cc: gnso-secs@icann.org Subject: RE: [council] Seeking guidance for EPDP - Follow up from Council Meeting and Next Steps Dear Keith, and GNSO Councilors, Thank you for kicking off discussion on this issue. The IPC agrees with the background you set forth and the importance and complexity of this topic. However, instead of another small group to be formed later to address this issue, the IPC believes that the issue of data accuracy is properly within the scope of the EPDP[1] and should be handled by a EPDP small team. Data Accuracy is a fundamental requirement under GDPR Art. 5 and accuracy is woven into the Temp. Spec. that the EPDP was chartered to assess (see Temp. Spec. language below). Moreover, the EPDP should also continue its important work on accuracy because programs such as ARS are critical, not only to the security, stability, and resiliency of the DNS, but also to the concept of data controllership which is also critical to contracted parties’ liability under GDPR . As such, the GNSO Council should continue the engagement with ICANN org on data accuracy. In the interest of clarity, the IPC notes that the only remaining legal question being considered by the EPDP is to clarify ambiguity in previous advice<CallRail%20will%20produce,%20all%20known,%20non-privileged%20documents%20in%20its%20possession%20responsive%20to%20this%20request> received from Bird & Bird. As such, the IPC believes that the accuracy question of RDS data can and should be addressed by the Phase 2 EPDP team as soon as possible. To accomplish this, we recommend that an EPDP small team be formed to work on new language to be included in the EPDP’s Final Report. We note that some may assert that “time is running out” and that any work not completed by the end of June, when the GNSO funding runs out, will not be addressed. The IPC is confident that the current work on accuracy can be completed swiftly, and rejects artificial deadlines that may curtail this important work or attempts to close the EPDP before it completes the work plan as outlined and defined in its GNSO Council approved charter. Finally, we should not enter this task believing that additional budget is not available for this important work. To the remaining question pertaining to ICANN org and ARS, the IPC notes that the concept of accuracy related to ARS actually underpins the open question of controllership of RDS data at issue in the EPDP. In this regard, the IPC considers ICANN org’s response to be an attempt to diminish its own controllership over RDS data, thereby attempting to limit its own liability. The concept that a data controller would have difficulty in accessing data under its controllership is an absurdity of ICANN’s own creation. If ICANN actually intends to undertake the controllership role it has stated it is willing to accept, which role would diminish liability for contracted parties (and which appears desirable for the entirety of the GNSO), the GNSO should challenge this apparent abdication of responsibility by ICANN org. As a data controller, there is no question that ICANN org should be able to access the data it needs for its own purposes, including its important ARS work. Accordingly, the IPC encourages our GNSO colleagues not to view data accuracy as an obligation for contracted parties, nor as a risk for at-risk data subjects, but rather as an opportunity to allocate appropriate controllership to ICANN org where it belongs. Kind regards, John and Flip ___________________________________________ [1] Data Accuracy is Within Scope Data accuracy is important and, inf fact, European Commission representatives commenting upon ICANN's proposed GDPR-compliant WHOIS models made it clear that “personal data shall be accurate and kept up to date. Every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (retroactive database data correction with regards to the factual data situation found out during the investigation). To comply with the data quality principle, reasonable steps should be taken to ensure the accuracy of any personal data obtained.” This point was stressed by Georgios Tselentis, a representative of the GAC from the European Commission, on the EPDP call of March 12, where he reminded the team that under the GDPR accuracy was not an optional concept but one that was critical to ensure legal compliance with the GDPR. See https://community.icann.org/pages/viewpage.action?pageId=126419071 Temp Spec Language (link<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...>) There are several references to data accuracy in the temp spec. Section 4 that describes the lawfulness and purposes for processing gTLD Registration Data. Section 4.1 references the bylaws and explicitly states ● maintenance of and access to accurate and up-to-date information concerning registered names and name servers; Section 4.3 also references the bylaws and the need to facilitate 3rd party processing of registration data and the ICANN requirement to "use commercially reasonable efforts to enforce its policies relating to registration directory services," including by working with stakeholders to "explore structural changes to improve accuracy and access to generic top-level domain registration data," "as well as consider[ing] safeguards for protecting such data." Section 4.4 outlines the ICANN purposes for processing the data including 4.4.2. Providing access to accurate, reliable, and uniform Registration Data based on legitimate interests not outweighed by the fundamental rights of relevant data subjects, consistent with GDPR; Finally, Appendix C on Data Processing Requirements defines ICANN, Registries and Registrars as controllers for various processing activities. It also defines a list of "Principles for processing" for those controllers. 1. Principles for Processing Each Controller will observe the following principles to govern its Processing of Personal Data contained in Registration Data, except as required by applicable laws or regulations. Personal Data SHALL: [........] 1.4. be accurate and, if necessary, kept current, as appropriate to the purposes for which they are Processed ("accuracy"); EPDP Phase 1 Final Report (link<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_de...>) Despite the lack of specifics in the charter, the final report references accuracy in several places. EPDP Team Recommendation #4. The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy. [6] footnote [6] states The topic of accuracy as related to GDPR compliance is expected to be considered further as well as the WHOIS Accuracy Reporting System. In the SSAC group statement in Appendix G: "A vital ICANN policy is the accuracy complaint process, where third parties have the right to submit data accuracy complaints, and registrars and registrants must respond per the requirements. The accuracy complaint process has been a vital accountability and compliance mechanism that has helped stop and prevent numerous serious abuse and security issues. " From: council <council-bounces@gnso.icann.org<mailto:council-bounces@gnso.icann.org>> On Behalf Of Drazek, Keith via council Sent: Thursday, March 12, 2020 6:34 PM To: council@gnso.icann.org<mailto:council@gnso.icann.org> Cc: gnso-secs@icann.org<mailto:gnso-secs@icann.org> Subject: Re: [council] Seeking guidance for EPDP - Follow up from Council Meeting and Next Steps ◄External Email► - From: council-bounces@gnso.icann.org<mailto:council-bounces@gnso.icann.org> Hi all, As a follow-up to Rafik’s 6 March email (below) and our brief discussion during yesterday’s Council meeting, I’d like to share my current thinking and propose a path forward. If anyone has views to share, please do so now; the EPDP Phase 2 Team needs our guidance in short order. I’ve done some additional homework since yesterday’s call, so I hope I’ve captured everything here accurately. 1. The issue of registrant data accuracy is an important topic that deserves full and thorough consideration, including its impact on GNSO policy, contracted party agreements, and other ICANN processes such as ARS. As such, it is not only a policy issue, and there are likely non-GDPR-specific factors that will need to be considered. 2. The EPDP Team Phase 1 Final Report Recommendation #4 said, “The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy.” The ICANN Board approved this recommendation without further guidance or comment. 3. There is not agreement within the EPDP on the meaning of “data accuracy” in the context of GDPR. There is disagreement over whether it is only from the perspective of the data subject or also third parties? There was a legal memo received during Phase 1 on the topic of data accuracy and a legal question was developed during Phase 2 to help clarify the meaning, but it has not been submitted. 4. The charter for the EPDP did not specify or identify the topic of data accuracy as within scope, but the EPDP Phase 1 final report included a reference to data accuracy in footnote #24. That footnote said: “The topic of accuracy as related to GDPR compliance is expected to be considered further as well as the WHOIS Accuracy Reporting System.” This footnote did not specify that such further consideration take place in Phase 2, but the issue was included in the Phase 2 work plan that was approved by the GNSO Council. 5. During Phase 1, the EPDP Team requested external legal counsel guidance on the topic of accuracy in the context of GDPR, and received the following summary answer: “In sum, because compliance with the Accuracy Principle is based on a reasonableness standard, ICANN and the relevant parties will be better placed to evaluate whether these procedures are sufficient. From our vantage point, as the procedures do require affirmative steps that will help confirm accuracy, unless there is reason to believe these are insufficient, we see no clear requirement to review them.” 6. There is not sufficient clarity at this time on how existing accuracy requirements have been impacted by GDPR. As such, in order to properly consider and scope further work on registrant data accuracy, more discussion is needed among interested/impacted parties, including ICANN Org. 7. The EPDP is scheduled to conclude its Phase 2 work in June with its deliberations on priority 2 items, of which accuracy is one, needing to complete by 24 March at the latest to be included in the Final Report. Furthermore, and there is no FY21 budget assigned for its continuation beyond that time. Under these constraints (time, resources, complexity), our ability to reach a policy solution in a couple of months is highly unlikely if not impossible and could delay delivery of the Final Report on SSAD which has been identified by basically everyone as priority #1. In light of the above, my recommended path forward for the Council and EPDP is as follows: 1. Council acknowledge the importance and complexity of the topic, but also the time and resource constraints noted above. 2. Council will discuss and consider possible next steps, including establishing a small group/scoping team to establish a framework to address the issue of registrant data accuracy across policy/contracts/procedures. 3. Council to acknowledge the possible impact of the data accuracy issue in the context of SSAD implementation and RDDS, and recognize the need to prioritize accordingly. 4. Encourage the EPDP team to submit the pending legal memo to help inform the work of any future scoping team. I hope that strikes the right balance to ensure the work will be done, while giving the community space and time to approach the issue holistically and to carefully develop any needed policy recommendations. I shared this with Rafik and Pam and we are in agreement. We were asked to respond by Friday the 13th, but that doesn’t leave much time for feedback, so please respond by 11:59 UTC on Monday 16 March. This will allow us to deliver our reply to the EPDP Team prior to their Tuesday call. Thanks, Keith From: council <council-bounces@gnso.icann.org<mailto:council-bounces@gnso.icann.org>> On Behalf Of Rafik Dammak Sent: Friday, March 6, 2020 6:32 PM To: Council GNSO <council@gnso.icann.org<mailto:council@gnso.icann.org>> Subject: [EXTERNAL] [council] Seeking guidance for EPDP Hi all, I am sending a request from EPDP team chair asking guidance from GNSO council regarding WHOIS accuracy. There was disagreement within the EPDP team if the topic is within scope or not. So we would like to get from council guidance regarding its expectations on WHOIS accuracy issue in phase 2 and if the EPDP team is expected to deliberate on it or not asap, taking into account the GNSO council and ICANN org ongoing correspondence<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_system...> on the matter. The EPDP team chair asked that GNSO council can provide guidance by Friday 13th march so that the EPDP team will have time to receive further guidance from the external legal council (if applicable). The time constraint can be also explained that EPDP team is currently deliberating priority 2 topics during the initial report public comment period. Best Regards, Rafik Confidentiality Notice This message is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is proprietary, privileged, confidential or otherwise legally exempt from disclosure. If you are not the named addressee, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this message in error, please notify the sender immediately either by phone (800-237-2000) or reply to this e-mail and delete all copies of this message.