Content Comparison

Notes/ Action Items

EPDP Meeting #15 Notes

Thursday, 20 September 2018

High-level Notes/Actions

Notes and 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 (2 minutes)

• 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 (5 minutes)

3. Review and discuss draft agenda for EPDP meeting in Los Angeles (30 min)

Objective:

• To obtain input on the agenda and a common understanding of the objectives of the meeting.

• To discuss a routinized way of discussing topics since there will be elements of repetition in discussing many “purposes,” many data elements, and so on.

EPDP Team feedback on agenda:

• We need to work through the various processing steps and assess the legality of each.  The bullet points and agenda need more granularity. Farzaneh and Thomas put together a data processing/lifecycle matrix that could be helpful in this regard.

• Should accuracy of data be added to the discussion?

• Instead of deciding if an "x" should be placed on a purpose, we should use the updated registrar text on purposes for the registrar column and give homework to the registries to draft purposes text for their columns for processing. For ICANN purposes, it was suggested that Dan assist with the ICANN purposes.

• Important to have Dan Halloran or others from ICANN org as a vocal participant in the meeting.

• Is it possible to discuss what victory for the EPDP Team would look like on today's call rather than at the F2F?

• We have to first do legitimate purposes, then we have to relate them to data elements, then we have to agree on redaction and retention. If we include these in the initial report, would anyone disagree that these required components would be victory?

• Can processing activities be added to these bullets so they are not forgotten during the discussion?

• Concerns about using CBI.

Action Item 1: ICANN support staff to distribute Thomas and Farzaneh's matrix.

Action Item 2: Capture Alex's methodology and distribute via email.  

Action Item 3: Reach out to ICANN org and note the request for active participation from EPDP ICANN Org liaisons and ICANN compliance staff during the F2F.

Action Item 4: Leadership team to further refine the F2F agenda based on today’s feedback, including adding a column for UTC times.

4. Continue with purposes matrix to complete discussion of purposes §§4.4.11 – 4.4.13. (30 min)

• During Tuesday’s meeting, we reviewed the sub-sections where team comments added parties to be included for each purpose. We ended with §4.4.10, having to do with the zone file. We intend to finish off the remaining subsections asking each newly added party to explain why this is a legitimate and lawful purpose.

• Beginning with §4.4.11, x's were added by registrars and registries. If someone added these, could you please provide a rationale?

• Re: §4.4.11, this concept of safeguarding could be a registry and registrar purpose and it may be useful to get additional input from the team on that.

• The registry purpose goes to EBERO and escrow, so as a purpose goes, yes - this is a registry purpose.

• For registrars: in regard to 4.4.11, that is covered under the escrow requirements so not necessary to be listed as a registrar purpose here.

• There should be other DRPs included in §4.4.12 and not just UDRP and URS.

• Question - there are plenty of places in 4.4 where the original Temp Spec wording is broad. The word choice in our work product will be extraordinarily important. With that in mind, what does "coordinating" mean in §4.4.12? I'm not sure coordinating is the right word.

• Coordinating could mean enabling this procedure so that it works properly.

• Coordinating could become more clear as we talk about processing.

• We are looking at generality vs. specificity - it's best to use specificity so that we know why we're collecting this data and identify specific purposes for collecting. §4.4.12 needs more specificity. If ICANN adds another DRP, ICANN will have to update its policy accordingly.

• What if ICANN adds a DRP in the future, how can the policy be dynamic if the policy needs to change?

• We could consider listing the acronyms of the relevant dispute process and add language that would cover additional dispute processes developed in the future that are the subject of ICANN consensus policy?

• Could we do a data privacy impact assessment for this? We need to show our transparency and go through the process.

• Would we have to notify all registrants about future changes if we invent or discover a new, valid use of data?

• This is the reason why the EPDP feels so high stakes all the time b/c we know how hard it is to change policy.

• I do not see the necessity in spelling out the mechanisms that we have.

• To make this more GDPR compliant, we need to be specific in our purposes and map out the relevant data processing - we do need more granularity here. The registrars proposed alternative language for §4.4.12 was going in the right direction.

• There may have been other DRPs referenced in the chat that may need to be added.

• If we are talking about the potential of future proofing -- I would suggest that PDP activities going forward with respect to any data privacy have a built-in data privacy impact assessment.

• Action Item 5: Leadership team to draft §4.4.12 based on today’s EPDP team feedback.

• §4.4.13 - contractual compliance monitoring request.

• In order to process a WHOIS inaccuracy complaint, ICANN sends the complaint to registrars to confirm the accuracy. With any other complaint that relates to contact data (for example, the audit), the registrar and registry would be involved in that.

• I question the contracted parties in this purpose. This function is b/w contracted parties and ICANN, a registrar receiving a compliance inquiry - our function is to resolve that with ICANN, not with a third party. Struggling to see the nexus here.

• I can see why registrars and registries may need access to the data, but I view compliance as an ICANN purpose. I think the purpose is who is creating the need for the data being available - I don't think you need a registrar/registry purpose for §4.4.13.

• There is a tendency to put all things WHOIS into this conversation. There is already a WHOIS accuracy policy. The temp spec does not affect any existing accuracy policies.

• §4.4.13 is a very narrow and specific type of access.

• For our next rounds of discussion, think about a way to make it more specific.

Action Item 5: Leadership team to draft §4.4.12 based on today’s EPDP team feedback.

5. Introduction to Appendix A (30 minutes)

Elements of Appendix A are on the agenda for the Los Angeles meeting, so an introduction of the key areas is required.

Background:

a) 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?

b) Key topics are Appendix A §§2-4.

• We need to identify data elements before we talk about redaction.

• Reasonable access is a term discussed in the temp spec and it can be discussed in a way that is not gated by the charter.

• We need to flag this and move on - this is perhaps why the GNSO Council designed the charter in the way that they did.

Action item 6: ICANN Support Team to make an index of all of the google docs the team is using.

c) Note feedback already received on Appendix A input document

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

7. Wrap and confirm next meeting to be scheduled for Monday, 23 September at 15.30 UTC at ICANN Los Angeles.