[Gnso-epdp-team] Notes and action items from today's EPDP Team Meeting - 14 August 2018

[Marika Konings]

Dear All,

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

As a reminder, our next meeting will be Thursday, 16 August, 13:00 UTC.

Best regards,

Caitlin, Berry, and Marika

===============



EPDP Team Meeting - 14 August 2018

Tuesday, August 14, 2018


High-level Notes/Actions:

1.       The next meeting is Tuesday 16 August at 13.00 UTC. The deadline for submission of Part 3 of the survey is Wednesday, 15 August at 19:00 UTC.

2.       In response to a request for better access to the meeting proceedings, ICANN will provide a “read-only” Adobe Connect room where Alternates and Observers can see the presentations and chat and listen to the audio. The room was tested in today’s meeting and should be available for the next meeting.

3.       In a discussion of the role of this “Triage” portion of the work it was pointed out that:

     *   combining  sections for comment can result in a result that there is not consensus on an issue where there often is agreement on the heart of the issue
     *   the utility of the Triage discussion was also questioned as, after some issue identification, we skip over substantive discussion
     *   by way of suggestion, if more “wordy” comments were submitted, support / non-support and root issues will be more easily identified
     *   the goal of the Triage is to form the required deliverable for the GNSO where the comments provide a basis for the next round of discussions
  1.  Additional materials requested of ICANN:
     *   “Picket Fence” presentation from by Becky Burr
     *   Library and summation (e.g., staff notes and annotations) of communications between ICANN and EDPB and other similarly situated entities
  2.  ICANN’s role as a data controller should be noted and communicated for discussion at the appropriate time to ICANN in secs. 5.1 et.sec., particularly Data Escrow



Questions for ICANN Org from the EPDP team:

1.       Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data?

2.       In section 5.7  of the Temporary Specification (and other sections), what is the meaning of “reasonable access”? Is it access to personal data reasonably provided? Does “reasonably” relate to the effort necessary to retrieve it? Does it mean how criteria for releasing it are applied, i.e., legitimate and not overcome by the rights of others? Should it just be “access”?



All Action items:

·         Staff to circulate proposed Communication Plan with EPDP Team for input and review

·         EPDP Team to review communications plan and provide feedback

·         Staff to share instructions for use of alternate AC room with AC streaming prior to Thursday's meeting.

·         Council liaison, Rafik Dammak, to provide update on participation of alternates to GNSO Council and determine whether there any concerns about the proposed approach for live streaming the AC room to facilitate read-only access to AC.

·         Staff to share “Picket Fence” presentation that Becky Burr provided to GNSO Council with EPDP Team.

·         Staff to forward message from Kavouss regarding selection of meeting venue with ICANN CEO and ICANN Board Chair (completed) and his spoken message in today’s meeting

·         EPDP Team members to complete survey part 3 by Wednesday, 15 August at 19:00 UTC



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

·         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 Chair



·         F2F meeting

·         Scheduled to be held in Los Angeles from Monday 24 - Wednesday 27 September 2018. Plan for full three day meetings.

·         Concerns expressed about visa ban that will prevent attendance of some members of certain nationalities. This has also affected attendance of members for other meetings such as ICANN60 in Puerto Rico. Request avoiding any future meetings in any country or geographic territory which impose an entry ban for certain nationals. This request has also been communicated to the ICANN CEO and Chairman of the ICANN Board.

·         Are alternates able to attend in person, if they would desire so? There may be space limitations that need to be factored in, but the leadership team is looking into options. Some disagree with the ability of alternates to attend - their role is to replace members in their absence not participate in addition to members.



·         Communications Plan

·         One of the requirements of the charter is to communicate on a regular basis with the GNSO Council and broader community. ICANN Staff has put together a plan & road map that outlines various ways of communicating regular updates.



Action item #1: Staff to circulate proposed Communication Plan with EPDP Team for input and review

Action item #2: EPDP Team to review communications plan and provide feedback



·         Access for Alternates

·         Request for read-only access to Adobe Connect room to facilitate alternates to follow deliberations. This could be done through using a shadow room.

·         Recommended that if there is support from GNSO SG/Cs for this request, to request Rafik as the GNSO Liaison to take this back to the GNSO Council for its consideration.

·         Proposed approach is to live stream the Adobe Connect room for alternates/observers to observe - this will allow for real time view of chat and slides.  Testing is currently occurring with the hope that this solution can be rolled out by Thursday's meeting.



Action item #3: Staff to share instructions for use of alternate AC room with AC streaming prior to Thursday's meeting.



Action item #4: Council liaison, Rafik Dammak, to provide update on participation of alternates to GNSO Council and determine whether there any concerns about the proposed approach for live streaming the AC room to facilitate read-only access to AC.



·         Draft Triage report

·         Still work in progress - the hope is to share the draft triage report shortly with the EPDP Team for review.



3. Summary of responses to EPDP Input Survey Part 2

a. Results for Sections 5-7 (Requirements Applicable to Registry Operators and Registrars)

b. Appendices B (Supplemental Data Escrow Requirements) & F (Bulk Registration Data Access to ICANN)



See summary table of results in slide deck



4. Substantive Discussion of Temporary Specification (beginning with Sections 5, 6, 7, Appendix B, & Appendix F)

a. Part 2 of the Survey can be found at  https://www.surveymonkey.com/r/7BMRCNS

b. Responses and issue summaries are in the Spreadsheet accompanying this agenda



Section 5. Requirements Applicable to Registry Operators and Registrars

5.1. Publication of Registration Data

5.2. Registrar and Registry Operator Service Level Agreement.



Issue Summary:

5.1: There are many comments but none object to the incorporation of the Appendix into the Specification via this clause.

5.2: It was noted that the required date for the closure of SLA negotiation is past and should be reset to one quarter out or dealt with in some other way.

Other comments state that discussions on access should not occur until after all gating questions have been answered, and Contracted Parties are data processors only to the extent necessary to fulfill the objectives clearly articulated within ICANN's mission statement.



·         Most comments pointed to the appendix not the section itself.

·         Add to the summary for 5.1 that there is disagreement regarding the content of the Appendices.



Issue Summary:

5.3-5.4: Most groups support these clauses as incorporating the Appendix into the specification. There is disagreement regarding the content of the Appendices.

5.5: Discussion required to ensure this wording adequately addresses all possible combinations of countries involved in data transfer.



·         ICANN is not mentioned as party here, this is problematic. Need to make relationship clear - data agreement between escrow agents and ICANN.

·         ALAC comment was more of a question than an objection in relation to 5.5. Wording in the section refers to adequate processes but not clear whether in all cases there are adequate processes available. Should be clarified.



Issue Summary:

Many support sections 5.6 - 5.7. ICANN & this team should define "reasonable access" in Section 5.7.

Those not in support of 5.7 state that ICANN needs to ensure that access is narrowly tailored for this purpose.  There is a question as to why ICANN needs access to registration data for compliance purposes. Another group states ICANN should have full access to registration data.



·         Need to define "reasonable access" as part of 5.7

·         Need to be precise in what data elements ICANN needs to get access to for what type of compliance action.



Section 6. Requirements Applicable to Registry Operators Only

Issue Summary:

Several groups support 6.1 - 6.3; one noted that (1) section 6.3.2 should be amended to reflect that approval of RRA updates is necessary and (2) the community should strive to have a single, standardized approach on GDPR provisions in general, and international transfers in particular.

Other comments: (1) amend the timeline in 6.2; (2) clarify the definition of periodic access in 6.1, the reporting requirements in Section 6.2, and the language around international data processing in 6.3; (3) Test 6.1 and 6.2 against data minimization principles



·         RySG suggested eliminating section 6.2 and suggested clarifications to 6.3. Do model clauses even apply in all circumstances? For 6.2 date is in the past so language is not relevant as it has been superseded by what has happened in practice. 6.3 goes into the limits of the picket fence, this gets into an area that goes beyond the picket fence. Encourage everyone to review specification 1 to the new gTLD Registry Agreement which sets out the parameters of what consensus policy can cover - this seems to go beyond that? This may need further analysis as not everyone may agree that this falls outside the picket fence - let's not make assumptions. If need be, specific questions could be asked of ICANN staff?

·         What are additional reporting requirements? What is meant with that? Clarification needed.

·         In relation to section 6, consider having registrar operators contributing to this contribution as they impose requirements on a blanket basis. Up to contracted parties to pass on any obligations to parties they have contractual agreements with. May confuse things if downstream parties are included in this conversation?

·         Need to consider whether article 6 approach is taken which would involve joint controller agreement between ICANN and contracted parties.

·         ICANN's Model RRA-Data Processing Agreement refers to the concept of Shared Personal Data (which is a subset of Personal Data and not mentioned in the Temp Spec.)



General comments on triage effort



·         Objective of this exercise was originally to try and establish where there was agreement / support for certain sections but also understand where there is disagreement and why. Summaries aim to provide succinct summary of the main comments in each section. Tool for driving the discussions in the next phase where the EPDP Team will hone in on the substance and possible path forward. Individual comments will of course also be part of that.

·         Grouping of certain sections may unfairly indicate support or lack thereof as sometimes issues are with a very specific part. In certain cases a ‘No’ response may support the concept but may have objected to the actual phrasing. Need to figure out where there is agreement and/or minor issues that can be easily addressed so focus can be on the significant disagreements.

·         We do the triage exercise to establish which parts of the temporary specification are controversial and what the reasons for objections are. Therefore, suggestion is to indicate the level of support and be a little more wordy on the reasons for objections. That can probably help avoid discussions on these calls.

·         Need for proper definition of terms to be able to express views.

·         Maybe should have focused on, do you agree in principle with this section to weed out minor issues vs. substantial ones.



Action item #5: Staff to share presentation that Becky Burr provided to GNSO Council with EPDP Team.



Section 7. Requirements Applicable to Registrars Only

Issue Summary 7.1 - 7.1.8:

Some comments indicated this provision is too prescriptive and, as such, is likely to: (1) give a false impression that following this direction provides full GDPR compliance, (2) not address privacy regimes in other jurisdictions, and (3) does not accommodate different business models. It would be better to generally require GDPR notice requirements.

This clause does not include ICANN’s role and notice requirements as a data controller.

Some supported this detailed direction but indicated additional detail and definition of terms (e.g., legitimate interest”) is necessary.



·         Who decides what is commercially reasonable?



Issue Summary 7.1.9 – 7.1.15:

Some groups believe more precision and detail is needed to cover all aspects of GDPR ("consent" should used as in list of defined terms), but contracted parties believe that the sections are too prescriptive, and each registrar and registry must figure out how to comply given its business model



·         May need single policy across all registries and registrars - EPDP Team's role to define what that is.



Issue Summary (7.2 - 7.2.4):

The potential implementers of Section 7.2 note (1) the difficulty of gaining consent to publish "additional contact information" and more clarity is needed around the purposes of collecting additional contact information; (2) the difficulty of multiple parties (other that the registrant) providing consent; (3) making each field "selectable" with regard to consent;

It is also pointed out that GDPR-compliant consent is still not defined, and that consent should be clear in any case.

Those seeking information seek to (1) accelerate the Consent capability implementation (faster than commercially reasonable) and (2) that any contact within the Whois set of contacts and others can consent to disclosure.



·         Some limited use cases in which registrants have provided consent to share data - not a clear process yet for how to communicate this with the registry, or how consent is obtained from other contacts that have been listed. Consent is a complicated matter.

·         Consent has to be as easily withdrawn as given - tracking the status of the consent is a challenge and as such may not be reliable basis compared to some of the other legal basis.

·         What happens if consent is withdrawn?



Issue Summary 7.3 - 7.4:

This clause is generally acceptable but the Appendix G to which it refers is likely flawed as it denigrates the position / rights of the gaining registrar. The rest of the team looks forward to a briefing by registrars of this issue so there might be agreement that the revised transfer policy is GDPR compliant.



Appendix B - Data Processing Requirements

Issue Summary - 1:

It is suggested that this Section should be struck as the data that is escrowed under the RAA is different that Whois data and so this specification does not apply. It is also suggested that ICANN be identified as the Data Controller here for imposing this requirement and recommended that the RySG suggests that the escrow providers and contracted parties are best placed to work out how to operate escrow services in accordance with the GDPR.



Issue Summary - 2:

There are parallels to be drawn between data escrow transfers between countries and Whois data transfers between countries - are they both subject to the safeguards listed in Chapter V and what are the implications of that to Whois access?

Also, it was pointed out that data escrow is governed by a set of agreements among ICANN (a data controller), the contracted parties and the data escrow provider and might be better left for those parties to negotiate.



·         There are already contractual obligations in relation to data escrow - does this belong in a temporary specification?



Issue Summary - 3:

Most agree with this provision but those that do not state that the EPDP needs to clarify ICANN's approach to data escrow agreements and the relationships (i.e. controller / processor) between the parties. This issue highlights the greater need to clarify roles and responsibilities of parties and the structure data sharing agreements. The escrow providers and contracted parties are best placed to work out how to operate escrow services in accordance with the GDPR.



Issue Summary - 4:

This section is supported. It was pointed out that data escrow is governed by a set of agreements among ICANN (a data controller), the contracted parties and the data escrow provider and might be better left for those parties to negotiate.



·         Should establish for a fact that ICANN Org is the data controller for this part and contracted parties are carrying this out on ICANN Org's behalf.

·         Negotiation should not only be left to CP and ICANN.



Appendix F: Bulk Registration Data Access to ICANN

Issue Summary:

This section is supported. It was pointed out that domain names themselves may also be personal information and so this processing activity needs to be analyzed for purpose and legal ground.



·         Does ICANN Org have a plan in place for storing of this information? Isn't personal data stripped out of bulk registration data? Not clear what process is currently used.

·         Not clear how a domain name registration can be personal information.

·         Need to make sure that the way reporting is done is legally compliant.

·         Need to assess whether there are things that ICANN as the processor needs to do to ensure it complies with GDPR.

·         Is this a problem for the EPDP Team to solve or is this for ICANN Org to solve? Shouldn't this be ICANN Org's determination to make?



5. Review action items and questions for ICANN Org, if any



Questions for ICANN Org from the EPDP team:

1.       Is there a list and summary of ICANN contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data?



All Action items:

·         Staff to circulate proposed Communication Plan with EPDP Team for input and review

·         EPDP Team to review communications plan and provide feedback

·         Staff to share instructions for use of alternate AC room with AC streaming prior to Thursday's meeting.

·         Council liaison, Rafik Dammak, to provide update on participation of alternates to GNSO Council and determine whether there any concerns about the proposed approach for live streaming the AC room to facilitate read-only access to AC.

·         Staff to share presentation that Becky Burr provided to GNSO Council with EPDP Team.

·         EPDP Team members to complete survey part 3 by Wednesday, 15 August at 19:00 UTC



6. Wrap and confirm next meeting to be scheduled for Thursday 16 August at 13.00 UTC. (Part 3 Survey results due Wednesday, 15 August by 19:00 UTC.)

Marika Konings
Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN)
Email: marika.konings at icann.org<mailto:marika.konings at icann.org>

Follow the GNSO via Twitter @ICANN_GNSO
Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-efforts.htm#newcomers>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20180814/a2dc7855/attachment-0001.html>