Thank you, Marika!

All, I had provided in the AC chat room links to ICANN org’s responses to EPDP Team’s questions regarding OCTO’s use of registration data, but the links were broken. Here they are again. As mentioned, if the Team has any additional questions for OCTO, Dan and I would be happy to take them to our colleagues in OCTO.

Best,

Trang

From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Marika Konings <marika.konings@icann.org>
Date: Tuesday, January 29, 2019 at 12:00 PM
To: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org>
Subject: [Gnso-epdp-team] Notes and action items EPDP Team Meeting #40

Dear EPDP Team,

Please find below the notes and action items from today’s EPDP Team meeting. Please take specific note of action item #4:

Action item #4: EPDP Team to indicate if there are any concerns / objections to the addition of ‘maintenance’ to the language for purpose 1, so that it reads: “To ensure that a Registered Name Holder may exercise its rights in the use, maintenance, and disposition of the Registered Name Holder...

Best regards,

Caitlin, Berry and Marika

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

EPDP Team Meeting #40

Tuesday, 29 January 2019

Notes and Action Items

High-level Notes/Actions:

Action item #1: Leadership team / Support staff to propose revised wording later today to address input provided during today's meeting in relation to reasonable access.

Action item #2: Legal committee to formulate question to obtain clarity for how the proposed additional “purpose” of ICANN Org research could/should be addressed. Via what means ICANN Org, as controller and even though it does not have the data, request data in a GDPR-compliant manner to undertake research.

Action item #3: Staff support team to make updates accordingly to data elements workbooks for purpose 5 to cover ARS.

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.

Proposed Agenda:

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

a. Reminder: process for email discussions and upcoming deadlines (see also https://community.icann.org/x/VZwWBg and https://mm.icann.org/pipermail/gnso-epdp-team/2019-January/001342.html)

b. Review of outstanding action items

c. Other updates, if applicable

Appreciate all the contributions that have been made on the mailing list over the last few days
Leadership has taken note of the comments in relation to workload
Aim to keep the pace and work towards final report - need to determine what is necessary for the report to be meaningful.
Try to close of as many issues as possible on the mailing list, but may need to come back to some of those during calls.
Urge to focus on what is really important in the recommendations - avoid wordsmithing for the sake of improving the language.
Wiki page will include the latest information: https://community.icann.org/x/VZwWBg.
As deadlines close, leadership will review input received and make a recommendation on how to move forward. This could be in the form of a 'final' version to be reviewed on list or during a meeting.
Important to note which of these questions / recommendations could benefit / improve with more time and which would remain the same. Not spend more time on those latter items.
Planned publication date for Final Report is 11 February to align with GNSO Council document deadlines. Special Council meeting has been scheduled for 14 Feb which would allow for Council review / discussion, followed by a possible vote during the 21 Feb meeting. This would allow consideration by the ICANN Board prior to the 25 May expiration date.
Need sufficient time to allow members to consult with their respective groups. Think about ways to already get input from members before formal consensus call takes place.
As a reminder, a consensus call is not about asking people to express consensus for the report or recommendations, but it is about the chair indicating the consensus level he believes that have been achieved. Members are then asked to indicate whether or not these designations accurately reflect the positions of the group.

3. Continue review of public comments on Initial Report and/or revised recommendations

a. Recommendation 5 – Data elements to be transferred from registrar to registry: the team will review the public comments while small teams will review the data elements (30 minutes)

i. Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes)

ii. Question for team: which concerns / data elements merit group discussion? Specifically, do any of the concerns / data elements suggested present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes)

iii. Confirmation of agreement reached or next steps to come to agreement (5 minutes)

Data that can be transferred is a matter of legal assessment, not want or desire. EPDP Team has gone through this legal analysis as part of its work. Where there is a legal basis (6.1(f)), such data may be transferred.
Many of the comments are on opposite ends to the spectrum. For our purposes, need to recognize that the concepts of thin / thick do not serve our purpose here, also in the context of the GDPR. RDS PDP WG came to a similar conclusion - identified minimum public data set (baseline set of elements). Registries / registrars are free to add additional data elements under purpose 7. Need to forget about thick / thin - we are creating something new.
EPDP Team has factored in data minimization and which data is required.
Approach that has been taken at the outset is that purpose for processing data were identified, followed by data elements analysis and subsequent data processing steps that found which data elements are required to be transferred to registries.
Consider distinguishing between base set and base set plus additional data elements. To be further considered by Data Elements Workbooks small team.
Registrars are not opposed transmitting data to registry but have maintained that whether it is done or not is predicated on a legal justification for that data sharing. That case needs to be made outside of the purposes identified by the EPDP Team. Dependent on the registries making the case that registrars 'must'. Need to change vocabulary. Registrars would NOT support transferring millions of records to a Registry that does not or cannot justify why they need this data.
There is an existing consensus policy that will need to factored in. Note that recommendation #22 already refers to Thick Whois as one of the policies that will need to consider how the EPDP Team recommendations potentially impact that policy and its implementation.
Thick WHOIS IRT will need to review potential impact of these recommendations on its work.
Agreement from the group to proceed this way - In relation to the questions raised in relation to thick WHOIS, the EPDP team refers commenters to the analysis in the Final Report for which data elements may be transferred from registrars to registries, but also noted that per recommendation #22, the impact of these recommendations on the Thick WHOIS policy will need to be assessed during the implementation phase. (Consider how to further clarify this language per the discussions during the meeting)

b. Recommendation 12 Reasonable Access (30 minutes)

i. Review of updated language circulated by Alex Deacon on behalf of small team - https://mm.icann.org/pipermail/gnso-epdp-team/2019-January/001327.html (5 minutes)

ii. Consider updated language – does it address the concerns expressed during the public comment? (20 minutes)

iii. Confirmation of agreement reached or next steps to come to agreement (5 minutes)

See revised language shared by Alex Deacon.
Aims to add further detail in relation to the items to be further considered in the context of 'reasonable'. Aim to create a feedback loop over time so that process can be improved over time.
See input from RrSG and responses from Alex.
Hesitant to put specific timelines in. May need to distinguish between urgent requests for which a shorter timeline is essential. A subpoena/warrant/court order is always an "Express Lane". Consider something like: "without unreasonable delay, but ordinarily not more than 30 business days from receipt."
Each data element needs a legal basis as to why it should be disclosed.
There should be flexibility for the CPs. Responses might need to be different than what has been offered and a response may also be to provide a subset of the data that has been requested.
How to deal with voluminous requests? Would that impact the deadline?
Consider strengthening language that currently says are 'further explored as part of the implementation'?
Need to consider how CPs can deal with requests in new environment. What is technically reasonable? What can be automated?
Focus on the policy language that sets policy goals for the interim period while further work is undertaken on the standardized access model as well as part of implementation.
How can data be made available to LE outside of the EU? Consider adding a point to the recommendation to consider this as part of implementation.
The more details that are added, the more time that may needed for groups to review.
Need a permanent disclosure policy going forward as not every entity may be able to accredit in a future access model.
Wording needs to set limit but also set expectations so that the limit is not the norm.
Should go beyond best practices, and need something sooner rather than later. Need to make it more clear what reasonable access means.
How to deal with registrars that are not at the table - important that compliance can take action against those as it is not about those that are actively collaborating with requestors.
Consider asking legal counsel for advice on whether ICANN Org research can be captured under purpose 2, whether it is already foreseen under GDPR (ability of controller to do research) or whether a separate purpose needs to be created.

Action item #1: Leadership team / Support staff to propose revised wording later today to address input provided during today's meeting in relation to reasonable access.

10 minute break

c. Recommendation #1 – Additional Purposes (20 minutes)

i. Review input received to date (RrSG, ALAC, NCSG) (5 minutes) (see attached)

ii. Confirmation of agreement reached or next steps to come to agreement (5 minutes)

See summary document that was circulated that contains input received to date.
New recommendation on additional purposes: see conclusions reached by Milton, no other purposes identified that require further discussion, apart from those already on the list.
ARS is a compliance activity as such capturing it as part of purpose 5 by updating references to ICANN Compliance to ICANN Org would remove the need to consider a separate purpose.
In relation to research, see also input from legal counsel on how this might fall under controller ability to undertake research. Is access of data by OCTO just another access question under purpose 2 or does it require a separate purpose? Is the work significantly different that it requires a separate purpose? ICANN Org has indicated that no additional data is currently used or needed to carry out responsibilities. Could this be addressed by Purpose 2, even though focus is on third parties? No, this is unlikely to apply. Could you make purpose 2 apply to ICANN Org? Or Purpose 5 - Compliance? Need to test legality. Need to clarify with legal counsel whether ICANN as controller, even though it does not have the data, it cannot request it to undertake research, per the GDPR.
Would need requirements from OCTO to be able to determine what is needed. ICANN Org would need to indicate what is needed for this to be a purpose. See previous responses on this topic: https://community.icann.org/x/ahppBQ. If data is needed in the future, it would be hashed data. We are not discussing what ICANN should do in the future, but what ICANN does now.
EPDP Team Agreement: Address ARS as part of purpose 5 by making the updates as suggested by Alan Greenberg (change reference to ICANN Compliance to ICANN Org).

Action item #3: Staff support team to make updates accordingly to data elements workbooks for purpose 5 to cover ARS.

Purpose 1 – proposal by BC to add “maintenance”

d. Recommendation 11 – Data retention (20 minutes)

i. Review small team recommendation and input provided (RySG, RrSG, GAC) (5 minutes) (see attached)

ii. Consider updated language – does it address the concerns expressed during the public comment? (20 minutes)

iii. Confirmation of agreement reached or next steps to come to agreement (5 minutes)

Deferred to next meeting / mailing list

4. Next steps to get to Final Report (15 minutes)

a. Updated Timeline (see attached)

b. See draft Final Report circulated to the mailing list (see https://drive.google.com/a/icann.org/file/d/1E6W-daNTaadOhG5BRlzNJQbrT9MSoKDn/view?usp=sharing [drive.google.com])

c. Process for review (see https://docs.google.com/document/d/1sVZ9odV0qK1Bk8a4bDwWe5RW_PBzOnYBhHW_GnLL8jw/edit?usp=sharing [docs.google.com])

5. Wrap and confirm next meeting to be scheduled for Thursday, 31 January 2019 at 14.00 UTC (5 minutes)

a. Confirm action items

b. Confirm questions for ICANN Org, if any

Marika Konings

Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN)

Email: marika.konings@icann.org

Follow the GNSO via Twitter @ICANN_GNSO

Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.