Dear EPDP Team:

Please find below notes and action items from EPDP Meeting #35 on Thursday, 12 December 2019.

The next EPDP Team meeting will be Thursday, 19 December at 14:00 UTC. The Legal Committee will meet on Tuesday, 17 December at 15:00 UTC.

Thank you.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. EPDP Support Staff to update the Terms of Use Building Block to change “data processing agreement” to “disclosure agremeent” by Friday, 13 December.
2. EPDP Support Staff to include a footnote in the Authorization Provider Building Block, noting the Team will return to the discussion once a decision on who will be the authorization provider by Friday, 13 December. EPDP Team to revisit the “should vs. must” discussion following additional guidance from ICANN org.
3. EPDP Support Staff to include implementation guidance on examples of online and offline infrastructure. EPDP Team to provide examples within the updated text by Wednesday, 18 December.

Upcoming Review Deadlines

Date	What	Topic
17 December 2019	Deadline for comments and suggestions	Initial Report language on: Purposes Acceptable Use Policy
19 December 2019	EPDP- Phase 2 call #36	Address comments / suggestions received by deadline on: Purposes Acceptable Use Policy

EPDP Phase 2 - Meeting #35

Proposed Agenda

Thursday, 12 December 2019 at 14.00 UTC

1. Roll Call & SOI Updates (5 minutes)

2. Confirmation of agenda (Chair)

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

a) Status of building blocks

4. Preliminary Rec #11 – Terms of Use (20 minutes)

a) Review updates made as a result of previous meeting

• Support Staff added explanatory text to explain the different types of documents.
• The changes during the last call are an improvement. The note at the top of the building block is a good start to help explain. Data processing agreement seems incorrect – this should be the disclosure agreement b/w the disclosing entity and the entity requesting data.
• Action: Support Staff to update data processing agreement to disclosure agreement in the explanatory text.
• No additional comments, this building block can be closed for now.

b) Review any remaining comments/suggestions

c) Feedback from EPDP Team

d) Confirm next steps

5. Preliminary Rec #14 - Automation

a) Review comments / suggestions provided by deadline

• Comment from NCSG: At worst, you want to say "may" be automated, it is not a consensus policy ever, that it "must" be automated. Suggest rewording to:

"The EPDP Team recommends that those aspects of the SSAD identified below may be automated where both technically feasible and legally permissible."
• If automation is legally and technically feasible, that is what the system should do.
• The use of the word “must” is too absolute. Must should be replaced by “may”, as this provides flexibility and would not prohibit automation.
• Automation will be very helpful in a lot of ways, and if it can be done, it will be beneficial. However, the decision of what is automated should have flexibility – “must” should be changed to “may” or “should”
• At this point, it’s not clear where these decisions will be made. If automation is taken away, that will take a lot of the usefulness of the SSAD.
• The current wording of the language builds in discretion. Strongly believe this language has to be a “must”.
• There needs to be an indication of the Team’s intention here – for that reason, prefer “must”.
• This language was originally proposed to show that automation is allowed when technically and legally permissible.
• It does not matter what the ultimate model is
• Concern with “must” causing issues with compliance in the future
• If ICANN is the centralized discloser, the language may not be as objectionable
• Proposal to add footnote, noting that this language will be revisited once the Team decides who will make the disclosure decision.
• Action: Support Staff to add footnote: that makes clear that this language will be revisited once a determination has been made who is the authorization provider and note that some think it should be may instead of must.
• Comment on: The SSAD must allow for automation of the processing of well-formed, valid, complete, properly-identified requests from accredited users with some limited and specific set of legal basis and data processing purposes which are yet to be determined. These requests MAY be automatically processed and result in the disclosure of non-public RDS data without human intervention.

• Objection with the “must” – cannot have a permissive statement and add a “must”
• Change the “must” to a “should” would be acceptable. However, this seems duplicative to the first paragraph.
• Strong “must” language is better for enforcement and explains what the policy is. There needs to be “must” language in the policy.
• “may” language could disappear in implementation
• “Disclosing entity” should be changed to “authorization provider”
• In Consensus policies at ICANN, the IETF definitions are used (RFC 2911)
• Cannot have rigidity here, as this relates to a principle-based law
• There is a safety valve already included
• It may be helpful to identify specific portions that must be automated
• Await guidance from ICANN org on “should” vs. “must” and revisit once guidance is received
• ICANN org liaisons comment: For implementation purposes, who would determine that automation is "both technically feasible and legally permissible," and when would that occur?

• This is an excellent question the Team has been dancing around – the controller has to have an override on an automated system. A DPIA would have helped with this issue.
• Action: ICANN org question can be deferred for later once more details are worked out

b) Feedback from EPDP Team

c) Confirm next steps

6. Preliminary Rec – Response Requirements

a) Review comments / suggestions provided by the deadline in relation to edits discussed previously

- [online and offline]

- Concerned that others who are reading this would not know what “online and offline” means

- may be helpful to include examples

- If a requestor is of the view that its request was denied erroneously, a complaint could be filed with ICANN Compliance.

- Object to second sentence

- If ICANN compliance is not the arbiter, then who is?

- The first sentence of the paragraph deals with the requestor. Could change: ICANN Compliance should be prepared to investigate complaints about disclosure requests handled erroneously.

- Question from ICANN org – this statement assumes that the CP is disclosing the data

- If there is a complaint for every refusal, this would be a problem.

- Action: put a pin in this when it is determined who will be making the disclosure decision

b) Feedback from EPDP Team

c) Confirm next steps

7. Preliminary Rec # – User Groups

d) Review comments / suggestions provided by deadline

• Important to have user groups
• Language is too vague – there is no detail in the accreditation policy

e) Feedback from EPDP Team

f) Confirm next steps

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

a) Thursday 19 December at 14.00 UTC

b) Confirm action items

c) Confirm questions for ICANN Org, if any