[Gnso-epdp-team] ICANN Compliance question in relation to EPDP Recommendation 7

Tue Feb 5 01:31:30 UTC 2019

Dear Alan, Matt, EPDP Team,

Please see the below note from ICANN Contractual Compliance.

**
Thank you for your responses related to Recommendation #7.

Although the majority of the compliance function is accomplished through review of information which would otherwise have appeared in WHOIS prior to implementation of the Temporary Specification for gTLD Registration Data (and, therefore, the data elements listed in Recommendation #7), there is other information which are necessary to be processed to fulfill the function. Please refer to the types of data listed in the Contractual Compliance data processing overview<https://community.icann.org/display/EOTSFGRD/Input+from+ICANN+Org?preview=/90774122/97848455/Summary-Contractual-Compliance-Data-Processing-Activities.pdf> and note that the information in type (i) of the overview (complainant/complainant representative contact information) is obtained both directly from the complainant and from contracted parties and their representatives. Obtaining this information from contracted parties and their representatives is essential for ICANN’s confirmation and validation of complaints, as well as directly required by certain contractual requirements currently in the ICANN agreements/policies. Examples include domain name Account Holder information, underlying privacy/proxy customer information, correspondence between complainant and contracted party, etc. Therefore, in addition to the data elements listed, the EPDP team may want to consider Recommendation #7 also explicitly including the types of information listed in the Compliance data processing overview, inclusive of domain name Account Holder information and underlying privacy/proxy customer information; and regardless of (i) whether the information is received from the contact directly, a contracted party or representative and (ii) the medium in which the information is contained (Whois/RDAP database, correspondence, customer service tickets, chats, call and system logs, control panel, screenshots, other registration records, or similar).

This topic also appears to relate to the ongoing discussions regarding Recommendations #10 and #11 and the impact that limiting data retention by contracted parties to only TDRP-relevant information will have on the ability of ICANN Contractual Compliance to gather and review evidence demonstrating a contracted party’s compliance with other contractual requirements (e.g., Abuse report handling, Transfer Policy, ERRP, EDDP, UDRP, URS and including the requirement to relay communications to relevant email contacts). This evidence will be used by ICANN Contractual Compliance to both facilitate complaint resolution for internet users and close complaints that are out of scope of the requirements.

If the team has any questions regarding ICANN Contractual Compliance’s function and activities, please let us know.

Thank you.
**

Best,
Trang
ICANN Org Liaison

From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> on behalf of Matt Serlin <matt at brandsight.com>
Date: Wednesday, January 30, 2019 at 1:55 PM
To: Alan Woods <alan at donuts.email>, 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

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.

Regards,
Matt

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

Dear all.

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.

Alan

[Image removed by sender. Donuts Inc.][donuts.domains]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains_&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=CJEIF8gbxDZ8bcJ7BgUUSO4xZtjAZ3M2u9LEc0ljfEc&s=XB1UrEwAOgIsPvs2jCm-M1uXCBxoLpCY_IWwkui-zfk&e=>

Alan Woods
Senior Compliance & Policy Manager, Donuts Inc.
________________________________
The Victorians,
15-18 Earlsfort Terrace
Dublin 2, County Dublin
Ireland

[Image removed by sender. http://storage.googleapis.com/signaturesatori/icons/facebook.png][facebook.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=CJEIF8gbxDZ8bcJ7BgUUSO4xZtjAZ3M2u9LEc0ljfEc&s=5Sly1vWk7Ik3Gx6Hqo1F8Ba92WArc93UVayTjCZCVWQ&e=>  [Image removed by sender. http://storage.googleapis.com/signaturesatori/icons/twitter.png]  [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=CJEIF8gbxDZ8bcJ7BgUUSO4xZtjAZ3M2u9LEc0ljfEc&s=kOQAPbmNZkGB-qjzumvjHaFy32gbaY0sRfSNkP5fFRE&e=>  [Image removed by sender. http://storage.googleapis.com/signaturesatori/icons/linkedin.png]  [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=CJEIF8gbxDZ8bcJ7BgUUSO4xZtjAZ3M2u9LEc0ljfEc&s=H_f_4PvMBoYDWcE-OLIdKh-9xFtKARPzW_XwjTVgZ_4&e=>

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?

Thank you,
ICANN Contractual Compliance

Best regards,

Caitlin, Berry and Marika

_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team at icann.org<mailto:Gnso-epdp-team at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190205/0f438bad/attachment-0001.html>