Dear All,

Below, please find notes and action items from EPDP Meeting #36 below.

Thank you, and happy holidays to all!

Best regards,

Marika, Berry, and Caitlin

--

EPDP Team Meeting #36

20 December 2018, 1400 UTC

High-Level Notes/Actions

1. Alan Greenberg, EPDP leadership and staff support team to review input received in reference to and produce updated version for handling data of proxy registrants and data in privacy registrations for EPDP Team review on the mailing list.

2. Kurt and Kristina to compile additional parameters and information necessary for ICANN org to begin the procurement of external legal counsel.
   
   
3. There was a discussion concerning the potential collision between the ongoing discussion of EPDP issues and the comment period currently underway - and in particular the risk of continuing EPDP discussions before the comment period is closed and comments are read. For the benefit of the EPDP team and the DNS community, nothing discussed in the meetings prior to the closure of the comment period will obviate the full consideration of comments in the formulation of the final report.

These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ.

1.      Roll Call & SOI Updates

• Attendance will be taken from Adobe Connect
• Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes.
• Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team.

 2. Welcome and Updates from EPDP Team Chair

• Review of outstanding action items
• Other updates, if applicable

• Use today's meeting to review proposed language in relation to some of the issues that have been under discussion
• Note to be sent to the GNSO Council later today in relation to status of letter to EDBP letter - no letter sent at this point in time, to be further considered by EPDP Team at later stage.
• Reminder, public comment forum will close on Friday 21 December at 23:59 UTC.
• Important to avoid repeat comments during meetings - need to wrap up when all points have been made.
• Need to consider how to effectively review public comments. How to assess whether comments have sufficient background / rationale to trigger re-examination? Not dependent on who puts forward the comment, but based on the substance / rationale. Staff and leadership will be working on a public comment review tool to facilitate review of public comments. No small team in place at the moment or foreseen to review comments. Note that submissions, including names and affiliation, can already be reviewed here: https://docs.google.com/spreadsheets/d/1GUf86Ngo97g74wLyDmeBv8lGcUtjLJWjsEdxBXcYDD4/edit#gid=694919619.   

3. Continue review of list of topics for further discussion: in today’s meeting we will review potential wording developed from previous discussions for certain Temp Spec / Policy Recommendations to assess where there are areas of agreement.

• Privacy/Proxy Services - how the P/P records appear in the public WHOIS (review of language developed in previous meeting)
• The EPDP recommends that in the case of a domain name registration where a Privacy/Proxy service, offered or made available by Registrar or its Affiliates in connection with a registration is used, (e.g. where data associated with a [Privacy/Proxy customer] is masked), Registrar MUST return [unredacted data] in response to [RDDS] quer[ies], including the existing privacy/proxy pseudonymized email.
• Note: bracketed wording references suggestions from James and Marc A.
• Language was developed during previous meetings, bracketed wording references suggestions for changes that were shared on the mailing list by James and Marc A.
• Whatever language is agreed to needs to work once PPSAI is implemented as well as today's world. PPSAI recommends that to the extent feasible P/P registrations need to be clearly labelled in WHOIS. No need to do PPSAI's work, but future-proofing recommendation is important.
• If there are further suggestions on how this language can address both the current situation as well as the expected future state, please share those with the list.
• Is the implication of this recommendation that underlying customer information would be revealed? P/P is registrant of record, so P/P information would be displayed, not underlying customer information. Consider clarifying this in the text so this is clear.
• Will still need to consider whether publication of data is considered personal data as not all P/P may be using anonymized data. This puts CPs at risk if this data is published in a blanked manner, some caution may need to be exercised.
• Also need to factor in difference between privacy and proxy providers. Privacy registrations are under the name of the registrant, while contact info is P/P provider. For proxy providers, all the info provided is P/P. So for privacy registrations there would be personal data involved (registrant name).
• Could this be addressed by just stating privacy/proxy service, on the assumption that they would self-identify now, and required identification following PPSAI implementation.
• Different proposals made during the call, to be further considered. Alan Greenberg to take first stab at bringing these different versions together.
• Action item: Alan Greenberg, leadership and staff support team to review input received and produce updated version for EPDP Team review on the mailing list.

Consent by the Registrant to Publish and/or Disclose for technical contact

• Current language in Temp Spec, Section 7.2.1/ Appendix C – Section 2.3 contains this requirement: Registrar MAY provide the opportunity for the Admin/Tech and/or other contacts to provide Consent to publish additional contact information outlined in Section 2.4 of Appendix A.
• Margie to introduce issue: Whether registrars should seek consent from those listed as additional contacts (admin/tech) to having their information as reflected in the Contact data be published rather than be redacted. This is an issue that would be available to both natural persons and legal persons.
• Proposed outcome: confirm this requirement [IPC/BC/SSAC support confirmation.]
• This may be a question for legal counsel as there are questions around what can be done, what contractual arrangements would need to be taken to make this GDPR compliant. Not sure that it is possible to come to agreement on the information that is currently available.
• Art 14 of the GDPR would need to be considered (information provided that is not from the data subject) - would be helpful to get further input on how this article may apply. Would registrars need to obtain consent from tech contact? What happens if consent is withdrawn ? Does 14.2.d mean that consent is to be obtained in the first place?
• EDPB letter made it clear that if a registrant that uses someone else's data, they would need to 'inform' that person. Need confirmation that this obviates the consent requirement as well as liability.
• Note that current language says 'MAY' - so it is up to registrars to determine whether necessary measures have been taken to do this in a GDPR compliant manner. Does not impose any new requirements, but allows registrars to offer this as a service. Absent this recommendation, it is still possible for contracted parties to offer such a service?

• There may be a data field to show appropriate consent was given, but this may not be possible within this framework of the EPDP.
• In the EPP, Section 2.9 - you can attach contact disclosure fields to each field. The format for data escrow does not include disclosure preferences, but because this is based off of EPP, this would be possible.
• If we took this language out of the Temp Spec, registrars would not be barred from getting appropriate consent and publication - should we let the market decide?
• Should this question be put to the legal team?

Geographic Differentiation

• Discuss proposed draft recommendation (see attached document)
• Discussion, next steps
• Talked about two things 1) Clarification from EPDP did not apply to our situation  2) could work with outside counsel or DPAs.  Even with clarity, we're still confronted with a complex situation.
• Postulated rules engine, or at least initial research in how it might work; or some preliminary study.
• Until we figure these issues out, the work required might take longer that the time the EPDP has.
• Point of order - these two issues (Geo & Tech Contact) are out for public comment and these discussions may impact/conflict the input received. [Attempt to recap conversations and see where we are as this was identified as an outstanding issues after the Initial Report]
• Who is in charge of language to the EDPB - differing viewpoints should be captured. What is the question and what is the scope of the clarification?
• The answer to this hinges on external advice. If we can rely on the registrant to certify that the information is accurate and belongs to them and they have sought consent, we should be able to rely on the country the registrant provides. We cannot have this discussion until we solve the first problem.
• Rules engine is not a commonly-understood term. Perhaps not all EPDP Team Members have the same understanding of what a rules engine is. A rules engine could just be a flowchart on a piece of paper. It could also be coding or software that makes decisions based on input it receives, and these are separate and distinct things.
• While it is called a rules engine, it is a flowchart concept, factoring in various factors (such as location) and determining which rules apply. This should be done by ICANN in consultation with legal counsel.  This is not a unique situation to the domain industry.
• From the EWG Final Report: More specifically, “rules engine” refers to a feature that could be implemented within the RDS to manage (a) the storage, collection and processing of domain name information based on Registrant, Contact, Registrar, Registry, and RDS jurisdictions (represented by the following data elements: Registrant and Contact Country Code, Registrar and Registry Jurisdictions), and (b) data protection laws of the applicable jurisdictions, in accordance with ICANN's future defined policy for the RDS.
• Things may have changed since the first postulation of the rules engine, so attention must be paid when building this.
• The Initial Report is out for public comment, so there are no major contributions we can make until we take into account the public comment. Caution the team against trying to push any new decision on critical questions we are asking the public to comment on.
• The rules engine could start with a flowchart, but this could be unwieldy and unmanageable as things change. There are a few ways to implement something like this in a practical fashion.
• What this language is intended to convey is that the language as written is that its at the discretion of the registrar when to differentiate geographically until such time as an authoritative body relieves the registrar of the liability or until such time as a rules engine relieves the risk.
• Summarizing at this point may dangerously undermine the public comment process.
• Rules engines are as much of an implementation issue as imaginable.
• This is not within our scope and is an implementation issue. While the EWG was in favor of a rules engine, this is work of an IRT to implement this. A solution presented the EWG was binding corporate rules (BCRs) – it’s easier to make exceptions to comply with local law and operate from there. I thought the group agreed that is not possible for the contracted parties to differentiate?
• The rules and policy that are going to used to feed this algorithm are going to be used by the rules engine are definitely within our scope. What are the rules that will direct how this algorithm will work?
• We do not know, and the determination of that will exceed our time limit, so we should think about in our future deliberations how we will address must vs. mays and what requirements should be and should not be.

First meeting of the legal team

• Team is staffed with Kurt and Rafik as chair and vice-chair, Leon as the board liaison, Diane, Margie, Tatiana, Kristina, Laureen, Emily, Hadia, Benedict, Thomas, Dan Halloran
• The majority of the meeting was spent discussing processes. Some topics discussed were how questions are raised to this team. The Team will hone questions put forward by the EPDP Team. How will the Legal Team report back to the whole team? We also discussed working methods – email vs. teleconferences and how to answer questions – is there previously received advice, or are there questions that can be answered without going to legal counsel? The next call is scheduled for 2 January 2019.
• There are three EDPB questions and volunteers will begin honing the questions independently.  In the meantime, ICANN will undergo its procurement process for outside legal counsel.
• Has the team decided on what type of attorney/law firm the group wants to proceed with? ICANN org needs more detail before it can begin the procurement process.
• Kurt to clarify additional details necessary to begin procurement process.

4. Wrap and confirm next meeting to be scheduled for Thursday, 3 January 2019 at 14.00 UTC

Confirm action items

Confirm questions for ICANN Org, if any