February 2019 - Gnso-epdp-team

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

Proposed agenda - EPDP Team Meeting #44
by Caitlin Tubergen Feb. 6, 2019

Feb. 6, 2019

Dear EPDP Team, Please find the agenda for tomorrow’s EPDP Team meeting below. Best regards, Marika, Berry, and Caitlin -- EPDP Meeting #44 Agenda Thursday, 7 February 2019 1. Roll Call & SOI Updates (5 minutes) 2. Welcome and Updates from EPDP Team Chair (5 minutes) a. Review of outstanding action items b. Other updates, if applicable 3. Implementation Bridge Per last week’s action item, CPH to present language/approach for implementation bridge discussion a. CPH to present updated language proposal b. Discuss proposal c. Confirmation of agreement reached or next steps to come to agreement 4. Recommendation #12 - Reasonable Access (30 minutes) a. Review revised proposal b. Discuss revised proposal c. Confirmation of agreement reached or next steps to come to agreement 5. Recommendation #10 – Email Communication a. Review revised proposal b. Discuss revised proposal c. Confirmation of agreement reached or next steps to come to agreement 6. Recommendation #11 – Data Retention a. Review revised proposal b. Discuss revised proposal c. Confirmation of agreement reached or next steps to come to agreement 7. Review of additional topics raised from table (if time allows) 8. Wrap and confirm next meeting to be scheduled for Monday, 11 February 2019 at 14.00 UTC (5 minutes) a. Confirm action items b. Confirm questions for ICANN Org, if any

1 0

Updated language for recommendation #5
by Marika Konings Feb. 6, 2019

Feb. 6, 2019

Dear EPDP Team, Per the action item from today’s meeting, please find attached the updated proposed language for recommendation #5. Per the other action item: EPDP Team to further review / consider this issue (rec 5) and put forward proposed language for the Final Report, factoring in today's discussion (could also be in relation to rec #22). Please provide any input you may have by Thursday 7 February COB. 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…>.

1 0

Re: [Gnso-epdp-team] RrSG Comment on Recommendation 10
by Alan Greenberg Feb. 6, 2019

Feb. 6, 2019

Alan, "Should ICANN compliance wish to test the fidelity of the system, that is in their purview to do so to ensure the mechanics of the system." does not give compliance the ability to address complaints that messages are seemingly not being relayed (or are being relayed to a non-viable contact address). Alan At 01/02/2019 05:34 AM, Alan Woods wrote: Thank you Greg and our SSAC colleagues for this, However, with my privacy lawyer hat on, can we actually remind ourselves here of the goal. The Goal here is to simply confirm that the registrar has relayed the requestors communication. The suggestion from our SSAC colleagues, has the Registrar, not only maintaining this log, but creating a database of requestor data, email addresses, metadata, and, for good measure, a positive obligation to further monitor responses from those emails sent, so as to initiate an action which may result in a suspension of a domain name. Outside of the fact that a system of this size is likely complex and cost prohibitive to smaller registrars, it ignores necessity and data minimization and alas fails the privacy by default and privacy by design tests. I'm sure that the very clever folks at the registrars can come up with a much simpler and functional system along the lines of: 1. A communication request received is assigned a number e.g. #X 2. The number is provided to the requester (for their own reference) but the registrars have no need to maintain a record of which requester is assigned which number, just that request #X is made, and the system has confirmed its relay of the message associated with #X. 3. Should ICANN compliance wish to test the fidelity of the system, that is in their purview to do so to ensure the mechanics of the system. None of the other data or actions are remotely necessary. 4. I would also suggest that we give the registrars a bone here and state that nothing in our recommendation language should prevent the registrar from taking appropriate actions to prevent excessive use or abuse of the registrant contact process. Now to display how number 4 may be achieved, but also noting that this is not within ICANN's controllership and therefore outside of the ICANN policy reach: 4a. A Registrar may, at their own discretion, keeps a sufficiently anonymized log of requests (whereby the system pseudonymizes of somehow anonymizes personal data of the requester but is capable of logging where requestor (let's call him Y) has made 30000 requests #X ,#Z etc. This can then be used to perhaps filter such future requests from that requestor. To confirm this would be solely at the option of the regsitrar, abased on their own needs, size, resources etc. The registrar would be controller here, and ICANN base policy cannot dictate this. This would indeed be a prudent step for a larger registrar to prevent abuse of the relay system, and to avoid allegation that they are 'spamming' their registrants. To that end. I think Sarah's' proposed wording with Kristina's addition (and perhaps the clarification contained in 4 above) is still wholly sufficient for the goal and purpose pursued. Kind regards, Alan Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Thu, Jan 31, 2019 at 11:25 PM Greg Aaron <greg(a)illumintel.com<mailto:greg@illumintel.com>> wrote: The SSAC team proposes a revised version of #2. A goal is to make measurement and compliance activity around this contractual requirement possible. The Temp Spec doesn't offer that, and the existing proposals don't yet either. The RrSG proposal says that no personal data about the activity will retained, and log format or content are not specified. If so, how will a registrar demonstrate that a message from any requestor was sent to the registrant? The below makes clear that the records about forwarding are for examination by ICANN Compliance (only). If someone who originated a message is concerned, they can make a complaint to ICANN. That is the same model that we have now for invalid WHOIS and abuse reporting complaints. We also assume that such records will be retained for only an appropriate term. Part of the recommendation below is based on an existing procedure in the RAA. so it is familiar. It creates no new personal data transfer, and there is already a “P”urpose defined for contracted parties to send personal data to Compliance. It does not require the registrar to keep the entire email message if they do not want to. Proposed text: "2) The EPDP Team recommends that Registrars must maintain records that demonstrate that the communication from the requestor was relayed by email to the Registered Name Holder. This information must include the requestor's identity as it was provided to the Registrar, the Registered Name Holder's email address, and a timestamp. Such records will be available to ICANN for compliance purposes, upon request. If Registrar receives a bounced email notification or non-delivery notification message, the Registrar must initiate re-verification of the registrant's contact data per the RAA's WHOIS Accuracy Program Specification, paragraph 4." From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Friday, January 25, 2019 4:14 PM To: gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] RrSG Comment on Recommendation 10 Hello All, For Recommendation 10, the RrSG has the following proposed new text: 1) In relation to facilitating email communication between third parties and the Registered Name Holder, the EPDP Team recommends that current requirements in the Temporary Specification that specify that a Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, remain in place. 2) The EPDP Team recommends Registrars MUST maintain Log Files, which shall not contain any Personal Information, and which shall contain confirmation that a relay of the communication between the requestor and the Registered Name Holder has occurred, not including the origin, recipient, or content of the message. The registrar cannot be reasonably expected to confirm, or attempt to confirm by any means, the receipt of any such relayed communication. 3) DELETE 3 -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________ 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 https://mm.icann.org/mailman/listinfo/gnso-epdp-team

6 5

Re: [Gnso-epdp-team] Proposed Revised "Registration Data" Definition
by Marika Konings Feb. 6, 2019

Feb. 6, 2019

Dear EPDP Team, Are there any concerns about adding this as a recommendation to the Final Report? If so, please flag this by Thursday 7 February COB. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of "Rosette, Kristina via Gnso-epdp-team" <gnso-epdp-team(a)icann.org> Reply-To: "Rosette, Kristina" <rosettek(a)amazon.com> Date: Tuesday, February 5, 2019 at 08:24 To: EPDP <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed Revised "Registration Data" Definition All, With apologies for the delay, I’m following up on a point I previously raised, namely, revising the definition of “registration data”. The Temp Spec contains this definition: “Registration Data” means data collected from a natural and legal person in connection with a domain name registration.” The “in connection with” language is so broad and vague that it could be interpreted to data that registrars and registries would not consider to be registration data such as billing data, account creation data, and the like. RySG proposes to revise the definition to reference the relevant data elements: “Registration Data” means the data elements identified in Annex [X], collected from a natural and legal person in connection with a domain name registration.” (Annex [X] would then identify the relevant data elements, as carried over from the whatever becomes the final version of Recommendation 4). Additional text is in bold and italics. RrSG supports this proposed revised definition. Happy to answer any questions. Many thanks. K Kristina Rosette Senior Corporate Counsel, IP – Domains rosettek(a)amazon.com<mailto:rosettek@amazon.com> | 703.407.1354

1 0

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 07 February 2019 at 14:00 UTC
by Andrea Glandon Feb. 6, 2019

Feb. 6, 2019

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/R50WBg Thank you. Kind Regards, Andrea

1 0

Re: [Gnso-epdp-team] [Ext] Re: ICANN Compliance question in relation to EPDP Recommendation 7
by Trang Nguyen Feb. 6, 2019

Feb. 6, 2019

Hi James, Please see below response from ICANN Contractual Compliance. -------------------------- The Whois Accuracy Program Specification requires registrars to take certain action regarding both Whois information and corresponding customer account holder contact information. Therefore, registrars may be required to provide account holder information to ICANN if they are to demonstrate compliance with the specification. Account holder information may also be shared with ICANN via copies of correspondence related to other contractual obligations. Privacy/proxy customer contact information may also be required to be shared with ICANN when requesting registrars’ demonstration of compliance with the Specification on Privacy and Proxy Registrations, as well as other provisions which require registrars to contact the underlying customer (see list of examples in the prior communication). This type of information is contained in the data processing overview as complainant/complainant representative information and information underlying public Whois. For these and the prior reasons stated, ICANN Contractual Compliance requests the EPDP team to amend Recommendation #7 to explicitly include the types of information listed in the Compliance data processing overview rather than being limited to select Whois data elements. -------------------------- Best, Trang ICANN Org Liaison From: "James M. Bladel" <jbladel(a)godaddy.com> Date: Monday, February 4, 2019 at 6:45 PM To: Trang Nguyen <trang.nguyen(a)icann.org>, Matt Serlin <matt(a)brandsight.com>, Alan Woods <alan(a)donuts.email>, Marika Konings <marika.konings(a)icann.org> Cc: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] Re: [Gnso-epdp-team] ICANN Compliance question in relation to EPDP Recommendation 7 Thank you, Trang and everyone…. With regard to the note from Compliance, I’d like to point out that we consistently decline to provide two (Account Holder and underlying Privacy/Proxy customer) of these data points to ICANN Compliance. I don’t think we’re unique among Registrars on this point. Those fields also aren’t mentioned in the linked document (Data Processing Overview). Prior to GDPR, we did provide ICANN with email communications logs (to demonstrate compliance with Registrant communications), and some of those email addresses may have been non-public/not published in WHOIS. But this ended last May, and the logs we share now contain only truncated addresses. Additionally, underlying Privacy/Proxy customer data is included in our data escrow deposits, but those files aren’t normally accessible to ICANN Compliance absent some business or technical failure. With this in mind, it would be fantastic if ICANN Legal / Compliance would clarify their proposed expansion of Recommendation #7 to include these two fields. Thanks— J. From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Trang Nguyen <trang.nguyen(a)icann.org> Date: Monday, February 4, 2019 at 7:31 PM To: Matt Serlin <matt(a)brandsight.com>, Alan Woods <alan(a)donuts.email>, Marika Konings <marika.konings(a)icann.org> Cc: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: Re: [Gnso-epdp-team] ICANN Compliance question in relation to EPDP Recommendation 7 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=/…> 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(a)icann.org> on behalf of Matt Serlin <matt(a)brandsight.com> Date: Wednesday, January 30, 2019 at 1:55 PM To: Alan Woods <alan(a)donuts.email>, Marika Konings <marika.konings(a)icann.org> Cc: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)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(a)icann.org> on behalf of Alan Woods <alan(a)donuts.email> Date: Tuesday, January 29, 2019 at 3:44 AM To: Marika Konings <marika.konings(a)icann.org> Cc: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)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=/…>, 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=DwMGa…> 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.…]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donut…> [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&…> [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_compa…> 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(a)icann.org<mailto:marika.konings@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(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

1 0

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

Feb. 6, 2019

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 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: 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 implementation, 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 for 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