[Gnso-epdp-team] Action Items + timeline with upcoming deadlines for feedback

Thu Dec 19 10:19:31 UTC 2019

Hi Eleeza,

we discussed this differentiation ad nauseam during on a different topic 
our last call and were unable to come to consensus to change to must. I 
suspect that this proposed change would lead to various parties to 
withdrawing their consensus on the recommendation. The recommendation 
was not written with compliance enforcement in mind as the most 
important goal but rather to create an expected outcome.

Further, even when including limiting factors to a "must" 
recommendation, these are not likely to be sufficient as this area of 
law is constantly evolving.

As for the higher burden on ICANN resulting from the reasonability test, 
this seems intentional to me. Enforcement should not be the norm but a 
result of special circumstances where unreasonableness can be 
demonstrated without reasonable doubt.

I therefore do not support the proposed change.

Best,

Volker

Am 19.12.2019 um 02:00 schrieb Eleeza Agopian:
>
> Dear EPDP Team,
>
> Thank you for the question you sent to ICANN org on 6 December 2019 
> regarding the potential enforcement of a “SHOULD” directive within an 
> ICANN policy, specifically, the proposed draft recommendation text 
> which initially read,  “If, based on consideration of the above 
> factors, the authorization provider determines that the requestor’s 
> legitimate interest is not outweighed by the interests or fundamental 
> rights and freedoms of the data subject, the data should be 
> disclosed.” We understand that the team agreed to the following 
> language on its 12 December 2019 plenary call: “If, based on 
> consideration of the above factors, the authorization provider 
> determines that the requestor’s legitimate interest is not outweighed 
> by the interests or fundamental rights and freedoms of the data 
> subject, the data *shall* be disclosed. The rationale for the approval 
> should be documented.” While the team’s discussions have resulted in 
> changing “SHOULD” to “SHALL,” we are providing this answer to close 
> the loop on the team’s outstanding question.
>
> We note that this question was directed to ICANN Contractual 
> Compliance and seems to assume that ICANN Contractual Compliance would 
> have the contractual right to enforce such a requirement. However, in 
> order to determine how or whether such language could or would be 
> enforced by ICANN, we would need to know who the authorization 
> provider is. For example, if the EPDP Team were to recommend that 
> ICANN org play the role of authorization provider, ICANN would not be 
> in a position to enforce its own compliance with such a requirement. 
> Alternatively, if one or more third parties was the authorizer(s), 
> then ICANN Contractual Compliance would not be involved in enforcement 
> since compliance is only involved in gTLD registry and registrar 
> contractual compliance enforcement. If contracted parties were 
> required to act as authorizers, ICANN org would enforce such a 
> requirement pursuant to the contracted parties’ agreements with ICANN.
>
> We believe that it would be difficult to enforce the proposed “SHOULD” 
> obligation without clearly defined limitations on when “SHOULD” would 
> not mean “MUST,” provided the word “SHOULD” is defined as in RFC 2119 
> <https://tools.ietf.org/html/rfc2119>. From the Compliance 
> perspective, a requirement framed as “MUST,” which could be 
> potentially limited by qualifying factors (such as “unless one of the 
> following conditions applies”), could be more predictably enforced.
>
> “SHOULD” is defined in RFC 2119 
> <https://tools.ietf.org/html/rfc2119> as follows: “This word ... 
> mean[s] that there may exist valid reasons in particular circumstances 
> to ignore a particular item, but the full implications must be 
> understood and carefully weighed before choosing a different course.”
>
> For example, if the registrar is subject to a requirement that it 
> SHOULD disclose data, and the registrar contended that it decided not 
> to disclose requested data based on reasons it has identified as 
> valid, the registrar would not necessarily be found to be in violation 
> of a requirement that it SHOULD disclose data. This is essentially a 
> “reasonableness” test, but ICANN would face a significant burden to 
> demonstrate that a registrar was acting unreasonably.
>
> Based on the above, ICANN org strongly recommends the use of the word  
> “MUST,” with an accompanying list of defined exceptions, rather than  
> a “SHOULD.”
>
> Thank you,
>
> Eleeza and Dan
>
> ICANN org liaisons
>
> *From: *Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> on behalf of 
> Caitlin Tubergen <caitlin.tubergen at icann.org>
> *Date: *Friday, December 6, 2019 at 8:29 AM
> *To: *"gnso-epdp-team at icann.org" <gnso-epdp-team at icann.org>
> *Subject: *[Gnso-epdp-team] Action Items + timeline with upcoming 
> deadlines for feedback
>
> Dear EPDP Team,
>
> As shared during yesterday’s meeting, please find attached the 
> proposed timelines and deadlines to get to the Initial Report by early 
> February. As a reminder, please provide your input on the Initial 
> Report language on:
>
>   * Terms of use
>     <https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit>
>   * Automation
>     <https://docs.google.com/document/d/1KCzlakWVkt6GN5ZPl0my45WdR34JPes_bZwmJkY9Z3k/edit>
>
> by *_Sunday 8 December at the latest_*. The comments and suggestions 
> made by the deadline will serve as the guide for discussion during the 
> meeting on 10 December 2019. Please also take note of the other 
> upcoming deadlines to plan your work accordingly.
>
> Other action items and high-level notes for Tuesday’s meeting are:
>
>  1. EPDP Leadership to further consider the appropriate channel to
>     further consider the geographic differentiation issue.
>  2. EPDP Team may continue to provide comments on the structure,
>     formatting, and diagrams within the Initial Report Google Doc
>     <https://docs.google.com/document/d/1isn0eJsqw-g-qvqRbocM6849OWpFl0WG/edit>
>     in comment mode (please refrain from line edits in the document).
>  3. EPDP Team to provide additional comments (if any) on the
>     Authorization Provider Building Block
>     <https://docs.google.com/document/d/1XeHP_YZN7fR0LwQ4DzRuY9PqB39uOzHXot-yH0fcvbc/edit>
>     by Friday, 6 December.
>  4. EPDP Support Staff to propose compromise text, where possible, in
>     response to the Team’s discussion and additional comments for the
>     Authorization Provider
>     <https://docs.google.com/document/d/1XeHP_YZN7fR0LwQ4DzRuY9PqB39uOzHXot-yH0fcvbc/edit>
>     Building Block for the Team’s review by *Monday, 9 December*.
>
> Questions for ICANN org:
>
>  1. Could ICANN org provide detail on how/if it would enforce a policy
>     with a “should” directive? By way of example, how would the
>     following text be enforced? “If, based on consideration of the
>     above factors, the authorization provider determines that the
>     requestor’s legitimate interest is not outweighed by the interests
>     or fundamental rights and freedoms of the data subject, the data
>     /should/ be disclosed.” (emphasis added)
>
> Best regards,
>
> Marika, Berry, and Caitlin
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- 
Volker A. Greimann
General Counsel and Policy Manager
*KEY-SYSTEMS GMBH*

T: +49 6894 9396901
M: +49 6894 9396851
F: +49 6894 9396851
W: www.key-systems.net

Key-Systems GmbH is a company registered at the local court of 
Saarbruecken, Germany with the registration no. HR B 18835
CEO: Alexander Siffrin

Part of the CentralNic Group PLC (LON: CNIC) a company registered in 
England and Wales with company number 8576358.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20191219/a046f460/attachment-0001.html>