[Gnso-epdp-team] ICANN Compliance question in relation to EPDP Recommendation 7
matt at brandsight.com
Wed Jan 30 21:54:37 UTC 2019
Thanks Alan and I just wanted to respond and echo your sentiments below. I have reviewed the latest language for Recommendation 7 and it appears to be fine as written and in-line with our various discussions on the topic.
I appreciate the questions posed by contractual compliance below but do not feel like it’s part of our remit to determine which specific data elements might be needed by compliance going forward. As Alan point out, compliance would always have the option to ask for relevant data and provide a valid legal justification on a case by case basis.
From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> on behalf of Alan Woods <alan at donuts.email>
Date: Tuesday, January 29, 2019 at 3:44 AM
To: Marika Konings <marika.konings at icann.org>
Cc: "gnso-epdp-team at icann.org" <gnso-epdp-team at icann.org>
Subject: Re: [Gnso-epdp-team] ICANN Compliance question in relation to EPDP Recommendation 7
This appears to be along the lines and related to the issue which I raised regarding Recommendation 7. In this instance, I believe that the penny may have dropped. In truth, the ePDP team is working in a vacuum, and we cannot be hefted with the expectation that we shall somehow discern the data which is deemed necessary by the various elements within ICANN Org. As such we need to be told whether any stakeholder, ICANN included, has a justifiable need for data to be disclosed in furtherance of their function; with regards to this question from ICANN Compliance, it is, and always has been for them, (or any other, so motivated, stakeholder) to present and justify those needs for our consideration. We have tried to capture, as best as we can, the obvious uses, but to supplement this, the ePDP has sought input and indeed in this instance have specifically asked "How does ICANN Contractual Compliance use WHOIS data<https://community.icann.org/display/EOTSFGRD/Input+from+ICANN+Org>?". ICANN compliance have responded with their data processing overview<https://community.icann.org/display/EOTSFGRD/Input+from+ICANN+Org?preview=/90774122/97848455/Summary-Contractual-Compliance-Data-Processing-Activities.pdf>, and the only element of 'in-scope data' noted therein was 'redacted registrant data' (assuming to mean actual underlying unredacted data ) for both "compliance tickets" and "audit program" tasks. All other elements noted, from my reading, were either not personal data (e.g. ICANN approved DEA name) or personal data that fell under ICANN's sole controllership (e.g. PII relating to complaints made to ICANN compliance, or Contacts of DRPs).
Therefore in response to ICANN Compliance's questions (as I see them):
1) "is Recommendation 7 intended to limit all contractual requirements where ICANN is currently permitted to request information and records to only permitting ICANN to request the data elements listed in Recommendation 7’s chart" Yes. Such is the task we have. The workbooks are based on our experience, but mainly on the responses received; taking into account their responses, the ePDP defined and discerned what data elements we felt were reasonable for disclosure for the task of contractual compliance to request in furtherance of what we would believe to be the Contractual Compliance tasks. Where there is an issue, this should be raised and a small team is currently reviewing the workbooks and perhaps any necessary modifications can still be achieved.
2) "can the EPDP team please clarify which contractual requirements Recommendation 7 applies to and how they should be changed". Vis á vis ICANN Compliance, and recommendation 7, the ePDP is ONLY concerned with the data that is required to be transferred from CP to ICANN for the purpose of compliance; therefore, we are necessarily limited to that which is allowed in the RAs and RAAs. I'm unsure as to what other specificity is necessary here. If other data is necessary for ICANN compliance to do their task that they feel is not covered here, then they should provide detail. Additionally, it is not in the scope of the ePDP to suggest contractual amendments, that is a matter for ICANN and the CPH and we refer to our recommendations 13 & 14.
3) "may ICANN continue to request the information and records specified in the existing contractual requirements, with the understanding that if there is registration data included in the records requested that it may be limited by the allowing contracted party to only include registration data from the list of data elements in the chart?" ICANN may, of course, continue to make disclosure requests for 'additional' data. If there is a valid legal basis and necessity for such disclosure for any such data element, then there should be no issue in making such a disclosure request to the CPs.
Disclaimer: Again due to time constraints, this is my own response and not necessarily the view of the RYSG.
Senior Compliance & Policy Manager, Donuts Inc.
15-18 Earlsfort Terrace
Dublin 2, County Dublin
[http://storage.googleapis.com/signaturesatori/icons/facebook.png]<https://www.facebook.com/donutstlds> [http://storage.googleapis.com/signaturesatori/icons/twitter.png] <https://twitter.com/DonutsInc> [http://storage.googleapis.com/signaturesatori/icons/linkedin.png] <https://www.linkedin.com/company/donuts-inc>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
On Fri, Jan 25, 2019 at 11:08 PM Marika Konings <marika.konings at icann.org<mailto:marika.konings at icann.org>> wrote:
Dear EPDP Team,
Please find hereby a question from ICANN Contractual Compliance in relation to recommendation #7:
Hi Kurt/EPDP Team,
There are multiple contractual requirements which require contracted parties to provide ICANN data and records which may include registration data (including, but not limited to 2013 RAA Sections 3.4.3, 3.15 and 3.18; and new gTLD Base RA Section 2.11 and Specification 11, Section 3b). ICANN requires such documentation to facilitate its review of compliance with other provisions in the ICANN agreements and policies. With this understanding, can the EPDP team please clarify which contractual requirements Recommendation 7 applies to and how they should be changed? Specifically, is Recommendation 7 intended to limit all contractual requirements where ICANN is currently permitted to request information and records to only permitting ICANN to request the data elements listed in Recommendation 7’s chart? Or may ICANN continue to request the information and records specified in the existing contractual requirements, with the understanding that if there is registration data included in the records requested that it may be limited by the allowing contracted party to only include registration data from the list of data elements in the chart?
ICANN Contractual Compliance
Caitlin, Berry and Marika
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnso-epdp-team