[Gnso-epdp-team] Action Items + timeline with upcoming deadlines for feedback
eleeza.agopian at icann.org
Thu Dec 19 01:00:55 UTC 2019
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.”
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:
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)
Marika, Berry, and Caitlin
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnso-epdp-team