[Gnso-epdp-team] Notes and action items from EPDP Team Meeting #41

Caitlin Tubergen caitlin.tubergen at icann.org
Sat Feb 2 20:45:14 UTC 2019

Dear EPDP Team,


Below, please find the notes and action items from the last EPDP meeting on Thursday, 31 January 2019.


Best regards,


Marika, Berry, and Caitlin



EPDP Team Meeting #41

31 January 2019


Action Item #1: EPDP Leadership to propose updated language for Rec. 11 (data retention) based on the discussion from today’s meeting.


Action Item #2: Registry and Registrar EPDP Team Members to review implementation bridge options with respective stakeholder groups and come forward with a proposal for the next EPDP Team meeting on Tuesday, 5 February.


Action Item #3: EPDP Team to review additional ICANN org questions and indicate on the email list if any of these need to be addressed in the Final Report




1. Roll Call & SOI Updates (5 minutes)


2. Welcome and Updates from EPDP Team Chair (5 minutes)

Today's meeting will mark the end of public comment review
Between today and tomorrow, the Leadership Team will review proposed edits to the draft recommendations and come back with proposed language for inclusion in Final Report. 
The Support Team will send an updated draft of the Final Report to the EPDP Team tomorrow, Friday, 1 Feb.
Following receipt of the proposed language, EPDP Team Members should flag any issues they believe warrant further discussion.
There will be meetings on Tuesday, Wednesday, and Thursday of next week.
In terms of getting the Final Report out - we plan to distribute the next draft tomorrow, Friday, 1 Feb.
Leadership will also send out the consensus call paperwork early next week.
There is a status of review document on the wiki page. The next step is for leadership to look at comments received and propose a path forward. Support Team is planning to update the Final Report based on suggested edits as well as agreed-upon text.
EPDP Team Feedback:
The recommendations should be voted as a package - they should not be voted on in isolation.
Crystal clear recommendations are a good goal, but in the process of consensus building, this may be impossible.
There needs to be sufficient time to review a final draft so that everyone can see what the report says.
a. Reminder: process for email discussions and upcoming deadlines

b. Review of outstanding action items

c. Other updates, if applicable


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


a. Recommendation 11 – Data retention (20 minutes)

i. Review small team updates and input provided (see PCRT at https://community.icann.org/x/U4cWBg and small team recommendations). ii. Review input provided (RySG, RrSG, GAC) (5 minutes)

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

Edits came from Ry/Rr public comments
Paragraph 1: One year retention period linked to the TDRP was originally recommended - if it is being retained for purposes of the TDRP, any data retained could only be used for the TDRP.
Paragraph 2: The EPDP Team did identify the TDRP as a means to justify the retention period. Registrars, if they use retained data for something under the TDRP, it would be under their own controllership.
Paragraph 3: in the absence of having text in the actual recommendation - it should not be construed to mean that contracted parties cannot set their own retention periods for their own purposes. The current waiver procedure must be maintained. Consider a fast track for waivers accepted, that parties within the same jx would be subject to the same waiver without having to apply separately.
Waiver procedures do not need to be applied to this recommendation. We may need a general disclaimer that notes that local laws have precedence.
It seems that public comments from non-CPH have not been factored into the text of the updated recommendation.
Should additional time be considered - public comments note 3 - 6 years. The language here is too restrictive - there may be other uses beyond the Transfer Policy.
To make a case to retain the data past one year - does the benefit of investigating something that happened on a name that's not under the registrant's control outweigh the risk to the data subject?
Saying data might be necessary at some point in the future is not a good enough reason to retain it
The Team could consider remaining open to requests to change the retention period based on certain requirements.
Retention periods under one year are highly problematic for investigations.
How proportional is it to save data and for how long. The argument has been made to retain data longer.
A balance is important here - what worked in the past may not work going forward, and we need to recognize new limitations and adjust accordingly.
The EPDP Team, as soon as practicable, recommends ICANN to undertake a review of all active process and procedures - including other lawful needs.
Not comfortable with ICANN conducting a study to determine retention for other needs. It’s likely this study would be biased.
It's not just about the retention period but also who would have access to the data - this would be part of the study.
We need to remember what we are doing here - do any public comments received warrant a change to the language. At this point, there does not appear to be comments that warrant change to the language. With respect to longer retention periods - no one would come up with a robust rationale as to why we need a longer period - therefore, we should keep what we have.
Action Item: EPDP Leadership to propose updated language for Rec. 11 based on today's conversation.
4. Implementation Transition Period (30 minutes)

The GNSO Council Leadership has requested the team further discuss next steps regarding implementation transition period and notes it may be helpful to include a recommendation in the Final Report.

This item was discussed in Toronto, and the Team discussed the bridging of a policy that will be adopted in the interim.
The gap is the time b/w when the Temp Spec expires and the new policy goes into effect.
The CPH have mixed feelings - could there be a compliance framework MOU with ICANN org, i.e., as long as CPH as doing their best efforts to comply with the new policy. Others are asking for something more formal.
The Council Leadership is requesting a recommendation to come from the community, rather than ICANN org.
There is not a consensus position within the RySG among the possible avenues forward. It may be more productive to defer this topic until next Tuesday.
A framework should have input beyond the contracted parties. However, it would be problematic if there was zero enforcement of the Temp Spec.
The general sentiment re: this gap is that the decision should rest with the EPDP Team.
Would this compliance framework be enforceable?
To the question of timing - if the Team is planning to issue a recommendation of a compliance framework, that could be considered in parallel with finalization of the Final Report.
The risk of having something more formal - this could be challenged by a given contracted party as an extension of the Temp Spec - and this may open the door to challenging the Temp Spec was implemented as an SSR emergency.
Important to get some guidance from ICANN org on their preferred path forward.
Need to think through timelines - this should be fleshed out with some degree of specificity by Tuesday. We need to think about providing a solution in a timely manner. Contracted parties should get support around a model and begin fleshing it out.
Action item: CPH to Put formal question in front of stakeholder group and come forward with a proposal for Tuesday's meeting.
5. ICANN Org Questions


There are six questions posed by ICANN within this table. Read the first three questions in five minutes.

a. ICANN Org Liaisons to introduce questions for discussion

1. RDAP and SLAs – what recommendations and/or guidance needs to be  included in the Final Report, or is this to be addressed during implementation?

This work comes from a spreadsheet emailed to the EPDP Team. The spreadsheet sought to identify changes from the Temp Spec and also areas where the Initial Report was silent.
Is there a good reason why the language was not included in the Initial Report?
What will happen to RDAP is the EPDP TEam is silent on this?
If there are additional items that need to be discussed, please flag them so we can add to the agendas next week.
Question: if the Team is silent, is this to be confirmed as policy, or not?
If the Temp Spec does not confirm, requirements from RA/RAA would control.
If the Team did not confirm the Temp Spec to be approved as policy, it would not be retained as policy.
The difference b/w the Temp Spec and what the EPDP Team is doing is the the EPDP Team is creating a new policy, while the Temp Spec is part of the contracts until May 25.
There is no need to include any of these items in the Team's Phase 1 report.
RDAP has not been implemented, and this is not necessary for GDPR compliance. What problem would be solved by putting this language in the Final Report?
There should be an RDAP mention in the policy, otherwise there is no obligation.
The Team's work to make its processes GDPR compliant - we will not include in Phase 1 of its work. The Support Team can consider adding proposed language in the Final Report. 
Action Item: EPDP Team to review additional ICANN org questions and indicate on the list if  any of these need to be addressed in the Final Report
On notices to RNH - this is changing specific requirements in the RAA - adds elements that conform to GDPR requirements.
Consent provision - language has restrictions on consent based on GDPR
Bulk registrations - Temp Spec requires only thin data
2. RDDS Search Capabilities - should the requirements in the Temp Spec be confirmed by the EPDP Team in the Final Report or is this to be further considered in phase 2?

                3. Bulk data registration access to ICANN – should the requirements in the Temp Spec be confirmed by the EPDP Team in the Final Report?

4. Process for amendments to Registry – Registrar agreements – should the process in the Temp Spec be confirmed as a policy recommendation, or is this to be addressed during implementation?

5. Does the ‘consent’ provision in the Temporary Specification require confirmation in the Final Report or is this to be addressed during implementation as consent is already defined in the GDPR?

6. Notices to Registered Name Holders Regarding Data Processing - is this required to be addressed in the Final Report or is this part of implementation or in direct consultation with registrars?

b. Confirmation of agreement reached or next steps to come to agreement


6. Wrap and confirm next meeting to be scheduled for Tuesday, 5 February 2019 at 14.00 UTC (5 minutes)

Confirm action items

Confirm questions for ICANN Org, if any





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190202/7fa8a90f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4621 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190202/7fa8a90f/smime-0001.p7s>

More information about the Gnso-epdp-team mailing list