- Gnso-epdp-team - lists.icann.org

Re: [Gnso-epdp-team] Recommendation 12 - Reasonable Access
by Alan Greenberg Feb. 7, 2019

Feb. 7, 2019

Ayden, prior to the Temp Spec, contracted parties had no need to reply to such requests because the information was public. With the Temp Spec and with the policy and Purposes we are recommending, contracted parties have a new obligation. Thus we are implicitly "expanding the role of Contractual Compliance" since their role is to ensure that contracted parties are fully fulfilling their obligations and we are adding obligations! Alan At 06/02/2019 03:19 PM, Ayden FÃ©rdeline wrote: I oppose the edit put forward by our colleagues in the ALAC that seeks to expand the role of Contractual Compliance. However, if the desire is more along the lines of (2) and the tool was funded on a cost-recovery basis by those seeking to utilize it, and not indirectly or directly by registrants, I would not object to language along the following lines: -- The EPDP Team recommends that ICANN org and the contracted parties develop a mechanism that provides third party requestors with uniform statistical information on the 1) nature of submitted requests, 2) average processing time, and 3) the number of requests approved or rejected, with rationale appropriately coded for information purposes. Such a mechanism must be funded on a cost-recovery basis by those private sector third parties who make access requests and seek to have access to these records. -- Ayden Original Message On Wednesday, February 6, 2019 2:59 PM, Mark Svancarek \(CELA\) via Gnso-epdp-team < gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team>> wrote: > Hopefully there is some language which properly reflects the variability of request responses while recognizing that nothing can be judged successful or improved without measuring it. > > For example, in our online services (1) we offer a firm SLA to our customers and reimburse them when we miss it, regardless why we missed it... but (2) internally we generate more interesting metrics to better understand the root causes, opportunities to improve, and the relative frequency of the various issues. Also, this reduces finger-pointing between teams. > > CPs cannot agree to language which implies (1); ALAC is requesting something like (2). > > /marksv > > -----Original Message----- > From: Gnso-epdp-team gnso-epdp-team-bounces at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> On Behalf Of Hadia Abdelsalam Mokhtar EL miniawi > Sent: Wednesday, February 6, 2019 11:36 > To: Alan Woods alan at donuts.email<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> > Cc: gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> > Subject: Re: [Gnso-epdp-team] Recommendation 12 - Reasonable Access > > Hi Alan, > > I am sorry that this is how you feel about our suggestion with regard to compliance, certainly there was no intention to having a stick to beat the contracted parties. Usually auditing is something that both parties benefit from. In what sense does our suggestion put new obligations on the contracted parties? It is just a means of verifying the process and this is good for the CPs as well because it ascertains the functionality of their system. Moreover how does the suggestion of having some kind of auditing contradict with the fact that every single request received must be considered individually? Additionally, we never said that existing complaints' processes can not be used we only said that you need to agree on the auditing mechanisms/means or whatever you want to call it. This is merely a suggestion to implement a sense of trust into the system, rather than having that trust something as intangible as good faith between the parties involved. > > Finally I invite you to put a few lines that speak about using existing complaints processes in this regard. > > Hadia > > From: Alan Woods alan at donuts.email<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> > Sent: 06 February 2019 19:01 > To: Hadia Abdelsalam Mokhtar EL miniawi > Cc: Marika Konings; Sarah Wyld; gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> > Subject: Re: [Gnso-epdp-team] Recommendation 12 - Reasonable Access > > To be perfectly honest, I think that Hadia & Alan's suggestions, are perilously close to going against the the very nature of the tentative agreements we have on Recommendation 12. If their point of view is that ICANN compliance must be used as a stick to beat the Contracted parties into submission/compliance, I find that exceptionally unhelpful. It is not the role of the ePDP to create new obligations for CPs outside of that which is necessary for GDPR compliance! > > The repeated issue of the parties is that it is nigh on impossible to set this in stone; every single request received must be considered individually, on its own merits (as the GDPR, which supersedes all our machinations, requires). The CPs are coming to the table in goodwill noting that we understand the need for predictability for 3rd party requests. We have discussed at length the impossibility of setting a strict timeline on such requests, I simply think this squanders the goodwill in this agreement in now suggesting a frankly unimplementable, or more likely a utterly ad hoc and random audit system, rather than accepting that the contracted parties are acting in good faith, and will continue to do so. For those CPs who do not act in good faith, I have a feeling that a poor audit result regarding response to disclosure requests will be the least of the issues. > > There are elements that are tangible and capable of ICANN review upon complaints regarding same, using existing complaints processes. Let's not reinvent the wheel here! > > So to be clear. The RYSG strongly opposes the ALAC addition. > > Alan > > [Donuts Inc.] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> > Alan Woods > Senior Compliance & Policy Manager, Donuts Inc. > > The Victorians, > 15-18 Earlsfort Terrace > Dublin 2, County Dublin > Ireland > > [ https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstorage.go… ] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb… [https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstorage.go…] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c… [https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fstorage.go…] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke… > > 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 Wed, Feb 6, 2019 at 12:10 PM Hadia Abdelsalam Mokhtar EL miniawi <Hadia at tra.gov.egmailto<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> :Hadia at tra.gov.eg<https://mm.icann.org/mailman/listinfo/gnso-epdp-team>> wrote: > Hi all , I have added a few words about compliance and the implantation of the policy and hence propose the following minor edits to recommendation number 12 > > " > The EPDP Team recommends that ICANN org and the contracted parties develop a mechanism that allows ICANN Contractual Compliance to audit response times to the requests. > The EPDP recommends that the implementation of this policy includes requirements of acknowledgement of recipient of requests and the response to such requests, criteria for a " Reasonable Request for lawful Disclosure" and a mechanism that allows ICANN Contractual Compliance to audit response time to the requests. > > The implementation of this policy will include at a minimum " > > The above is to replace > > "The EPDP Team recommends that criteria for a “Reasonable Request for Lawful Disclosure” and the requirements for acknowledging receipt of a request and response to such request will be defined as part of the implementation[Kristina 1] of these policy recommendations but will include at a minimum: " > > Hadia > > From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces at icann.orgmailto:gnso-epdp-team-bounces at icann.org] On Behalf Of Hadia Abdelsalam Mokhtar EL miniawi > Sent: Wednesday, February 06, 2019 12:32 PM > To: Marika Konings; Sarah Wyld; gnso-epdp-team at icann.orgmailto<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> : gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> > Subject: Re: [Gnso-epdp-team] Recommendation 12 - Reasonable Access > > Hi all, the below comments are on behalf of Alan G > > the proposal. > > 1. still does not set an expectation that although SOME requests may take the specified limit, not all should. Nor does it seem to imply that the Contractual Compliance has any ability to audit response times. > 2. I find the reference to "GDPR legal bases" problematic. For example, under the current proposals, a registrar who is operating full outside of the EU mat redact information for legal persons and for natural persons not subject to the GDPR. What is the GDPR legal basis for requesting information on such registrations. According to GDPR there was no need for redaction to begin with, so a registrar can refuse to provide any results with full impunity. > > From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces at icann.orgmailto:gnso-epdp-team-bounces at icann.org<mailto:gnso-epdp-team-bounces%20at%20icann.orgmailto:gnso-epdp-team-bounces…>] On Behalf Of Marika Konings > > > Sent: Tuesday, February 05, 2019 11:43 PM > To: Sarah Wyld; gnso-epdp-team at icann.orgmailto<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> : gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> > Subject: Re: [Gnso-epdp-team] Recommendation 12 - Reasonable Access > > Thanks, Sarah. > > EPDP Team members, as this topic is included in the agenda for tomorrow’s meeting, please share any issues or concerns your group may have with the modified language prior to the meeting, if possible. Staff has taken the liberty to fix some formatting issues in the attached version (some of the sub-bullets did not appear properly). > > Best regards, > > Caitlin, Berry and Marika > > From: Gnso-epdp-team < gnso-epdp-team-bounces at icann.orgmailto<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> : gnso-epdp-team-bounces at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team>> on behalf of Sarah Wyld <swyld at tucows.commailto<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> :swyld at tucows.com<https://mm.icann.org/mailman/listinfo/gnso-epdp-team>> > Organization: Tucows > Date: Tuesday, February 5, 2019 at 12:31 > To: " gnso-epdp-team at icann.orgmailto<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> : gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team>" < gnso-epdp-team at icann.orgmailto<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> : gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team>> > > Subject: [Gnso-epdp-team] Recommendation 12 - Reasonable Access > > Hello All, > > As discussed on today's call, here is the proposed revised Rec. 12 from RySG/RrSG. Thank you. > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Sarah Wyld > > Domains Product Team > > Tucows > > +1.416 535 0123 Ext. 1392 > > On 1/31/2019 11:31 PM, Kurt Pritz wrote: > > Hello Everyone: > > Thanks again for your perseverance. And - thank you in advance for your spirit of cooperation and compromise in considering the attached. We have spent the last few days reviewing the transcripts and other records of our recent discussions and then amending the Final Report Recommendations - taking into account the Initial Report Recommendations, the small team work, the conclusions in Toronto and these last several meetings. > > The Recommendations included here are: > > Recommendation 5 - Data elements to be transferred from Registrars to Registries > > Recommendation 10 - Email communication > > Recommendation 12 - Reasonable Access > > Recommendation 14 - Responsible Parties > > [Not included are Rec. 13 (sent earlier) and Rec. 11 and the Research Purpose (to be sent tomorrow.] > > Each of these documents has a brief forward containing a description of the pertinent discussion and an explanation for choosing the wording in the Recommendations. They each then contain the Recommendation as originally written and a redline of the proposed recommendation based on the most recent discussions. Please read the entire documents (they are not long), and not just the recommendation itself. > > I am certainly not asking for you to stand silently by if you disagree with these Recommendations because they would negatively impact GDPR compliance. I am asking that you study the balancing that went into this and be ready to accept wording in cases where it does not match your own choice. > > Please review with your groups and return to us by Monday so that we can put any of these on the Tues/Wed/Thur agendas. > > Sincerely, > > Kurt > > Gnso-epdp-team mailing list > > Gnso-epdp-team at icann.orgmailto<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> : Gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.… > > [Kristina 1]see previous comment about IRT/actor _______________________________________________ > Gnso-epdp-team mailing list > Gnso-epdp-team at icann.orgmailto<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> : Gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.… > > Gnso-epdp-team mailing list > Gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.… > > Gnso-epdp-team mailing list > Gnso-epdp-team at icann.org<https://mm.icann.org/mailman/listinfo/gnso-epdp-team> > https://mm.icann.org/mailman/listinfo/gnso-epdp-team

4 5

Input requested on BC input in relation to recommendation 9
by Marika Konings Feb. 7, 2019

Feb. 7, 2019

Dear Registrar Team, all, Per today’s action item, you are requested to provide your input on the BC suggestion that in relation to recommendation 9 – Organization field: “Instead of a “via a process that can be determined by each registrar” we should have concrete steps that can be enforced by ICANN. Could the registrars identify some reasonable steps for this process? ADD: After the implementation phase-in period, the ORG FIELD will no longer be REDACTED by either the registry or registrar. “ Your feedback on this input is appreciated. Thanks, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

3 2

Question in relation to BC comment on consent recommendation
by Marika Konings Feb. 7, 2019

Feb. 7, 2019

Margie, James, all, In relation to the BC comment: “RECOMMENTATION REGARDING CONSENT Page 19 – Line 549 please delete “as soon as commercially reasonable”. Instead, this recommendation should track the dates for implementation under the transition plan that James and the registrars proposed in Toronto.” Could you please provide further details in relation to what is referred to with ‘the transition plan that James and the registrars proposed’ and how that would affect the recommendation? As a reminder, this new recommendation (modelled on the existing Temp Spec language) currently reads as follows: “The EPDP Team recommends that, as soon as commercially reasonable, Registrar must provide the opportunity for the Registered Name Holder to provide its Consent to publish additional contact information”. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

3 2

Revised Recommendations for (Final) Review - with attachments
by Kurt Pritz Feb. 7, 2019

Feb. 7, 2019

Hello Everyone: Thanks again for your perseverance. And - thank you in advance for your spirit of cooperation and compromise in considering the attached. We have spent the last few days reviewing the transcripts and other records of our recent discussions and then amending the Final Report Recommendations - taking into account the Initial Report Recommendations, the small team work, the conclusions in Toronto and these last several meetings. The Recommendations included here are: Recommendation 5 - Data elements to be transferred from Registrars to Registries Recommendation 10 - Email communication Recommendation 12 - Reasonable Access Recommendation 14 - Responsible Parties [Not included are Rec. 13 (sent earlier) and Rec. 11 and the Research Purpose (to be sent tomorrow.] Each of these documents has a brief forward containing a description of the pertinent discussion and an explanation for choosing the wording in the Recommendations. They each then contain the Recommendation as originally written and a redline of the proposed recommendation based on the most recent discussions. Please read the entire documents (they are not long), and not just the recommendation itself. I am certainly not asking for you to stand silently by if you disagree with these Recommendations because they would negatively impact GDPR compliance. I am asking that you study the balancing that went into this and be ready to accept wording in cases where it does not match your own choice. Please review with your groups and return to us by Monday so that we can put any of these on the Tues/Wed/Thur agendas. Sincerely, Kurt

14 23

Proposed language in relation to process for amendments to RRAs
by Marika Konings Feb. 7, 2019

Feb. 7, 2019

Dear EPDP Team, In relation to the process for amendments to Registry – Registrar agreements, as discussed during today’s EPDP Team meeting, please find hereby the proposed language for inclusion in the implementation section of the report: New Recommendation: The EPDP Team recommends that, as part of the implementation, a process for amendments to Registry - Registrar agreements (RRAs) needed to implement the EPDP recommendations is considered. If you have any concerns about this language, please indicate this by Thursday 7 February COB. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

4 6

Recommendation 11 - Data Retention
by Caitlin Tubergen Feb. 7, 2019

Feb. 7, 2019

Dear EPDP Team, Following up on some noted issues during last week’s discussion of Recommendation 11 (data retention), please find updated language below for your consideration. We will discuss the below language tomorrow, but if you would like to flag any concerns in advance of tomorrow’s meeting, please do so. Updating language is italicized and bolded for emphasis. Recommendation 11 The EPDP team recommends that ICANN Org, as soon as is practicable, undertakes a review of all its active processes and procedures so as to identify and document the instances in which personal data is requested from a registrar beyond the period of the 'life of the registration'. Retention periods for specific data elements should then be identified, documented, and relied upon to establish the required relevant and specific minimum data retention expectations for registrars. In addition, community members should be invited to contribute to this data gathering exercise by providing input on other legitimate purposes for which different retention purposes may be applicable. These contributions could help inform the deliberations foreseen during phase 2 of the EPDP Team’s work. In the interim, the EPDP team has recognized that the Transfer Dispute Resolution Policy (“TDRP”) has been identified as having the longest specified retention period of one year and has therefore recommended registrars be required to retain only those data elements deemed necessary for the purposes of the TDRP, for a period of one year following the life of the registration. This retention is grounded on the stated policy stipulation within the TDRP that claims under the policy may only be raised for a period of 12 months after the alleged breach (FN: see TDRP section 2.2) of the Transfer Policy (FN: see Section 1.15 of TDRP). This retention period does not restrict the ability of registries and registrars to retain data elements provided in Recommendations 4 -7 for other purposes specified in Recommendation 1 for shorter periods. The EPDP team recognizes that Contracted Parties may have needs or requirements for different retention periods in line with local law or other requirements. The EPDP team recommends that nothing in this recommendation, or in separate ICANN-mandated policy, should prohibit contracted parties from setting their own retention periods beyond that which is expected in ICANN policy. Similarly, should local law prevent retention for the minimum period as set by ICANN, the EPDP team recommends that a suitable waiver procedure is put in place that can address such situations. In addition, the waiver procedure should be reviewed to determine if it would be appropriate for other Contracted Parties to “join” themselves to an existing waiver upon demonstration of being subject to the same law or other requirement that grounded the original waiver application. Thank you. Best regards, Marika, Berry, and Caitlin

1 0

questions submitted to legal counsel
by Caitlin Tubergen Feb. 7, 2019

Feb. 7, 2019

Dear EPDP Team, Following up on an action item from today’s call, please find the questions recently sent to the outside legal counsel: Registration Data Redaction from Public Whois Database - City Name of the Registered Name Holder 1a. Is the data provided by the Registered Name Holder for the “City” field in the RNH’s address personal data? To what extent is there a risk under GDPR that the publication and/or disclosure of the RNH-identified “City” could result in inadvertent disclosure of personal data (which may affect the the policy of whether it should be redacted from the data that is made publicly available in Whois), or contribute to making the Registered Name Holder more identifiable? Please note that the EPDP is considering a recommendation to allow the publication of the City, State/Province and Country, while redacting the contact’s name, street address, email address, postal code, telephone number. What are the bases in the GDPR, its official advisories and interpretations, and in practices similar to our own for making such a determination? 1b. If the city field is personal data and therefore must be redacted, is there a lawful basis under Art. 6(1)f for publishing a subset of the data submitted by the registered name holder that includes the city name, where the legitimate interest is that those pursuing legal claims can determine jurisdictional issues prior to asserting the claim where that interest overcomes the rights of all registrants in not having their personal data published. (This proposed legitimate interest was gleaned from the transcript in Toronto.) GDPR Data Accuracy Requirement 2. Some EPDP Team members cite Art. 5.1(d) of GDPR as a requirement for the EPDP Team to examine how accuracy is currently defined in ICANN’s 2013 Registrar Accreditation Agreement (the contract with registrars) and possibly require changes. Some EPDP Team members cite the accuracy requirement in Art. 5.1(d) GDPR as support for additional accuracy related policies, such as a requirement for registrars to validate the correctness of the data as provided by the data subject or a requirement to validate when the accuracy is being challenged. Others maintain that the Art. 5.1(d) GDPR requirement is to accurately record, maintain and process the data provided by the data subject and to update that information as informed by the data subject. Is the accuracy requirement limited to correction at the request of the data subject or is it a broader requirement? Please advise on how the accuracy requirements of GDPR impact the contracted parties and ICANN. GDPR Reach 3. In light of the EDPB Guidance on territorial scope of GDPR, how do ICANN’s stable establishments within the EU impact its responsibilities as a data controller. The EDPB Guidance appears to suggest that ICANN, as a controller with stable establishments within the EU, might be required to comply with GDPR? Is this the case even if the majority of processing activities (including registrar/reseller collection of data from RNH) take place outside of the EU? . Specifically: Do any of ICANN’s operations within the EU qualify as Establishments, as defined by Recital 22 of the GDPR? If ICANN is found to have Establishments within the EU, do these Establishments require ICANN (as a controller of gTLD Registration Directory Services related processing activities) to be subject to article 3.1 of the GDPR? Do the answers to the above questions impact ICANN’s, and/or any associated controllers’ or processors’, ability to distinguish between Registered Name Holders (RNH)/data subjects based on the geographic location of the RNHs in determining the geographic scope of GDPR? Thank you. Best regards, Marika, Berry, and Caitlin

1 0

Recordings, Attendance & AC Chat / GNSO Temp Spec gTLD RD EPDP / Wednesday, 06 February 2019
by Andrea Glandon Feb. 6, 2019

Feb. 6, 2019

Dear all, Please find the attendance and AC chat attached to this email, and the MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Wednesday, 06 February 2019 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/gYA2Bg MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-06feb19… AC Recording: https://participate.icann.org/p3oxdzbirui/<https://participate.icann.org/p3oxdzbirui/?OWASP_CSRFTOKEN=52ea284f72e587ea…> ** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ Thank you. Kind Regards, Andrea Glandon

1 0

Re: [Gnso-epdp-team] [Ext] Re: FW: Response from ICANN Compliance re. registrations under the 2009 RAA
by Alan Greenberg Feb. 6, 2019

Feb. 6, 2019

Now that I have posting rights again: Two comments on "... will contain the name and contact information of some contact" - It is not really necessary to mention "name" since the 2009 RAA did require a Name field for the Registrant. - "some contact" is too wide, since we are still requiring (optionally) a technical contact which may not be the entity responsible for the registration (for instance it my be the hosting provider). Since we are also eliminating the Billing fields, the Registrant is the only remaining non-technical contact, so replacing the phrase with: "... will contain full Registrant Contact information" That also eliminates the need for the e.g. Regarding Ayden's recommendation to eliminate the final sentence, I do not agree. We need to make it clear that ensuring the Registrant contact information being present is a gating requirement to elimination of the Admin fields. We could in fact stop collection admin contact details before that, because for all new or changing registrations the 2013 rules apply which ensures Registrant data. Alan At 06/02/2019 06:58 AM, Ayden Férdeline wrote: Thanks, Marika. I have some suggested edits, which are stylistic and not substantive: Redline: Recognizing that in the cases of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to in eliminating the collection and maintenance of the current Aadministrative Ccontact field, the Registrar MUST ensure that each registration will contain the name and contact information of some contact., e.g., the Registered Name Holder. This will need to happen before the administrative contact is eliminated. Clean: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to eliminating the collection and maintenance of the current Administrative Contact field, the Registrar MUST ensure that each registration will contain the name and contact information of some contact. Best wishes, Ayden Férdeline ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, February 5, 2019 6:18 PM, Marika Konings <marika.konings(a)icann.org> wrote: In line with the comments made, would the following work for inclusion in the Final Report: New Recommendation: Recognizing that in the cases of some registrations, there may be an Admin Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, in eliminating the collection and maintenance of the administrative contact, the Registrar MUST ensure that each registration will contain the name and contact information of some contact, e.g., the Registered Name Holder. This will need to happen before the administrative contact is eliminated. If you have any concerns about this proposed language, please share this with the mailing list by Wednesday 6 February COB. Best regards, Caitlin, Berry and Marika From: Alan Greenberg <alan.greenberg(a)mcgill.ca> Date: Monday, February 4, 2019 at 18:20 To: Kurt Pritz <kurt(a)kjpritz.com> Cc: Marika Konings <marika.konings(a)icann.org>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] Re: [Gnso-epdp-team] FW: Response from ICANN Compliance re. registrations under the 2009 RAA Kurt, that would be fine. But that is not "elimination of the field". The registrar "ensuring" must happen before the field disappears. We have an escrow program to protect registrants against failures in registrars and registries. The escrow data going forward must always include contact info. I am just about to name an alternate for tomorrow and will lose posting privileges to this list. Alan At 04/02/2019 07:07 PM, Kurt Pritz wrote: Thanks for this Alan: Might another approach be to write into the policy something to the effect that, â��Recognizing that in the cases of s some registrations there is an â��Admin Contactâ�but no Registered Name Holder or any other contact, it is required that, in the eliminating the collection and maintenance of the administrative contact, the registrar will ensure that each registration will contain the name and contact information of some contact, e.g., the registered name holder.â�� Something like that to let each registrar manage its own situation and also to give compliance a way to monitor registrations to ensure that there is contact information. Best regards, Kurt On Feb 4, 2019, at 3:58 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: Another alternative is to say that the Admin contacts are not to be collected for new, changed or transferred registrations (which are all subject to the 2013 RAA requirement for Registrant contact data) and that the fields will be eliminated once all registrars confirm that all of the registrations under their sponsorship have Registrant contact information. Alan At 04/02/2019 05:14 PM, Alan Greenberg wrote: I do not believe that we can eliminate the Admin contact information (as currently recommended) without a concrete idea of how many registrations might be left without contact information and just a note that implementation should investigate the potential impact. If that investigation (if it is even possible given the data that ICANN possesses) we to show that there are a substantive number of such registrations, what could they do? We know that registrars have resisted the requirement to take corrective action on registration (which is why the validation/verification requirements in the 2013 RAA only apply when there are changes). If we eliminate Admin fields, we must provide for ensuring that all registrations have contact information within a relatively short period of time. The easy fix given the timeline is to not eliminate the Admin fields. Alan At 04/02/2019 08:19 AM, Marika Konings wrote: Dear Alan G., all, In relation to the question regarding the 2009 RAA you formulated a while back, note that ICANN Org had already provided a response: Alan GreenbergÃ¢��s Question: br> The EPDP is requesting that ICANN Org confirm that all registrars are now operating under the 2013 RAA. The EPDP is requesting that ICANN Org provide its interpretation of the requirement under the RAA Data retention Specification 1.1 whether registrars, as part of their adoption of the 2013 RAA, are required to ensure that Registrant contact email and telephone fields are completed, or whether the phrase "shall maintain that information" (which was validly allowed to be blank at registration time) allows them to preserve any empty Registrant contact fields. If the former, is Contractual Compliance taking any action to ensure that registrars fulfill this obligation? ICANN org Compliance Response: Registrars are not required to collect additional contact information for 2009 Registrar Accreditation Agreement (RAA) registrations. However, registrars may be required to update existing contact information for 2009 RAA registrations when there is a triggering event under the 2013 RAA that may require them to do so (e.g., the domain name is an inbound transfer, the registrant changes, there is information to suggest the current contact information is incorrect). This response is also posted here: https://community.icann.org/x/ahppBQ. Please let us know if this does not sufficiently address your question. In order to ensure this issue is not overlooked during the implementation phase, would it be helpful to add a sentence along the following lines in the implementation part of the report: Ã¢��As part of the implplementation, consideration needs toto be given to the potential impact of these policy recommendations on legacy registrations that without additional mitigation could end up with no contact information if the administrative contact is the only information currently available (this could be the case for a limited number of registrations that are still under the 2009 Registrar Accreditation Agreement)Ã¢��? > Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support � GNSO, Internet Corporation forr Assigned Namees and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

2 1

Re: [Gnso-epdp-team] [Ext] RE: Comments on Final Report & Additional Topics- Part 1
by Marika Konings Feb. 6, 2019

Feb. 6, 2019

Thanks, Hadia, but this appears to change the meaning of what was agreed during yesterday’s meeting (‘expression of need’)? Of course, if everyone is comfortable with this change, we can make it accordingly. Best regards, Caitlin, Berry and Marika From: Hadia Abdelsalam Mokhtar EL miniawi <Hadia(a)tra.gov.eg> Date: Wednesday, February 6, 2019 at 07:04 To: Marika Konings <marika.konings(a)icann.org>, Margie Milam <margiemilam(a)fb.com>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] RE: [Gnso-epdp-team] Comments on Final Report & Additional Topics- Part 1 Thank you Marika, apologies for editing an old version. Please find below my edits in orange The EPDP Team commits to considering in Phase 2 of its work whether additional purposes should be considered to facilitate ICANN’s Office of the Chief Technology Officer (OCTO) to carry out its mission (see https://www.icann.org/octo [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_octo&d=D…>). This consideration should be informed by legal guidance on if/how provisions in the GDPR concerning research apply to ICANN Org and the relevance of research to ICANN's mission. Again my edits are because I think that we should avoid referring to data or modes of operation the whole idea is yet to be explored. Hadia From: Marika Konings [mailto:marika.konings@icann.org] Sent: Wednesday, February 06, 2019 2:44 PM To: Hadia Abdelsalam Mokhtar EL miniawi; Margie Milam; gnso-epdp-team(a)icann.org Subject: Re: [Gnso-epdp-team] Comments on Final Report & Additional Topics- Part 1 Hadia, all, Please note that per yesterday’s agreement, the recommendation has been updated as follows: The EPDP Team commits to considering in Phase 2 of its work whether additional purposes should be considered to facilitate ICANN’s Office of the Chief Technology Officer (OCTO) to carry out its mission (see https://www.icann.org/octo [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_octo&d=D…>). This consideration should be informed by legal guidance on if/how provisions in the GDPR concerning research apply to ICANN Org and the expression for the need of such pseudonymized data by ICANN. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Hadia Abdelsalam Mokhtar EL miniawi <Hadia(a)tra.gov.eg> Date: Wednesday, February 6, 2019 at 06:38 To: Margie Milam <margiemilam(a)fb.com>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: Re: [Gnso-epdp-team] Comments on Final Report & Additional Topics- Part 1 Hi all Thank you Margie for your edits I would suggest a minor edit to the research purpose to read (my edits are in orange) "The EPDP Team commits to considering in Phase 2 of its work whether additional purposes should be considered to facilitate research ADD: [ and threat response] carried out by ICANN’s Office of the Chief Technology Officer (OCTO). This consideration should be informed by legal guidance on if/how provisions in the GDPR concerning research apply to ICANN Org and the need for the research purpose by ICANN org in accordance with the mission of ICANN’s Office of the Chief Technology Officer." The reason for my edits is that we don't know yet the kind of data that would be required nor the means of implementation the whole purpose/idea is yet to be explored. Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Margie Milam Sent: Tuesday, February 05, 2019 4:03 AM To: gnso-epdp-team(a)icann.org Subject: [Gnso-epdp-team] Comments on Final Report & Additional Topics- Part 1 Hi- Per Marika’s request, here are some language clarifications for your consideration, as well as additional topic submitted on behalf of the BC, and developed in collaboration with the IPC. New Text is in yellow highlight. _________ Rec 1 Purpose 1(b): Subject to the Registry and Registry Terms Conditions and Policies, and ICANN Consensus Policies – please ADD: { and relevant registry agreements and registrar accreditation agreements] Purpose 2: Footnote 6 needs to be moved to be linked to Purpose 2, not Rec 2. Research purpose: The EPDP Team commits to considering in Phase 2 of its work whether additional purposes should be considered to facilitate research ADD: [ and threat response] carried out by ICANN’s Office of the Chief Technology Officer (OCTO). This consideration should be informed by legal guidance on if/how provisions in the GDPR concerning research apply to ICANN Org and the expression 426for the need of such data by ICANN Footnote 7/8 should not be a footnote but moved up to the body of the report. These footnotes are substantive recommendations and commitments that should not be buried in a footnote. Rec 7: Replace “ICANN Compliance”with ”ICANN Organization” to be consistent with other recommendations. Delete the quote in Footnote 12 on page 24, since this is inconsistent with Purpose 5. Additional Topics: INFORMATION TO BE PROVIDED TO THE REGISTRANT: Page 16- where there is the quote from the EDPB: It should therefore be made clear, as part of the registration process, that the registrant is free to (1) designate the same person as the registrant (or its representative) as the administrative or technical contact; or (2) provide contact information which does not directly identify the administrative or technical contact person concerned (e.g. admin(a)company.com<mailto:admin@company.com>). For the avoidance of doubt, the EDPB recommends explicitly clarifying this within future updates of the Temporary Specification”. We believe it is important to follow the EDPB’s advice and propose including a recommendation regarding informed consent, in light of the legal advice received, as follows: The EPDP recommends that as part of the registration process, the Registrar shall offer the registered name holder the option to (1) designate the same person as the registrant or its representative as the technical contact; or (2) provide contact information which does not directly identify the technical contact person, but instead uses a generic or role-based email (e.g.admin(a)company.com<mailto:admin@company.com>). OPTIONAL TECH CONTACT DISCUSSION: We do not support making the Tech Contact optional at the registrar level or registry level and believe that more discussion is needed. For example, we have not discussed what happens to existing Tech contacts in the legacy registrations. Shouldn’t there be a similar transitional process to what has been developed for the ORGANIZATION field? In any event, this obligation must be requieeed for the registries since they should receive the tech contact data for those registrants who have provided consent. RECOMMENTATION REGARDING CONSENT Page 19 – Line 549 please delete “as soon as commercially reasonable”. Instead, this recommendation should track the dates for implementation under the transition plan that James and the registrars proposed in Toronto. Rec 4: THICK WHOIS: we do not support the deletion of THICK WHOIS as a consensus policy, and believe that this goes beyond the scope of this EPDP. Rec 8: GLOBAL REDACTION vs. OPTIONAL AT THE REGISTRAR--- We do not agree with global application of the REDACTION, and believe that this recommendation goes well beyond the Temp Spec, which at a minimum allows the registrars/registries to CHOOSE a different application, especially because of differing legal regimes. Our policy needs to be flexible enough to account for laws beyond GDRP, such as the possible US legislation related to WHOIS. Similarly, we do not believe that the redaction should apply to legal persons. We recall James suggesting that we could consider an approach similar to the approach taken for the ORGANIZATION Field, and thus we would like to further explore it in Phase 2. Footnote 15 is a recommendation that should be moved into the body of the Final Report & not be buried in a footnote. Also- it needs to exclude registrations with privacy/proxy services and those for which the registrant has provided consent. PAGE 27: REDACTION OF CITY– we don’t agree with the redaction of CITY and are awaiting legal advice from Ruth on the issue. As a result, it is premature to make a recommendation that it be redacted now. This should be a Phase 2 discussion REC 9: Instead of a “via a process that can be determined by each registrar” we should have concrete steps that can be enforced by ICANN. Could the registrars identify some reasonable steps for this process? ADD: After the implementation phase-in period, the ORG FIELD will no longer be REDACTED by either the registry or registrar. We are still working through the remainder of the Final Report, and will follow up this email with additional comments. All the best, Margie

3 2