Dear EPDP Team:

Please find below the notes and action items from today’s EPDP meeting.

The next meeting will be Thursday, 26 March at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. All groups to review the minor comments section in the EPDP Team input on the Addendum Form and flag any comments that the groups view as NOT minor edits by COB today: Tuesday, 24 March. On Thursday, the EPDP Team will discuss the flagged comments (if any) before publication of the Addendum.
2. EPDP Team to publish its Addendum on the Initial Report on Thursday, 26 March. The public comment forum will now close on Tuesday, 5 May.

EPDP Phase 2 - Meeting #48

Proposed Agenda

Tuesday, 24 March 2020 at 14.00 UTC

1. Roll Call & SOI Updates (5 minutes)

2. Confirmation of agenda (Chair)

3. Welcome and housekeeping issues (Chair) (5 minutes)

4. Purpose 2 (priority 2) (15 minutes)

1. Review ICANN rationale statement

• During the Team’s last meeting, all groups but one found the Board’s draft Purpose 2 acceptable for publication
• NCSG requested the Board to provide clarity
• In formulating the discussion paper, the Board stayed very close to the specific words of ICANN’s mission, as set forth in the bylaws in terms of what SSR means within ICANN’s remit
• There are limits on the scope of ICANN’s policy development authority
• There are limitations on the scope of issues and the manner in which policies can be developed
• This is an org statement, but the board believes this purpose is necessary and appropriate

2. Feedback from EPDP Team
• Would it be possible to understand where this came from – was it the Board that wrote this? The initial reaction is that this takes SSR as the overarching ICANN mission with the bullets and details underneath. What the Team needs to look at more closely is the small bullets; some may already be covered in Phase 1 purposes. It does not seem appropriate to adopt the EC’s version of Purpose 2
• Understand ICANN’s mission – reiterating ICANN’s mission does not solve the problem. What parts of ICANN’s mission require disclosure from the SSAD? This restatement of ICANN’s mission does not answer this question. It’s important to specify what is not covered by current ICANN purposes.
• This is pulled from ICANN’s bylaws – SSR is ICANN’s mission and it’s fundamental to ICANN. Enforcing, implementing, and supporting the development of ICANN consensus policies will, at times, require access to nonpersonal data. Reject the notion that ICANN has to tell you what data elements it needs to carry out its mission.
• In Phase 2, the third-party purposes have been separated out, and rewording Purpose 2 is just finishing the Phase 1 work of converting this from a placeholder to a reworded purpose.
• In theory, ICANN could get this information, but the purpose needs to be here.
• The purpose appears to be abstract, but it’s time to move on from this discussion.
• IPC supports this
• NCSG needs to discuss this internally – if viewing from a registrant perspective, having trouble seeing why this is both necessary and appropriate. Purposes for processing registration data has to be explained to registrants, so not sure how this can be explained to me registrant.

3. Confirm language for inclusion in the addendum to the Initial Report
• Use the Purpose 2 formulation from the Board
• Add language from the Board to the addendum, and make clear that the NCSG is not agreement with this formulation
• NCSG can continue its review and reflection during the public comment period

5. Finalization of Addendum to Initial Report (15 minutes)

1. Review any cannot live with items identified
2. Feedback from EPDP Team

Legal v. Natural

• During the last F2F meeting, ICANN org noted it intends to provide the results of the study by mid-May, but this may need to change in light of COVID-19
• Action item: ICANN org liaisons to follow up on when the results of this study are expected.
• Can the Team expect any intermediate results to this study?
• If the discussion has come to a point where the Team is unable to say, the Temp Spec should remain. The Team should be mindful of getting this done rather than extending the time for discussion.
• The issue of legal vs. natural persons was in the Temp Spec and we are waiting for advice on this. GDPR does not apply to the information of legal persons, and there could be policy work on this. In the last week or so, the Team has received legal advice on legal vs. natural distinction – there are now multiple options from Bird & Bird. We are now in a place where we can have this discussion now that we have advice.
• Team did pay for legal advice, and we’re still waiting on the results of the survey, so the IPC does not feel that we should give up on this open issue.
• Is the Team prepared to delay the publication of the Final Report, pending results of the study. This may delay the report up until October or November, or is there an alternative solution here?
• Addendum currently says: Taking into account the timing of the delivery of its Final Report, the EPDP Team will not be able to consider the findings within the timeframe that has been established for the delivery of the Final Report. The EPDP Team will consult with the GNSO Council on if/how it is expected to consider the findings on this topic beyond its current timeline.
• Not recommending that the SSAD report be deferred – this is not a direct connection to the SSAD report. Object to the EPDP Team not handling the legal vs. natural and punting it to the GNSO Council for an indeterminate action in the future.
• There is a lot the Team can agree on and publish the majority of the addendum; however, the Team should not give up on legal vs. natural and should remove this from the addendum.
• Legal vs. natural is a policy question and does not have to be immediately resolved as part of an SSAD. NCSG believes that as a matter of policy, ICANN should have a uniform approach to the policy, and leave it up to the contracted party to make the choice. However, if some groups are suggesting that the policy be fragmented based on jurisdiction – this will not get the agreement of NCSG. In response to punting this to the GNSO, the GNSO is supposed to be the policy-making body of ICANN.
• Options: either ask the question of the GNSO Council how to handle it further, or make a statement of persistent disagreement and send to the GNSO Council.
• Not asking to delay the SSAD; just asking not to terminate the PDP. The Team is talking about legal vs. natural, not geographic differentiation at this juncture.
• This is holding up our work and our progress – re: SSR of the DNS, creating classes of registrants, even if delineated by legal v. natural does not sound like a stable DNS. Suggest flagging this as no consensus and move on
• The advice from Bird & Bird should be considered by the team; otherwise, the money is wasted.
• The disagreement on the legal vs. natural issue was never a legal one; it is a policy one. Do not see the value in having a legal memo from Bird & Bird compel the team to have a recommendation on this.
• What does it mean in practical terms if we extend the debate of the addendum by two weeks – how does that impact the timeline?
• The timeline from ICANN org is getting the results by early May. No interim conclusions will be provided before then.
• Table this and move on – unlikely to get results quickly.
• Groups that would like to continue this discussion: BC, IPC, ALAC
• If the addendum is not published today, there is no slack in the deadline. Priority 2 items were never considered part of the critical path for publishing the SSAD report. If we delay publishing the addendum, we will not make delivery of Final Report by June. If we delay discussion of this, it will take us off of the critical path of reviewing the comments.
• This is not an SSAD issue. The Team should not say it has not reached closure on the legal/natural issue
• The addendum includes narratives and conclusions – the BC looked at the words in the narrative and tried to determine what it could not live with. The legal v. natural narrative does not accurately reflect the record. The narrative in this addendum is not correct; it might be that the small team concludes that while CPs MAY differentiate, the majority of the EPDP Team does not agree that this should be a recommendation. Instead of pretending there is more to come, have the addendum reflect that.
• The GNSO needs to be notified where the Team is with this, especially if the Team does anything that will extend its timeline.

OCTO

• BC can live with this now that Purpose 2 is going in the addendum

Accuracy

• BC is not looking to prolong or relitigate, but the narrative should reflect that there was disagreement.
• The first sentence is fine, but do not agree with the additional statements including the opinion of the GAC representative. 
• Propose to strike everything after “treated”.
• Also look at line 662 for unbiased opinions.

Preliminary Rec. 22

• Remove “as disclosure…”
• Do not agree with the removal of this clause

Preliminary Rec. 23

• Some of what was stricken with respect to accuracy seems to be included in this rec. by the NCSG.
• Any members asking to include any additional rationale must do so within the next hour.
• Make clear that this is an ICANN purpose, not a purpose to justify the disclosure to third parties.
• Prefer to delete 662 – 666. Add explanations to the preliminary recommendation line 658 – this is an ICANN org purpose, not a third-party purpose.
• If this is deleted now, this does not forfeit the right of NCSG to make a minority statement or state a minority opinion.
• The Board is very clear about the statement of the purpose itself. Purpose 2 articulates ICANN’s purpose and is designed to avoid the conflation problem the EC identified in Phase 1. Object to a statement that ICANN could be prohibited from disclosing information under this purpose.

With respect to minor edits, the Team should be able to flag minor edits they do not agree with.

3. Confirm next steps

• EPDP support staff to note the divergence of opinion on legal vs. natural persisted. The EPDP team will consult with the GNSO on how to proceed.
• The EPDP Team received legal guidance noting that the publication of uniform masked email addresses results in the publication of personal data; therefore, wide publication of uniform masked email addresses is not currently feasible under the GDPR.

6. Review of Public Comments on Initial Report (30 minutes)

1. High level overview of input received by deadline (Staff Support)
2. Proposed approach for review of comments:
1. Commence deliberations on items identified in the report as requiring further work/review, considering input received to date, such as:
• Mechanism for the evolution of SSAD
• SLAs
• Reporting requirements
2. Staff support team to organize comments by preliminary recommendation, similar to approach in phase 1 (one document with all comments relating to that recommendation, see example and one discussion table, see example). Order of review determined by level of disagreement / change expected to be needed.
3. Every week by Tuesday COB, groups to provide their views on the discussion table for the topics that are to be discussed during Thursday’s plenary.
4. Leadership team & staff support team will consider input received on Wednesday and identify which comments need further consideration and/or proposed changes to the recommendation to address input received. 

Note, based on input received by 31 March on if/how many additional comments are expected, the approach may need to be revised.

Note, it will require the commitment of groups to review input received each week by the deadline – hopefully with only one plenary call a week and no small team meetings, groups will be able to organize accordingly. 

4. Feedback from EPDP Team
5. Confirm next steps

7. Wrap and confirm next EPDP Team meeting (5 minutes):

1. Thursday 26 March at 14.00 UTC. Topics to be addressed: Mechanism for the evolution of SSAD, reporting requirements.
2. Confirm action items
3. Confirm questions for ICANN Org, if any