[Gnso-epdp-team] Notes and action items - EPDP Phase 2 Meeting # - 17 June 2020

[Caitlin Tubergen]

Dear EPDP Team:

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

As a reminder, the next meeting will be Thursday, 18 June at 14:00 UTC.

Best regards,

Marika, Berry, and Caitlin
--

Action Items

1. After reviewing the Team’s progress today, Leadership suggests we start with item 35 tomorrow and review Rec. 6 during our meeting on Tuesday, 23 June. In the meantime, Support Staff to rewrite/reorganize Rec. 6 in line with today’s discussion.

2. Laureen to propose alternate wording to footnote 9, factoring in the different positions expressed during today's call. FN9: Compliance will not be in a position to address the merits of the request itself or the legal discretion of the Contracted Party making the determination. Proposal to delete the last clause (or the legal discretion of the CP making the determination).

3. Margie to draft footnote for Rec. 4 regarding NIS EU law.

EPDP Phase 2 - Meeting #65
Proposed Agenda
Wednesday 17 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)



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

  *   Item 11 (Rec. 8)
  *   Proposed deletion of this sentence: Information resulting from the alert mechanism is also expected to be included in the SSAD Implementation Status Report (see recommendation #19) to allow for further consideration of potential remedies to address abusive behavior.
  *   Can this sentence be moved to the small team for Rec. 19?
  *   Proposal to add this element in the suggested scope of MfE
  *   RySG – suggestion was to delete this sentence entirely; however, proposed a compromise to, instead, add to the scope of Rec. 19. The small group should consider this.
  *   The focus of the mechanism is on implementation aspects only. At the moment, the abuse provisions are part of the policy, so there may be a need to move these elements to implementation. The small team should consider this.
  *   Footnote 9: ICANN Compliance will not be in a position to address the merits of the request itself or the legal discretion of the Contracted Party making the determination. Proposal to delete the last clause (or the legal discretion of the CP making the determination). Unclear what legal discretion means in this context. Additionally, if further guidance is received, ICANN Compliance may be in a position to review how the CP applied this determination.
  *   The footnote should be kept as is
  *   Believe ICANN Compliance expressed an unwillingness to do this
  *   Do not understand why CPs have difficulties with the bracketed language to be discussed in the evolutionary model. Troubled why this section is problematic at this juncture when it has been there for quite some time.
  *   Is there a way to rephrase this footnote – the legal discretion of the CP is not very helpful. Could contemplate scenarios where DPA guidance is received on how to apply the GDPR, whether it’s the balancing test or whether it’s in reference to other permissible lawful basis under Article 6. ICANN should be able to review if subsequent guidance is received. This language forecloses any role for ICANN Compliance to ensure CPs are abiding by the law.
  *   Do not think it is ICANN Compliance’s role or remit to ensure CPs are complying with the law. Need to ensure that policy recs are flexible enough so that CPS can comply with the law.
  *   ICANN Compliance does not interpret the law; ICANN Compliance defers to CPs to interpret the law.
  *   This conversation supposes that every case involves a balancing test; this is not correct – some evaluations do not involve personal data
  *   Confused if ICANN Compliance always grants a waiver if a CP believes it is following its local law – that does not seem correct.
  *   There are paths where data that is not covered by the GDPR is involved; however, you need to see if there is a valid case for disclosure for any case.
  *   Understand good CPs comply, but how do we deal with the bad CPs? The current language seems to give bad CPs a free pass. There is a CP that denies every request, irrespective of it’s a valid request.
  *   Action: Laureen to come up with alternative language for the Team to consider.
  *   Item 12: If a requestor is of the view that its request was denied in violation of the procedural requirements of this policy, a complaint MAY be filed with ICANN Compliance
  *   Significant issue for BC. If there is a situation regarding systemic abuse, there needs to be a mechanism to deal with this. Need the ability to submit substantive requests.
  *   This is a type of guarantee that cannot be given. Even if this language is erased, there is no guarantee that Compliance is going to do anything. You can only complain that CPs are violating the policy.
  *   ICANN Compliance MUST make available an alert mechanism by which requestors as well as data subjects whose data has been disclosed can alert ICANN Compliance if they are of the view that disclosure or non-disclosure is the result of systemic abuse by a Contracted Party. This alert mechanism is not an appeal mechanism – to contest disclosure or non-disclosure affected parties are expected to use available dispute resolution mechanisms such as courts or Data Protection Authorities – but it should help inform ICANN Compliance of potential systemic abuse which should trigger appropriate action
  *   This is not about guarantees; this is about forms of recourse. Being able to report on the number of alerts vs. number of requests will give us statistical guidance to assist in going forward.
  *   This provision is not just meant to address systemic abuse. If there is a domain name with no personal data, ICANN Compliance should be able to enforce disclosure.
  *   Cases where there is no personal data should not be denied; however, this is not a compliance issue – how would you even know if there is no personal data?
  *   The issue is Compliance is not willing to look at the substance.
  *   Item 13 - 14: awaiting GAC input on examples of urgent requests – GAC Team came back recently – no need to further illustrate the categories listed.
  *   Question for the group – any concern with GAC-proposed approach? Adding definition of critical infrastructure?
  *   Agree with GAC Proposal – leave four bullet points and reference the proposed definition in a footnote
  *   Item 15: Remove “or in another standardized place that may be designated by ICANN from time to time.”
  *   No objections – remove language.
  *   Item 16: MAY reassign the priority level during the review of the request, in accordance with the requirements above. Would the EPDP team consider instead that a request that does not meet the requirements for Priority 1 or 2 may be rejected and may be refiled?
  *   This would be an easier approach
  *   However, would not be open to also allowing for a longer response time instead of dealing with the same request twice.
  *   Idea of reassignment as part of evolution may be the right approach.
  *   The steps outlined in the recommendation are logical and could be followed and imposed
  *   Item 17: definition of Priority 2 requests - In Rec #NEW, Priority 2, can the EPDP team please clarify if this priority is intended to be available only to ICANN-approved dispute resolution service providers, or should it also be available to parties and potential parties in administrative proceedings?
  *   This is limited to providers
  *   Clarify this in the text
  *   Item 18: In Rec #NEW, Priority 3 seems to contemplate a bifurcation within this priority level resulting in 4 priority levels. For implementation purposes, the system would require a fourth category, even if the contracted party were to choose to treat the two priority levels the same. Would it make more sense to create a fourth priority level to allow for this?
  *   No need to create a new priority level. This language gives CPs the discretion to prioritize certain types of requests if CPs feel this is warranted
  *   This is not a new priority level, this is a flag that could be put on a request
  *   Leave as is
  *   Item 19: In Rec #NEW, a. Abuse of urgent requests: For clarity during implementation, does the EPDP team contemplate any recommendations regarding abuse of the use of other priority levels? For example, what if a requester regularly incorrectly cites Priority 2, and those requests are downgraded. Would that be considered abuse?
  *   If we limit the ability of Priority 2 requests to providers, this danger is negligible
  *   No change necessary
  *   Item 20: Rec. 4
  *   Either delete “Digital service provider (DSP)” or clarify what the intended purpose is.
  *   Should not use these terms unless we define what we mean
  *   Do not understand this as a requestor purpose
  *   Keep digital service provider, add a footnote reference for NIS
  *   How does this relate to a purpose for disclosure of registration data?
  *   Purpose is fulfillment of a legal obligation
  *   Even if there is a definition, that does not make it a purpose. Criminal investigation is a purpose; criminal law is not
  *   Margie to draft footnote for Item 20
  *   Item 21: Unclear that the reference to Paragraph 9 is appropriate.  If there is no personal data involved (and not otherwise prohibited by law), the requested data must be disclosed
  *   The change in order has asked the disclosing party to process personal data where it doesn’t have a reason to do so at that stage. When CP gets a request, the CP has to perform a prima facie case to see if it’s a valid request. By changing 7 to number 1, it is creating a legal risk – process should revert back to how it was.
  *   Phase 1 allowed information that is not subject to GDPR to be redacted. SSAD is the way to get access to data that doesn’t need to be redacted. If we can’t do this, we are weakening our ability to comply with GDPR but not over-comply with GDPR.
  *   Couldn’t the CGM’s completeness and syntax check + accreditation allow for the basis to check the data?
  *   This list should not be a step by step, so the order doesn’t really matter – just have to follow steps in a way the individual CP feels is appropriate
  *   Still receive requests that state “give me the data b/c I have a trademark” – if that is the basis of the request, can’t look if there is personal data b/c do not believe that is an appropriate legal basis.
  *   If the CP denies the request on some grounds unrelated to the fact that it is non-personal data when the data does not pertain to a natural person is unacceptable.
  *   Just heard that a request could be rejected before it’s assessed if there is personal data or not
  *   It is not just about what is lawful and what is not. A request can be rejected b/c it was filed improperly. If requestors submit the requests properly, this will not be an issue.
  *   Offered a cure for the problem of legal v. natural – would involve a thorough validation of legal entities – some sort of accreditation that demonstrates existence a company that would be globally applicable
  *   Consider adding – assuming the request is full and complete
  *   Alan Woods to provide example text
  *   Item 23: Delete “without reviewing the underlying data”
  *   Moving step 7 up materially changes the recommendation. The threshold determination in 5 no longer makes sense.
  *   These are steps that each CP must perform, but there is no requirement that they must be performed in this exact order.
  *   Item 24: Can the EPDP team please explain what is the purpose of making a threshold determination? The paragraph used to require a Contracted Party to “make a threshold determination without reviewing the underlying data.” Paragraph 5a) no longer includes this language. Further, Paragraph 7 no longer indicates whether the registration data ought to be evaluated together with the request, rather it only requires the Contracted Party to “evaluate the request.” It is unclear how Paragraphs 5a) and 7 are distinct. Can the EPDP team please clarify? Paragraph 7: ICANN org notes that there do not appear to be any mandatory requirements specifying what it means to “evaluate the request.” Accordingly, ICANN Contractual Compliance would only be able to assess whether the CP has conducted “an evaluation”. Can the EPDP team please confirm there are no mandatory requirements specified for this evaluation?
  *   First issue – if you delete “without reviewing underlying data” – confused about what the threshold determination is. What is the difference b/w this and evaluate? Thought steps were implied that go in a certain order.
  *   Since legal v. natural will not be addressed in Phase 2, the language in the Final Report may need to change.



  1.  EPDP Team feedback
  2.  Confirm next steps


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

  1.  Thursday 18 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200617/a8688e56/attachment-0001.html>