February 2019 - Gnso-epdp-team

For your review - latest version of EPDP Team Final Report
by Marika Konings Feb. 7, 2019

Feb. 7, 2019

Dear EPDP Team, Please find attached for your review the latest version of the Final Report. In relation to section 5, EPDP Team Responses to Charter Questions & Recommendations, please note that those sections highlighted in green are considered finalized for inclusion in the Final Report, sections in blue are still under review / consideration (but these do include the latest language, unless indicated differently). For substantive issues or concerns, please flag these on the mailing list by Monday 4 March COB so that these can be included in the meeting agendas for next week. If you want to reference specific parts of the report, please use the line numbering of the attached pdf version. For any minor edits / updates, please use the google doc: https://docs.google.com/document/d/1sVZ9odV0qK1Bk8a4bDwWe5RW_PBzOnYBhHW_GnL…. On the wiki (see https://community.icann.org/x/VZwWBg) we have also posted a Word and clean version for those of you that prefer that format. As you review the Final Report, we want to remind you of Kurt’s message that also seem to apply here: “study the balancing that went into this and be ready to accept wording in cases where it does not match your own choice”. As a reminder, revisions to the data elements workbooks to ensure alignment with EPDP recommendations are being undertaken by a small team which is expected to share the results of its work shortly. 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…>.

10 10

Quick and dirty proposed rec 12 edits
by Heineman, Ashley Feb. 7, 2019

Feb. 7, 2019

As promised, I took a quick and dirty stab at revising recommendation 12 to address my earlier articulated concerns. I have no issue with the substance itself. This is an attempt to bring this back to the original intent of this recommendation and recognize that it is intended to address "reasonableness" of the process and not the "reasonableness" of the requests per set. I agree that a big chunk of this is to make sure that requests are done in a way that are actionable, but such a focus on the "reasonable requests" is and never was the core intent of this recommendation. I hope the attached is acceptable. Thanks for your consideration!!!

1 0

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

Feb. 7, 2019

At 07/02/2019 08:41 AM, Ayden Férdeline wrote: Hi Alan G., I hope to find a compromise here so that we can move forward, but I find your language to be too prescriptive. I don't understand why we'd call out "voice telephone and email contact information"? I used those terms because they are the ones that are used in the RAA and my understanding was that being specific as to which fields we are talking about. Surely if these are fields that are mandatory for a registrant to provide, in asking for full contact information (of mandatory fields), they would be covered? No, that is the entire point. In the 2009 RAA, there were not considered mandatory. That is why they may be missing as stated in the opening clause. I also have concerns with the sentence, "Registrars may, at their option, either not collect Administrative Contact fields, or collect them at the option of the Registered Name Holder." I believe this sentence is redundant. It is not redundant and not prescriptive. It is telling registrars (and registrants) that they have complete flexibility on how they treat these fileds once our policy is active. As it stands, we have another recommendation that allows a RNH to request that additional data elements be published. This has nothing to do with publishing. It is about whether the fields exist at all and whether they need to be collected. And it is about protecting registrant in the case of a Rr/Ry failure. Alan May I suggest the following language: Redline: Recognizing that in the case of some existing registrations, there may be an Administrative Contact information but no or incomplete Registered Name Holder contact information, the EPDP team recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains the Registered Name Holder voice telephone and e-mail contact information. Prior to the Administrative Contact fields being eliminated, Registrars may, at their option, either not collect Administrative Contact fields, or collect them at the option of the Registered Name Holder. Clean: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no or incomplete Registered Name Holder contact information, the EPDP team recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains contact information. Best wishes, Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, February 6, 2019 10:59 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: Hi Ayden, The issue is not collecting and maintaining. It would be foolish for registrars to have to collect Admin data post-EDPD-policy implementation if the intent is to get rid of the field. All of those registrations where they might collect Admin data, we know that the Registrant contact details are mandatory (since they would be subject to 2013 rules). The issue is we cannot eliminate the field from the database structure (and eliminate disclosing it when applicable) until we make sure there are no empty registrant contact fields. Moreover, as I pointed out in the my previous message, a registration might include Technical contact info but that is not sufficient to replace Registrant/Admin. Here is something that will work. "Recognizing that in the case of some existing registrations, there may be Administrative Contact information but no or incomplete Registered Name Holder contact information, the EPDP recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains the Registered Name Holder voice telephone and e-mail contact information. Prior to the Administrative Contact fields being eliminated, Registrars may, at their option, either not collect Administrative Contact fields, or collect them at the option of the Registered Name Holder." This would ensure that we do not eliminate the Admin fields until we can ensure that every registration (and particularly every registration in the escrow files) has SOME contact info for someone responsible for the registration. That protects the registrant, but does not required Registrars to keep collecting data that is being phased out. The list of fields to be collected would have to note this recommendation instead of just omitting the Admin fields. Alan At 06/02/2019 05:57 PM, Ayden FÃ©rdeline wrote: Hi Alan, I have tried to strike a balance between the text I shared earlier and the comments you have raised here. Here is what I have come up with: 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 contact information. Can you live with this? I have removed the reference to "some contact", which you found vague, and "name", because you noted this was unnecessary given the RAA. However I have still deleted the last sentence, because I do think it is redundant. Best wishes, Ayden â��â��â��â��â��â��â�� Original Message â��â�4;â€�â��â��â��â��â�â€� On Wednesday, February 6, 2019 5:27 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: 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 Ã¢��Ã¢��Ã¢��Ã¢��Ã¢â144;Ã¢â�¬�Ã¢��Ã¢�� Ori; Original Message Ã¢�Ã¢��Ã¢��Ã¢�Ã¢��Ã¢��â�¬�Ã¢�� On Tuesday, February 5, 2019 66: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 thatat in thehe cases of s some registrations there is an ÃƒÂ¢��Adminin ContactÃƒÂ¢�but no Registered Name ame Holder or any otherr 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 eaach 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 Questistion: 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 parart of the implplplplementation, 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)ÃƒÆ’Ã�Â¢��? ; br> > Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support � GNSO, Internet Corporation forr Asssiggned 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] 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