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 Automation 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: EPDP Leadership to further consider the appropriate channel to further consider the geographic differentiation issue. EPDP Team may continue to provide comments on the structure, formatting, and diagrams within the Initial Report Google Doc in comment mode (please refrain from line edits in the document). EPDP Team to provide additional comments (if any) on the Authorization Provider Building Block by Friday, 6 December. EPDP Support Staff to propose compromise text, where possible, in response to the Team’s discussion and additional comments for the Authorization Provider Building Block for the Team’s review by Monday, 9 December. Questions for ICANN org: 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
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@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org> Date: Friday, December 6, 2019 at 8:29 AM To: "gnso-epdp-team@icann.org" <gnso-epdp-team@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
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@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org> *Date: *Friday, December 6, 2019 at 8:29 AM *To: *"gnso-epdp-team@icann.org" <gnso-epdp-team@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@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.
This is a note from the SSAC team. Volker frames this is a discussion about changing from SHOULD to MUST – but the opposite is true. The existing Consensus Policy says “MUST” and received the endorsement of the community and was approved by the GNSO and the Board. Attempts to change to “SHOULD” will overthrow that consensus, and are not justified. Aleeza’s notes are logical. The Temp Spec is Consensus Policy, and it says: “5.1. Publication of Registration Data. Registry Operator and Registrar MUST comply with the requirements of, and MUST provide public access to Registration Data in accordance with, Appendix A attached hereto ("Appendix A").” And Appendix A says: “4.1. Registrar and Registry Operator MUST provide reasonable access to Personal Data in Registration Data to third parties on the basis of a legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.” There is no reason to go with “SHOULD”. If we use a MUST, and the registrar (or whoever) determines that the balancing test has not been met, it will not disclose. If the registrar (or whoever) determines that the balancing test has been met, then it MUST disclose. Because 1) that’s compliant with GDPR, and 2) that’s the reasonable expectation of the ICANN community, which expects contracted parties to participate, for all the good and justified reasons explained in Section 4 of the Temp Spec. We suggest the group focus on a solution to the real problem: what happens when a contracted party and a requestor disagree about whether the balancing test has been met. There will be honest disagreements between parties about whether a given case meets the balancing test. There will be cases where a contracted party withholds because it does not understand how to do the balancing test properly. (There are over a thousand contracted parties around the world, some of whom are not adequately educated or staffed to fulfill this function.) There will be contracted parties who are unreasonably conservative. And there may be contracted parties who will refuse disclosure for bad purposes, for example to hide malicious activity. What we know is that ICANN Compliance is not in a position to adjudicate balancing cases. There were some ideas floated in recent meetings about what to do here, and this area needs further work. For example, it is reasonable to require the disclosing party, upon request, to explain its reasons/justification for not disclosing the data. (And ICANN Compliance can be involved in this objectively, ensuring that the justification is shared.) As an escalation step, some sort of mandatory mediation could be useful. Such solutions can help educate the parties, which is always a helpful outcome. We do need a solution here, and a balanced one. Third-party requestors are recognized under GDPR and should have some recourse. It’s not balanced when a controller can deny any and all requests and can’t even be questioned about it. All best, --Greg From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Volker Greimann Sent: Thursday, December 19, 2019 5:20 AM To: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Action Items + timeline with upcoming deadlines for feedback 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 <https://tools.ietf.org/html/rfc2119> RFC 2119. 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 <https://tools.ietf.org/html/rfc2119> RFC 2119 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 <mailto:gnso-epdp-team-bounces@icann.org> <gnso-epdp-team-bounces@icann.org> on behalf of Caitlin Tubergen <mailto:caitlin.tubergen@icann.org> <caitlin.tubergen@icann.org> Date: Friday, December 6, 2019 at 8:29 AM To: <mailto:gnso-epdp-team@icann.org> "gnso-epdp-team@icann.org" <mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@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@icann.org <mailto:Gnso-epdp-team@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 <http://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.
participants (4)
-
Caitlin Tubergen -
Eleeza Agopian -
Greg Aaron -
Volker Greimann