Dear All,

Below, please find notes and action items from today’s EPDP Team Call.  

As a reminder, our next meeting will be Tuesday, 18 September, 13:00 UTC.

Best regards,

Marika, Berry, and Caitlin

EPDP Team Meeting #13

13 September 2018

High-level Notes/Action Items

Please complete the IT Governance GDPR Training Course by Tuesday, 18 September.

A GDPR Q&A session with Becky Burr will be held on Wednesday, 19 September at 13.00 UTC. If you have questions and/or topics you would like Becky to address, please submit questions via this document: https://docs.google.com/document/d/1QBy9YhdoaQ2yBmPicUSJai9YaNPZWrRywFJVlJAF_Ms/edit?usp=sharing.

The EPDP Leadership Team is putting together an agenda for the F2F meeting, and the preliminary schedule will be published early next week - if anyone from the EPDP Team would like to provide ideas or suggestions, please feel free to do so via the list.

The team should have received an email regarding the engagement of CBI for mediation services. CBI will be present during the F2F meeting in Los Angeles to assist in moving the team forward.

Please remember to provide further comments on §4.4 and Thomas and Benedict's purposes classification by Friday, 14 September.

Thomas Rickert will further develop the data elements matrix based on today’s discussion.

ICANN Support Team will create a distribute Google docs to allow members to work on answering the issues addressed for Appendix A, §§2.1 - 2.3, Appendix A §2.4, Appendix A §1, Appendix A, §4. The EPDP Leadership Team is looking for a small team of volunteers to work on this.

Notes & Action items

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/2IpHBQ.

1. Roll Call & SOI Updates

• Attendance will be taken from Adobe Connect
• Please 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 (5 minutes)

• Reminder to complete GDPR Training Course by Tuesday, 18 September
• Reminder of GDPR Q&A session with Becky Burr on Wednesday, 19 September at 13.00 UTC
• Leadership Team is putting together an agenda for the F2F meeting - the preliminary schedule will be published early next week - if you have ideas, please let the leadership team know
• The team should have received an email regarding the engagement of CBI (for mediation services)
• With respect to action items, please take note of the impending due date (Friday, 14 September) for comments on §4.4 and further comments on Thomas and Benedict's purposes classification by Friday, 14 September.
• Other updates, if applicable

Action item #1: If anyone from the EPDP Team would like to provide ideas or suggestions for the F2F in Los Angeles, please feel free to do so via the list.

3. Review data matrix formed from RDS work and Thomas’s chart (50 minutes)

Objective of discussion: Charter questions b1 and b2 (collection of data by registrar) to be answered (or considered) in substantive discussion

1. High-level overview of chart

• This document brings together Thomas's chart with work the RDS Team worked on. In the first column on the left, all data elements that are currently required, including non-WHOIS elements, appear. The second column are registry, registrar or contract purposes. The rationale column is to be used to provide rationale to the data elements.

• The two tables complement each other. During the last call, we discussed the purposes and who is pursuing the purposes. What we are trying to do now is to look at operational steps between the registrar and the registrant - what data can be collected by the registrar. We are not talking about passing on data to the registry or questions related to the disclosure of the data.

• The first step is to analyze what data the registrar requires to fulfill the contract. The outcome will be a table what data will be collected to perform the contract vis-a-vis the registrant.  Secondly, what data can be collected for a third party.  Art.6(I)(f)

• For the focus of this call, let's focus on what needs to be collected by registrars to perform the contract. Column A of the document shows all of the data elements ICANN requires to be collected.  Some of the elements may be out of scope for this EPDP, but they are included for the sake of comprehensiveness.

• Question for discussion: does anyone object to the data being collected to perform the contract?

• To execute the contract b/w a Rr and Rt, it's not necessary to collect any of this data. Even if we focus on registrant records as required, a lot of these that are mandatory should be moved to optional (fax number, for example). Because of the confusion on how organization is displayed, many natural persons retype their names, and that creates complications.

• Some fields are marked as optional. A radio button for asking for natural person/legal person declaration could be helpful. 

• If you think about the registrar role, the registrar does not dictate what goes into the registry. There are policy reasons for some of this data. ICANN Staff should go back and look at the RAA and Consensus Policy and see what is required to be collected.

• Perhaps it would be helpful for members to denote which fields should be optional into the chat.

• For the distinction b/w natural and legal entities, that is a discussion we need to have. 

• With respect to the contract, the data elements in Column A should represent what Margie has suggested in terms of contract and consensus policies. The mere fact that these elements appear in another document does not de facto mean that it is lawful to collect the data.

• It might be helpful to distinguish optional vs. mandatory by denoting optional data in a separate column.

• The legal bases under the ICANN contract and third party legitimate interests are all tied together.

• What data elements are required for a domain name registration to work?

• The word optional should not be construed as consent and should be identified separately.

• Other than a few elements such as domain name servers, there is nothing collected in WHOIS for the registrar or registry to do their business.

• The meta question being raised with the respect to the data needs to be resolved. In some sense, the ICANN process is the equivalent of an ownership title for the domain registrant.

• Are we discussing the contract b/w Rr and Rt, or are we talking about the whole contractual framework, and if so, how can we define the third party legitimate interests? 

• We are trying to focus on what data is required to perform the contract with the registrant.

• The fundamental confusion of the group is that we are merging ICANN's purposes with the Rr/Rt contract. The team is necessarily confused because the group has not agreed on the parameters of what we're doing. This problem is not being approached in a logical way. An example: escrow data.  Many things are out of scope in this discussion, but from the pure purpose of registrant rights, we have escrow data.

• The EPDP Charter is broad enough to allow us to deal with all data collection. We are here to discuss what elements that are currently in the contract that should be used in the future. While we have an aversion to invoking third party requirements, virtually nothing in WHOIS is necessary for the registrar.

• Who is the controller for purposes of this discussion?

• We are going to determine the controller decision later.

• Is there any opposition to leaving the data elements for the Rt as they are with the elements marked optional as they are with the qualification that we need to find a solution for a demarcation b/w natural and legal persons.

• Why do we need all three - phone, fax, and email?

• The premise that none of this data is needed to perform the registrar-registrant contract does not seem correct. In terms of what data elements are not necessary - you do not need a phone number or a fax number, particularly when we're talking about many people not having one. Are we also getting to technical and administrative contacts?

• Why do we need to have a philosophical discussion over whether fax should be provided?

• If the Team can agree on an approach for how to deal with existing data elements, that would be helpful. The Temp Spec took the approach of not adding new or removing existing data elements, and the Temp Spec specified elements that in certain circumstances would not need to be displayed in RDS.

• Is it important to rename the name and organization fields to better reflect natural and legal persons?

• It appears there is some traction to rename name and organization as data elements.

• For street, city, postal code, these are uncontroversial.

• Shall the phone number data element be kept as it is? There is a divergance on the requirement for the phone data element.

• Do you agree that the phone extension should be kept as it is (as optional)? Most want to keep it.

• Shall the fax be kept as optional? There is divergence on this point.

• Should the fax extension be kept as is? It appears most members would like this deleted.

• For members asking that phone numbers need to be retained, please give the reason since phone numbers can be abused.

• Shall we ask staff to propose a rationale as to why these elements might be needed?

• Tick marks do not give a rationale as to why these data elements may or may not be required. Additionally, counting tick marks is not appropriate since there is unequal representation within this team.

• This topic starts to wade into the diversity of registrars and how they serve their customers. There is a high degree of duplication or redundancy. The data minimization principle would ask why the information is being collected that is a duplicate. Some registrars, however, do use admin/tech contact.

• We could say that if there were to become optional, they could be submitted only when they are different than the registrant contact.

• It would be helpful to hear from registrars who use these contacts what the rationale is.

• We should differentiate whether a field is optional and whether entry to a field is optional.  How we treat optional is critical in these types of cases.

• Whose policy are we setting here with respect to mandatory or optional?

b) Discuss proposed amendments to chart

c) Note: relevant charter questions:

b1) What data should registrars be required to collect for each of the following contacts: Registrant, Tech, Admin, Billing?

b2) What data is collected because it is necessary to deliver the service of fulfilling a domain registration, versus other legitimate purpose as outlined in part (A) above?

d. Agree on next steps

4. Introduction to Appendix A (50 minutes)

Objection of discussion: Charter questions f1 - f3 (publication of data by registry/registrar) to be answered (or considered) in substantive discussion; EDPB advice re: collection of full WHOIS data and registration of legal persons to be considered in substantive discussion.

In App. A discussion, we were going to focus on priority 1 and 2a items (the items we need to sort through in our initial report).

Action item #2: ICANN Support Team to create Google docs to allow members to work on answering the issues addressed for Appendix A, 2.1 - 2.4.

a) Substantive discussion on §§2 – 4

b) Note: relevant charter questions:

·           f1) Should there be any changes made to registrant data that is required to be redacted? If so, what data should be published in a freely accessible directory?

·           f2) Should standardized requirements on registrant contact mechanism be developed?

·           f3) Under what circumstances should third parties be permitted to contact the registrant, and how should contact be facilitated in those circumstances

c. Agree on next steps

5. Confirm action items and questions for ICANN Org, if any (5 minutes)

6. Wrap and confirm next meeting to be scheduled for Tuesday 18 September at 13.00 UTC.