Dear EPDP Team:

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

The next EPDP Team meeting will be tomorrow, 17 June at 14:00 UTC.

Best regards,

Marika, Caitlin, and Berry

--

Action Items

1. For those EPDP Team Members who have not completed homework item below, please complete ASAP today:

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.
1. Support Staff to update the draft Final Report in line with today's discussion.
2. EPDP Team to confirm whether there are other provisions, in addition to 1.4d, that should be referenced in 1.7(b).
3. RySG to review the clauses from Item 4 (1.2c and 1.3e) offline and respond to the questions from ICANN org.

EPDP Phase 2 - Meeting #64

Proposed Agenda

Tuesday 16 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 deliberations on recommendation #19 (mechanism for SSAD evolution)

• Small Group met yesterday and discussed the scope of the mechanism. There appears to be an understanding on four out of five items, but the group is still discussing the scope of automation.
• The second discussion point is the method of the mechanism – how it would be formulated and who would be responsible for reviewing.
• The group is currently split according to party lines.

4. Commence run through of yellow items (items identified for further discussion / clarification)

1. Consider yellow items identified for recommendations (commencing with rec #1 and moving down the list)

• The document on screen has been circulated; the document includes items Staff Support had already flagged as well as the additional items that had been flagged by the groups.
• Some groups may not have gone through all of the recommendations yet. Please flag in the chat which recommendations are still outstanding by your group.
• The homework we asked the groups to do – identify what items they could not live with or minor edits.
• Staff, with leadership, worked together to propose a path forward for each item. Items flagged as yellow is where further information is sought, or we thought it may create a cannot live with item for other groups.
• For each recommendation, we included a separate table, groups were asked to review the tables and flag “cannot live with” items
• This list is a compilation of yellow items as well as items that groups flagged as saying this has created an issue for us.
• Every group was asked to review the approach and flag “cannot live with” items
• NCSG may want to check that input was provided in all recommendations

• Item 1 – 1.7 of Rec. 1:
• ICANN org – 1.7(a) – this seems to be redundant to Recs. 10-13-14 – would EPDP Team consider referencing those recommendations to provide greater clarity and avoid duplication?
• For RySG, not OK with just removing this. In comparing this with Recs. 10-13-14, it does not seem to overlap. Split on whether it’s better to leave where it is or move to Recs. 10-13-14, but agree that it should not be deleted.
• At worst, it’s redundant. At best, it’s makes the recommendation clearer and includes items not included in Recs. 10-13-14
• It may be helpful to make clear what is not included in Recs. 10-13-14 so that this does not result in different terms and conditions for different users.
• No change. Leave as is.
• Item 2 – comment made by RySG, adding a parenthetical, noting that number of SSAD requests will not be restricted (except where…)
• Agree to this in principle, but have it be limited to otherwise permitted under Rec. 1.4(d)
• Already limited to as is permitted under the recommendations – this should be acceptable
• If we are deleting the parenthetical, NCSG does not agree.
• BC: if the policy language is “search through the entire document and find places where it might conflict”, do not agree.
• NCSG: willingness to trust Staff to go through this and discuss changes is quickly waning – putting rate limitations is reasonable here.
• There may be some unresolved systemic issues, and the minor details that we are spending time on may not be the best way to spend the teleconference.
• Either Staff or we have to go through the recommendations to see what is not covered under 1.4
• Suggest keeping language as suggested by BC.
• or where they may be otherwise permitted under recommendation 1.4(d).
• Suggestion to replace “or where they may otherwise permitted under these recommendations” with “where they may be otherwise permitted under recommendation 1.4(d)”
• Staff to mark this and review the policy to determine what, if anything, also needs to be included
• The problem is not what is in the parenthetical but what comes before that, but the way the current language reads, it includes what is in 1.4(d) – do not understand why this needs to be replaced.
• The list should be in 1.4(d) – if not, it will get confusing in the IRT.
• Action: EPDP Team to confirm there are no contradictions in the BC-proposed language
• Item 3 – ALAC comment for the footnote – what does it mean that the verification will depend on the type of applicant? Having different levels of verification seems problematic. Suggest removing last sentence from FN 12.
• Agreement to remove the sentence.
• Item 4 – relates to two sentences – 1.2c and 1.3e that discuss a privacy policy. ICANN org – this seems to revisit language that was replaced in 1.2c – what is the difference b/w 1.2c and 1.3e – are they duplicative?
• Having trouble seeing the conflict that is being flagged. The existing language deals with a privacy policy, while the suggested addition deals with terms of service for the accredited entity. What is the conflict b/w these two different provisions?
• 1.2c and 1.3e do seem duplicative, but they are not the same as the comment from RySG.
• If you scroll down on the righthand document – the issue is that the language in 1.2c was replaced to clarify what a specific privacy policy. In 1.3e, there is a reference to terms of service, suggest updating 1.2c to cover the privacy policy and the terms of service.
• Question to RySG – should this say terms of service?
• If the Accreditation Authority is a processor, they will not be developing a privacy policy. Uncomfortable with this specific privacy policy that they’re free to develop.
• Action: RySG to review the clauses from Item 4 offline and respond to the list following this call.
• Item 5 (Rec. 3)
• MUST include all information necessary for a disclosure decision – question from ICANN org – to clarify for implementation purposes – could a request refer to a signed assertion which may provide all information in b, c, d
• RrSG, IPC – yes, this may refer to a signed assertion
• No additional input provided
• Item 5 (Rec. 5)
• Differences of understanding when information is relayed to CPs. What, if anything, is relayed to the CP when it concerns a request that meets the criteria for an automated disclosure decision? Staff’s understanding is that the disclosure request would still be provided to the CP for its records. This relay could be provided at the same as the CP is asked to disclose or at another time.
• RrSG: expressed support for Staff’s understanding
• IPC: do not agree with understanding, as for automated disclosure, CPs do not need the information, and having the information could open the CP to more liability
• ALAC: information should not go to the CP
• RySG: leave language as is
• IPC: for decisions that are centralized and/or automated, those are decisions that the CP does not have liability for the disclosure. For those requests, the liability will be centralized, and the CGM will be deciding on the request. In this world, it is unclear why the CP would want to expose itself to more liability by getting the information.
• Working under an assumption that there is no liability for CPs under certain use cases, but we do not know if this is accurate or not. Do not see how providing the data to CPs increases the CPs liability. Assume that CP involved would want records on the disclosure request.
• The CGM does not have the data, it will have to go to CP. Everyone should reread the memo from B&B, where it provides that there would be less liability but not no liability. CPs needs to have information on when data was disclosed and for which reason to fulfill legal obligations.
• When a request is filed, the CGM determines whether the request is eligible for an automated response or not. If not, an acknowledgment of receipt is sent to the requestor, and the request is sent to the CP. If the request falls in the scope of automated decisions, then the CGM sends the CP the request and an indication that it falls in the scope of automated decisions.
• What will be key to CPs not having the joint and several liability under the micro approach is that they’re not involved in the same processing.
• When we discussed how the data should travel, the following principle of data minimization, we decided that CPS will send the data directly to the requestor, so that is why the proposal that CGM does not make automated decision maker but just indicates to CP that request falls within scope of automated decision making. Then computer of CP gathers data and sends it in a secure way to the requestor. This is what is currently in the recommendations, and we should stick to it.
• The group is conflating a bunch of issues in the B&B memo.  It identified a small number of places where automated processing is permitted (either because the data is not personal, or because the Cps review a recommendations, etc. I don’t think it ever said that the Cps were not potential controllers in all of those scenarios. The point is, that the memo was about permissible automation - where the data is not personal or where the decision making is not automated.
• Propose leaving the recommendation as is.
• Item 7 – Footnote 23 is currently worded as implementation guidance, but IPC believes it should become part of the policy recommendation.
• Footnote 23 reads better as implementation guidance.
• We are discussing Footnote 23 – suggestion to move that as a policy recommendation – did not apply this b/c Staff Support was not sure there would be agreement to do this. Is there a concern re: moving this to the policy portion, or is the Team comfortable leaving it in implementation guidance.
• Concerned with “it may be provided at another point”.
• The explicit statement saying “provided at another time” – have a problem with.
• In moving the implementation guidance up, the policy would benefit from clarity.
• Recommend keeping the footnote as is with the implementation guidance footnote and move on.
• Afraid that this language conflicts with the recommendation for automation. This is silent as to the most important use case for processing. Cannot live for this without a carve out for cases that are automated.
• Rec. 5 is lacking “for requests that are not automated,” the CGM must relay the disclosure request to the registrar.
• CGM does not possess registration data. When the request comes in, all CGM does is if the request should be reviewed manually or should be reviewed in an automated way.
• One issue is the reference is registrar of record – this is something that Staff overlooked – we could change this to the CP instead of registrar of record. This purely speaks about relay of the disclosure request – understand that it needs to be relayed in both instances.
• Maintain language of Rec. 5 as shown on the screen and do not change the footnote.
• Item 8: bullet e – if the CP determines disclosure…CP must document rationale and communicate to requestor and CP. Question – does the rationale only need to be communicated to ICANN Compliance if requested?
• Agree with Rr input, but wondering if ICANN org has something else in mind?
• No, ICANN org did not have an alternative in mind. Is the “if requested” only ICANN Compliance or also the requestor?
• If requested refers only to ICANN Compliance. Consider moving the (if requested) to before ICANN Compliance
• Items 9 – 10
• Relay of request by default to RoR but identify circumstances where it would also go to the Ry. Some believe it should be at the requestor’s discretion to choose Rr or Ry. Outlined some scenarios for when the request may be relayed to the registry. Specific examples included caused issues with the CPs.
• Thought that we had agreed on a hybrid model where requests are sent to a centralized point. The idea that the CGM can issue recommendations is one of the workable halfway houses b/w people who are not OK with a decision made by the CP.
• The idea behind making the recommendation – if we were to have a mechanism to evolve this, knowing the CGM had already got the decision right and agreed with the CPs would make for an easier evolution.
• Records of disclosure request have to go to the Rr as well, even if the request is being processed by the Ry.
• The CGM still makes the determination, but there has to be a fallback – some Rrs may not have an SSAD connection. How the CGM makes the determination can be left to implementation.
• Can live with text displayed on the screen.

2. EPDP Team feedback
3. Confirm next steps

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

1. Wednesday 17 June at 14.00 UTC. Topics to be addressed: continue run through of yellow items.
2. Confirm action items

1. Confirm questions for ICANN Org, if any