Page History

Mp3

Adobe Connect Recording

GNSO transcripts are located on the GNSO Calendar

Attendance & AC Chat

Apologies: Kristina Rosette (RySG), Alex Deacon (IPC), Ashley Heineman (GAC)

Alternates: Beth Bacon (RySG), Brian King (IPC), Chris Lewis-Evans (GAC)

Notes/ Action Items

Notes and Action Items 

Small Team B Participants: 

• Benedict Addis (SSAC)
• Beth Bacon & Mark Anderson (RySG)
• Brian King (IPC)
• Chris Lewis Evans (GAC)
• James Bladel (RrSG)
• Mark Svancarek (BC)
• Milton Mueller & Amr Elsadr (NCSG)
• Hadia Elminiawi (ALAC)
• Thomas rickert (ISPCP)
• Daniel Halloran (ICANN Org Liaison -Legal)
• Rafik Dammak (GNSO Council Liaison)

Actions Items:

Action item #1: Small team B to review notes and proposals and respond immediately with any concerns as the findings will go to the full team next in preparation for the F2F meeting.

Questions for ICANN Org from the EPDP Team: None

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/ZwPVBQ

1.            Roll Call

• 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.

Review

Recommendation #13 – Controller Agreement

• See Discussion Table - concerns have been grouped together where possible to facilitate consideration.
• Question for team: which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation?
• ICANN Org is working on the memo discussed previously which is expected to be shared shortly (by Monday at the latest)
• RySG suggest that language is changed to not specify joint-contoller agreement but to have CPs and ICANN Org to work together to determine what type of agreement would work best. Many may be of the view that JCA is the best approach, but that may not be everyone's agreement. Important to have flexibility in the recommendation for those negotiating these agreements. RrSG comment is aligned with this perspective.
• BC can support this approach, allow for sufficient enough flexibility to have ICANN Org to take on responsibility for quieries by requestors.
• IPC can also support this approach.
• Not be overly presecriptive but agreements will need to outline the different roles and responsibilities.
• Support is conditional on ICANN assuming *some* formal responsibility here. CPs can't be compelled to disclose and also assume 100% of the risk exposure.
• Does proposed RySG language capture all possible scenarios or is it better to be more general? Note that the language refers to 'such as', which should provide sufficient flexibility.
• Some expressed the view that it is important to be specific here and provide guidance to ICANN Org on what is expected. How about timing? Would proposed rewording eliminate all other parties from the discussion? Could it overwrite EPDP Team recommendations? Flexibility is around the type of agreement that is put in place, not flexibility to change to policy recommendations of the working group.
• General agreement that recommendation should be more flexible and not prescribe the outcome, but further review may be warranted following receipt of the ICANN Org memo.
• EPDP Team does not support deletion of this recommendation as suggested by one of the commenters.
• Proposed updated language: "The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements such as a Data Processing Agreement (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate, with the Contracted Parties. In addition to the legally required components of such agreement, the agreement shall specify the responsibilities of the respective parties for the processing activities as described therein. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that determine the purpose and means of the processing."

Recommendation #20 - Input to Transfer Policy review (incl. Question #5)

• See Discussion Table - concerns have been grouped together where possible to facilitate consideration.
• Question for team: which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation?
• Language of recommendation is fine - comments point to specific issue sthat should be addressed in the transfer review that has been recently kicked off (see https://www.icann.org/public-comments/irtp-status-2018-11-14-en).
• Language is intended to instruct Council that additional work on the Transfer policy is needed as a result of GDPR.
• Important for all to share any concerns and specifics with the GNSO Council to help inform the review and next steps.
• No change needed to the recommendation. 

Recommendation #11 - Data retention

• See Discussion Table - concerns have been grouped together where possible to facilitate consideration.
• Question for team: which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation?
• BC/IPC request consideration of a 3 year retention period - especially in the context of cyberinvestigations. Is 3 years arbitrary? Reference to TDRP makes one year defensible - CPs need something specific and not arbitrary to defend a retention period. Could two year period in the RAA be considered as an alternative? Any data retention period beyond 1 year needs to be defended - hard to justify based on what has been provided as this relates to what ICANN governs.
• Needs to be made clear that the one year is a minimum required - contracted parties may need or be required to keep data longer. Similarly, local waivers may be needed. There may be altering retention periods based on national laws / retention requirements or based on the business practice, but that would not be for ICANN to govern.
• Language could also be cleaned up a bit.
• Note, this is just how long folks can keep data to fulful an ICANN requirement.
• Consider extending retention based on notification? LE can request for freeze through G7 network which allows MLATs to be fired off in the tie needed. Would such a freeze also be enforceable by ICANN? Caution to write up policy language - CPs already take appropriate action in case of an active legal investigation.
• Regarding minimums being defensible, a CP 's retention policy would need to disclose that at the time of collection regardless whether mandated by ICANN policy, local law, or individual business needs.
• Parties advocating longer retention period to provide further supporting information to justify a longer data retention period.
• Possible rewording: The EPDP Team recommends that Registrars are required to retain the herein-specified data elements for one year following the life of the registration. This minimum retention period is consistent the requirements of the TDRP.
• Proposed modification: make clear that proposed period is a minimum period, or more specifically a period for ICANN required retention and that CPs can adjust as needed beyond that period in line with local law / requirements. Remove the 'statute of limitations' language. Further discussion needed on the recommended ICANN retention period.

Recommendation #21 – Data Controller Agreements - EBERO

• See Discussion Table - concerns have been grouped together where possible to facilitate consideration.
• Question for team: which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation?
• NCSG point is mooted by the words "with the non-contracted Party entities" in the Recommendation
• No change needed

Consider further

Purpose 5 - see edits overview shared by Kristina

• Registrars are proposing language to limit the scope of the recommendation. Current language is overly broad. Need to restrain ICANN's ability to gather data, should be limited to terms of enforcement of those agreements, only for purposes that are outlined in the agreements.
• Proposal: Handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users, consistent with the terms of the registry agreement and the registrar accreditation agreements, and any applicable data processing agreements, by accessing specific data only as necessary.
• Perhaps "processing" as opposed to "accessing" would be better
• May consider splitting this up - intertwining two different thing, two different purposes that compliance pursues: handles monitoring and audits of their contracts, and separately handles compliance complaints.
• Important to be specific and not conflate with other purposes.
• Combine registrar and registry proposal - proposed rewording: 1) Handle contractual compliance monitoring requests and audit activities consistent with the terms of the registry agreement and the registrar accreditation agreements and any applicable data processing agreements, by processing specific data only as 2) Handle compliance complaints initiated by ICANN, or third parties consistent with the terms of the registry agreement and the registrar accreditation agreements.

Recommendation #10 - further thoughts on how to address comments or is this to be referred to plenary?

• Any suggestions to be shared on the mailing list

Recommendation #16 - update from Steve, Brian, James and Kristina on possible way forward. Consider remaining concerns.

• IPC/BC withdrawing its request for an additional recommendation, assuming that recommendation #16 will remain as is.
• Other concerns flagged seem to concern communication issues and URS review - may not be within scope and already addressed somewhere else. May have been covered already in deliberations and language of Initial Report.

Confirm submission to plenary of

• Purpose 3
• Recommendation #19

Next steps:

• Support staff will circulate notes and capture proposals made
• Following that, small team B outcomes will be shared with full EPDP Team for review

Action item #1: small team B to review notes and proposals and respond immediately with any concerns as the output will go to the full team in preparation for the F2F meeting.

Notes/ Action Items