Dear EPDP Team,

In order to facilitate your review of the input received on recommendation #6 – CP authorization, please note that the staff support team has reviewed the proposed changes and applied these as redline changes to the recommendation (see https://docs.google.com/document/d/1F0wmMEh6gopJVsDFDF5pe5mGAUHhr9CV/edit?ts=5ef29d26). In line with the approach used for previous input, we have applied color coding to the comments provided:

• Green – change applied as suggested.
• Orange – change applied to address the concern expressed but either no alternative wording was provided, wording was modified to align with terminology used in other parts of the report or wording was applied as suggested by another group who flagged the same issue / sentence.
• Yellow – further clarification / input sought from EPDP Team.

Please review this updated version and the proposed staff support team approach for addressing the input provided. If you cannot live with updates made or the suggested approach, please flag this accordingly and provide suggestions for how the concern expressed can be addressed instead. Also, please provide your input on the comments/questions highlighted in yellow so it may be possible to identify a path forward ahead of the next call.

Your input is requested at the latest by Monday 29 May.

Best regards,

Caitlin, Berry and Marika

From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org>
Date: Tuesday, June 23, 2020 at 19:39
To: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org>
Subject: [Gnso-epdp-team] Notes and action items - EPDP Phase 2 Meeting #67 - 23 June 2020

Dear EPDP Team:

Please find below the notes and action item’s from today’s call.

The next EPDP Phase 2 meeting will be Tuesday, 30 June at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin

Action Items

1. EPDP Team to provide input on remaining outstanding items (starting at item 63) by Monday, 29 June.
2. EPDP Team to provide input on Rec. 6 (if not yet provided) by COB TODAY, 23 June.
3. EPDP Team to review other groups’ input on Rec. 6 and note if proposed updated text by other groups can be accepted by Monday, 29 June.
4. Amr to propose alternate texts for Item 59 (confidential requests language) by Monday, 29 June.

EPDP Phase 2 - Meeting #27

Proposed Agenda

Tuesday 23 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)

• Support Staff has published updated Rec. 19 based on the Small Team’s conversation
• There seems to be an issue on what is policy and what is implementation – some groups believe that added automation use cases are always policy and not automation
• This proposal is not dead, but it is silent on too many matters
• Rr alternate did not agree to this proposal
• The Small Team needs to add some clarity on the Rec. 19, including the scope

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

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

Recommendation 9 SLAs

• Item 45 - Can the EPDP team please confirm whether the SLAs described in this table will be the required SLAs or if these are still subject to discussion during the implementation phase, as indicated in the heading noted here?
• 85% at 6 months, 90% at 12 months, and 95% at 18 months
• What does the percentage apply to?
• If there 100 requests, you would take the lowest 15 out, and average the other 85, and that would get you the SLA number
• The confusion arises when this was first proposed - where we landed, for 1 and 2 there are percentage measurements, and for 3 – those are the ones that have the more complex computation. 1 and 2 are being calculated separately and in a different fashion than 3.
• Item 47 – EPDP to confirm it meant business days as defined in CP’s jurisdiction.
• There is not a clean tie b/w non-LEA priority and CP’s jurisdiction. It’s not OK for an LEA request to be subject to a four-day weekend.
• For business days, some agreed that it was too long. CPs noted that without a limitation on to who can submit, they cannot accept the 24 hours, so Support Staff reverted this back to business days.
• Support Staff inadvertently did not apply the 1 business day requirement.
• ICANN closes its office at the end of December for a week, this would be unworkable solution for urgent requests. For a constructive suggestion – can we leave this as 24 hours? Second suggestion – if we need to somehow have this as a business day, what does the group think of the concept of a business day (but in any event no longer than one calendar day)
• If you cannot control who can make the request, they have to be bound by business days, but they have already been pre-approved for submission of requests in this category.
• Business days correspond with public holidays – not when your company decides to take a holiday.
• The attempt at a compromise is that we would recognize business days but have a cap (not to exceed five calendar days). Some companies that will be responding to these requests are not 24/7 operators. If it is a true emergency, the requestor should team up with an entity that can make emergency requests.
• Priority 1 cases are abuse cases, and registrars need to respond within 24 hours under the RAA
• There is a difference b/w law enforcement request that is 24 hours and the SSAD urgent requests that is open to others
• Agreement on (1 business day - not to exceed 3 calendar days)
• Item 48 - Urgent request SLA - change 24 hours back to 1 business day
• Item 43 – SLAs are included in the contract b/w ICANN and CPs – these SLAs will be reviewed as we learn through the mechanism.
• Clarifying point – re: Rec. 19 – the mechanism can trigger a bilateral negotiation b/w ICANN and the contracted parties but the mechanism cannot change the SLAs in order to respect the picket fence. “as updated from time to time per the process described in Rec. 19.”
• The SLA matrix is a template that is supposed to be used b/w ICANN org and the CPs to implement in a negotiation w/CPs. This won’t be binding b/c it can still be negotiated.
• The Team thinks this is what the SLAs should be – if it not sufficient, it will be changed through the mechanism
• Not comfortable how SLAs are being ported over to Registrars and ICANN where other groups will not have a say – there is a big issue over the affordability of the SSAD
• Misunderstanding re: picket fence and what is within it. Section 1.2.2 of the RAA – functional and performance specifications of registrar services. Do not need separate negotiations to change the SLA. Once the SLAs are part of the policy, it becomes part of the contract.
• The definition of picket fence in the contract has changed.
• Is it the Team’s agreement making these SLAs binding as a matter of policy, but it seems the Team is saying go negotiate this separately as part of the policy.
• ICANN org should do whatever is needed in terms of existing processes
• Understanding and intent is different – the numbers here are the policy and these will be the SLAs as soon as these are adopted by the board, and future changes will happen as part of the rec. 19 process (and subsequent bilateral negotiations)
• SLAs are implementation, not policy
• Now understand that these requirements will be binding as a matter of policy
• We have initial SLA values that are in the policy and they can’t be changed in the implementation, and there is a negotiation process for future changes
• Recommendation 10 – 12 – 14
• SSAD terms and conditions may need to be updated – suggestion was to add text that SSAD terms and conditions may be updated through the mechanism.
• RySG noted that Rec. 19 may not be right place for these updates.
• Is there general agreement that these terms and conditions can change over time?
• This comment came from the BC and Rys responded. Perhaps pose the Ry question to the BC.
• This might be outside of the MfE, and the flexibility of the SSAD operator is different than that
• No objection to terms being added by ICANN
• Recommendation 11 – Disclosure Requirements
• CPs and SSAD – Org notes that SSAD must comply with requirements for c, d, e, f – could the Team clarify what applies to whom?
• Does this mean we are negotiating the terms and conditions of the co-controller agreements, or is this deferred to implementation?
• Working assumption that ICANN org and CPs are joint controllers and they would negotiate the joint controller agreement among themselves
• ICANN is asking if by SSAD we mean the CGM, and the other part is they are looking for clarification on do the parts of the recommendation really all apply to SSAD or just to contracted parties
• What ICANN is trying to understand – some requirements seem odd if they apply to the identity provider to the accreditation authority
• SSAD should be the central gateway manager
• If the Team means more than the CGM, it should say so
• Item 59 – changes around how confidential requests are dealt with – this language was developed by a small team that the group helped review
• The goal of this was to add normative language, and this resulted in a change. Not wedded to this language, but still looking to insert normative language
• Prefer language proposed by IPC/BC
• This is something Chris and James worked out and this looks like a material change to what was agreed upon
• Can “CAN” be changed to “MAY”?
• There are cases where even where the LEA requests it to be anonymous, the data subject’s rights trump that.
• Object to MUST at the end of the sentence. If under your local law, you don’t have data protection legislation at the national level? This does not make sense.
• Item 60 – any concerns deleting footnote 49?
• No – agreement to delete.
• Item 61 – how could this be implemented?
• If it’s not a cannot live with item, suggest not spending additional time on this.
• Item 62 – what is expected in terms of redress – is this a reexamination request? RrSG – agree that this is similar to reexamination requests.
• This text is about when a requesting entity is flagged as submitting abusive requests – if a determination is made to throttle that user, the user can seek recourse, but this recourse is not the same as a reexamination request in Rec. 6
• Item 63 – there should be a similar recommendation that applies to CPs – must not reject requests that have not been flagged as abusive by the SSAD
• Until the Team sees the co-controller agreement, it cannot put coercive language in the text
• Keeping original text – no update accepted.
• Item 64 – what does appropriate access mean?
• Everyone should be able to see their own numbers – there is no reason for one requestor to see another requestor’s stats, or discloser to see another discloser’s stats, except in an aggregate.
• Could Volker say – I want to see all the requests sent to James? Who can see what on the CP side?
• Common sense – you can see your own data, but not other people’s data
• When envisioning seeing the data, it was meant to see your own data (requestor’s can see their data, and CPs can see their own data)
• This should be included in the last two items on the next call (63-64)

2. EPDP Team feedback
3. Confirm next steps

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

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

• EPDP Team to provide input on remaining outstanding items by Monday, 29 June.
• EPDP Team to provide input on Rec. 6 (if not yet provided) by COB TODAY, 23 June.
• EPDP Team to review other groups’ input on Rec. 6 and note if proposed updated text by other groups can be accepted by Monday, 29 June.
• Amr to propose alternate texts for Item 59 by Monday, 29 June.

1. Confirm questions for ICANN Org, if any