Dear EPDP Team:

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

Best regards,

Marika, Berry, and Caitlin

--

ACTION ITEMS

1. EPDP Team to carefully review all recommendation review templates and indicate:
   1. any “cannot live with items” with an accompanying rationale and proposed edited text by COB Monday, 15 June. Please provide text in the table at the top of the template and be sure to include the item number.
   2. Incorrect assumptions by the Staff Support Team
   3. Further clarifications for items highlighted in yellow and blue.
2. EPDP Team to carefully review the Leadership proposal for Priority 2 items and indicate if your group cannot live with the proposed path forward by Monday, 15 June. If there is not sufficient support for the proposed path forward, the topic will not be included in the SSAD Final Report and further consultation will take place with the GNSO Council if/how the priority 2 topic is expected to be addressed.
3. Staff Support Team to work with Chris Lewis-Evans to address the questions from today’s meeting by COB Monday, 15 June.
4. ICANN org liaisons to inform EPDP Team when the legal v. natural study will be delivered.

EPDP Phase 2 - Meeting #63

Proposed Agenda

Thursday 11 June 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)

1. Status of small team deliberation on rec. 19 mechanism

• Team met two times this week, and the team has reached a deadlock
• In an effort to move forward, some members (Marc, Brian, Amr, and Owen) met to iron out the divergence of opinion on the scope of the exercise – this small team will meet again on Monday.
• Everyone agrees there should be an evolutionary mechanism, but there is disagreement over what that should look like. Based on time, it will be at least 1.5 years until the evolutionary mechanism needs to be built (based on implementation). This could be passed to the GNSO to build the mechanism closer to the time when the mechanism will be necessary.
• Do not agree that everyone agrees on an evolutionary mechanism. NCSG was willing to make some movement for practical reasons. It has become increasingly clear during the small group discussions that certain groups see the evolutionary mechanism as a way to change policy, particularly around automation. NCSG has not been given any concessions on the issues it cares about and is on the verge of abandoning support of any mechanism. If the Team can’t make concessions on items NCSG cannot live with, the NCSG will not agree to a mechanism. Recognize a pathological term in the process – the Team is not actually coming to agreement but rather putting issues off to other committees that will extend endlessly.
• Registrars support the idea that this PDP make recommendations on the long-term evolution. Part of the reason we are having this issue is we have had 20 years of not evolving. We cannot have a PDP that swallows the bylaws, and the Team doesn’t always have to assume more automation and less expensive operational costs. It’s possible the SSAD could evolve in another direction (more restrictive, for example) which is why an evolutionary mechanism is important.
• The Team seems to have different definitions of evolution – some believe it should be a PDP; others believe it should be formal. Some seem to believe that centralization is a policy change. In terms of letting the GNSO decide later, the ACs have no say in the GNSO, and that is likely unacceptable to the ACs.
• Once the Team takes certain issues out of the critical timeline, there is no faith this will be done. If the Team doesn’t settle on a definition of evolution soon, this will not come to a close. We need to agree on a mechanism within the bylaws.
• Ending the EPDP without having an evolutionary process in place is a nonstarter; this is for legal reasons. GDPR is all about documentation and reviewing what you have documented; by law, we are required to evolve the work product of this group. The biggest question is where to slice and dice what is policy and what is implementation. The Team needs to have a policy recommendation in the final report re: when it is implementation and when it is gTLD policy.
• There is an incentive to have a workable system on both sides of the divide. Could write the mechanism in the way that ACs have more than an advisory role.
• The Small Team is working on a solution that is not bypassing the policy process. In terms of the MfE – there will likely not be consensus from IPC or other groups. What is currently on the table is not good enough.
• The reason the NCSG is turning away from the evolutionary process is that the small team does not trust the GGP to be the supervisor of this policy because it’s done by the GNSO. Why do the ACs not trust the GNSO to make policy? Perhaps because some of the ACs would not be able to block consensus like they are able to do in the EPDP. NCSG does not like the term evolution but would be OK with continuous improvements/adjustments.
• The majority of talking has been done by people not in the small team – we should wait to see what they come up with.  

4. Proposed approach for reviewing and addressing input received on recommendations (15 min)

1. Overview of recommendations review template (Staff Support Team)

• Staff Support Team sent an email yesterday regarding the status of review
• For each recommendation, there is a template for review. Some recommendations are grouped together since they are interrelated. This has caused the recommendation numbers to be slightly out of order in the draft final report; Support Staff will update the numbers later but wanted to avoid confusion at this stage.
• By way of example, the template provides an input table for the Team. As a reminder, groups were asked to identify cannot live with and minor edits. https://docs.google.com/document/d/1iWMJCdnBhu5rk7VTceV0ifPvFy0-eIyE/edit
• The table shows the text groups are asking to change, the rationale as to why it should change, and Support Staff’s proposal of how to address the proposal.
• Green cells indicate where Support Staff applied the proposed change. If other groups believe these changes result in “cannot live with” text, they should indicate as such.
• Orange cells indicate where Support Staff applied the change but with slightly different wording, either because of other changed language or for consistency
• Red cells indicate where Support Staff did not apply the proposed change either because the other language was overtaken based on other changes or the topic has been extensively discussed
• Where there are no colors – Support Staff tried to respond to questions asked, but the Team should confirm Support Staff’s understanding.
• Yellow cells indicate where additional guidance is needed from the Team before the change can be applied (or not)
• Green and orange items have been applied in the draft final report
• It’s important to review the recommendations in context of the entire report
• Please flag “cannot live with” items by using the corresponding number. Similar to how you have done with the input on the recommendations, please come forward with proposed edits
• For yellow items, there are quite a few questions from an implementation perspective – if these can be easily closed off, please indicate this.
• Blue items are asking the requesting group to provide further information.
• The idea is the Team takes time until Monday COB to go through these documents and flag the topics that have resulted in a cannot live with status so that the Team can start walking through the yellow items and “cannot live with” items during next week calls on Tuesday, Wednesday, and Thursday.
• From there, Support Staff will work to produce an updated final report.
• We have a placeholder meeting for the following Tuesday, but we note that is during the ICANN meeting. This may not be necessary but will have to wait to see the progress next week. 

2. EPDP Team feedback
3. Confirm homework assignment for EPDP Team
4. Confirm next steps

5. Recommendation #2 Accreditation of governmental entities (20 min)

1. Review items flagged for EPDP Team Guidance

• Upon review of the recommendation, ICANN org is unsure how to implement or enforce this recommendation – the ask for the group is to provide further clarity re: implementation or enforcement
• Basic idea is that each gov’t would organize accreditation system within their country or territory and would liaise with ICANN org/Accreditation Authority
• In reading the recommendation, ICANN org is left wondering how to enforce requirements on gov’ts – how is ICANN supposed to de-accredit a government? How could ICANN apply the requirements in 1.3 to governments. There are also a lot of SHOULDs instead of MUSTS – how is this to be enforced? Other issues are marked in the review template.
• Governmental entities will be under the same de-accreditation as other users; this would be a scaled response instead of instant. If governments misuse this, it would warrant de-accreditation.
• Does the Team need guidance on when to pass any de-accredited party over to DPAs for breach under the laws? Suspect that we do.
• Is it the central gateway manager that is making this decision to de-accredit? Can this be made clear in the policy?
• The CGM could report misuse to the Accreditation Authority.
• For this type of activity, we need to find a de-accreditation mechanism within the ICANN ecosystem.
• Item 7 is a clarifying question from ICANN org re: definition of eligible gov’t entity – does this also include accreditation for IGOs?
• Yes, this is meant to cover accreditation for IGOs – maybe where the IGO is headquartered would fall under the country. This may need to be fleshed out how it could work in implementation.
• Ultimately, the team needs to establish rules for ICANN to enforce. This is a globalized policy; do not understand how 194 different jurisdictions will enforce these rules.
• What about governments who can seek data anonymously without a warrant -could the Team please summarize this and provide guidance?
• Question from Org notes that IGOs could serve as an accreditation authority for its gov’t or for its members. The Team does not seem to be addressing the question from ICANN org.
• ICANN org is trying to understand whether Interpol or Europol can use this recommendation to be an accreditation authority. Is this possible or explicitly prohibited?
• Realistically, you cannot have an entity that is both an identity provider and an accreditation authority
• Unclear whether we are talking about accreditation of authorities or accreditation of users. Could WIPO say we want to be an accreditation authority? Should WIPO go to Switzerland, or ICANN? If a WIPO employee wants to use SSAD, they would get accredited as an individual. If WIPO wants to get accredited as an accreditation authority, they would go to Switzerland.
• If you are a gov’t entity, are you required to use Rec. 2 or can you go to ICANN?
• ICANN noted it cannot verify who is a law enforcement agency. This recommendation is trying to provide ICANN with the ability to know who an accredited gov’t law enforcement agency.
• This seems to be a big change to Rec. 1. Gov’t accreditation has to go through Rec. 2. If the U.S. FTC wants to be accredited, ICANN has to say – please go to the USG.
• Can governments accredit entities that perform law enforcement functions?
• Only national public authorities could be accredited by the national authority.
• Easy examples are consumer protection org; the harder are industry bodies. Concerned about who has the authority in different regimes for anti-phishing (by way of example). These questions need to be unpacked carefully in implementation.
• Some of these issues should be dealt with in the implementation phase by asking each national authority to draft a list of potential organizations that would fall under their authority; everyone else would go through accreditation through the ICANN org process in Rec. 1
• Where would requirements be listed and made available to gov’t entities? How would this be enforced?
• This is around detailing the safeguards. This is ensuring that the safeguards are made clear to gov’t entities.
• If the gov’t authority breaches this, ICANN can revoke its accreditation
• Can the Team clarify that the “would” in section 5 is a “should” or “must”?
• The would could be a should or a must. Intergovernmental agency should say Intergovernmental organization.
• What does that mean – what authority would be delegated?
• The thought here is that there are a number of different-sized countries. Interpol may decide that for countries of a certain size, they will act as the accreditation authority.
• Does this mean a gov’t in Africa can recognize the African Union to be their accreditation authority?
• Intergovernmental organizations have very specific mandates. In the majority of cases, there will be a designated ministry that will be dealing with this job.
• Under data access, there are some bullets and it’s unclear where they belong.
• This is a leftover, and some could be moved to implementation advice. Bullet 5 could be moved somewhere else or made clear here.
• Action for Chris, together with Support Staff, to provide necessary clarifications and move the text around if it’s needed.

2. Confirm next steps

6. Proposed approach for dealing with priority 2 items (15 min)

1. Overview of feedback received and leadership recommendation

• The group separated the items into Priority 1 (SSAD) and Priority 2 (not on the SSAD critical path).
• Support Staff went through the input provided and drew conclusions at a high level.
• For P/P providers – there does not seem to be disagreement on the recommendation itself. The input on PPSAI IRT will be shared with ICANN org and GNSO for its consideration. Question to ICANN org liaisons – if/when PPSAI is restarted – question regarding names from the same P/P customer can be correlated.
• Legal v. Natural – no conclusion on this will be included in the Final Report. EPDP Team will need to consult with the GNSO Council re: expected next steps.
• Re: city field redaction, there is support to change the recommendation from MUST to MAY so that redaction may be applied.
• Data retention – observes that there seems to be confusion re: purpose for which data is retained and subsequent processing. Data is retained for purposes of the TDRP. This should not preclude requestors from retaining for other purposes that are legitimate. If this is acceptable, this will be included as implementation guidance in the Final Report.
• OCTO purpose – include conclusion to wrap up on the charter question.
• In relation to uniform, anonymized email address – there is not agreement on proposed edits nor whether to consider this further – Leadership noted this topic had little time for consideration. Propose not to include this in the SSAD final report at this point. Ask the GNSO to further consider this issue.
• Accuracy – persistent disagreement. Council is expected to form a scoping team to further discuss this issue.
• Purpose 2 – include updated purpose 2 in the final report.
• If there is not sufficient support for the proposal, the topic will not be included in the SSAD final report.

2. EPDP Team feedback

• In preparing this analysis, did Support Staff look at group feedback and individual feedback?
• Is the boxed text to be included or just the staff suggestion for a path forward? What will show up in the final report?
• The analysis is concerning the input provided in the discussion tables, which included group and individual feedback.
• The analysis did not focus on comments provided, but rather EPDP Team’s response to the comments
• For Item A, what is in the box will be included. On legal/natural – nothing would be included. City field – box text. Data retention – box text. OCTO – box text. Feasibility – nothing. Accuracy – include the conclusion. For Purpose 2 – box text.
• Presume we will see a timeline for when we will submit comments on Final Report and deadline to submit minority statements.

3. Confirm next steps

7. Final Report preparation (10 min)

1. Overview of status of Final Report

• Draft Final Report is already available for your review: https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2?preview=/132940331/137921078/EPDP%20Phase%202%20-%20%20Final%20Report%20-%2010%20June%202020.docx
• Team still needs to discuss the timeline for minority statements – Leadership team to discuss.
• Re: Final Report – the focus is on the review of recommendations. There are other parts in the report that are updated as well – covering the public comment period and other editorial changes.
• Need further guidance with respect to Section 3 – for example, there were graphics in this section – should this be updated or removed?
• Also, expected benefits of SSAD – should this be updated or removed?
• Main roles and responsibilities – is it helpful to keep this here?
• Study on legal v. natural was delayed – can we find a time certain of when this study will be provided to the EPDP Team?
• Action: Org liaisons to follow up on expected receipt of legal v. natural study.

2. Flag open questions not related to recommendations
3. Confirm next steps

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

1. Tuesday 16 June at 14.00 UTC (tentative). Topics to be addressed: items flagged for EPDP Team guidance.
2. Confirm action items

1. Confirm questions for ICANN Org, if any