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

Notes and action items from today's EPDP Team meeting
by Marika Konings Nov. 6, 2018

Nov. 6, 2018

Dear All, Please find below the notes and action items from today’s EPDP Team meeting. Best regards, Caitlin, Berry and Marika EPDP Team Meeting #23 Tuesday, 6 November 2018 Notes and Action Items High-level Notes/Actions: Action item #1: EPDP Team to save the date for the next F2F meeting on January 16-18 2019 (Wednesday-Friday). Support team to send out save the date calendar invite for the F2F meeting Action item #2: EPDP Team to review proposed language in relation to natural vs. legal person for inclusion in the Initial Report and come prepared to discuss this on Thursday's meeting. Action item #3: Support team to draft proposed language for inclusion in the Initial Report reflecting today's discussion regarding provision for Technical contact. Action item #4: Support team to mark language in relation to data retention as agreed in the Initial Report and harmonize data retention periods across data elements workbooks. Action item #5: Thomas to translate slides into policy recommendations and edits to the tables for proposed inclusion in the Initial Report for EPDP Team consideration prior to Thursday’s meeting. Questions for ICANN Org from the EPDP Team: Is indemnification provided by ICANN through a joint controller agreement an option? If EPDP agrees on policy that requires ICANN to indemnify, would the ICANN legal team and Board oppose it? Notes & Action items These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ. 1. Roll Call & SOI Updates (5 minutes) * Attendance will be taken from Adobe Connect * Please remember to mute your microphones when not speaking, and state your name before speaking for transcription purposes. * Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair (5 minutes) a. Proposed approach for reviewing and finalizing the Initial Report * See https://community.icann.org/x/5QDVBQ * Important that people provide input as soon as possible - the timeline is determined by the end goal of having new policy recommendations in place by 25 May 2019. Any additional time needed will affect the time available for other phases of the work. b. Update on F2F planning Action item #1: EPDP Team to save the date for the next F2F meeting on January 16-18 2019 (Wednesday-Friday). Support team to send out save the date calendar invite for the F2F meeting c. Proposed next steps in relation to small team #1 and #2 language for inclusion in the Initial Report See email sent by Kurt which was followed by proposed language for inclusion in the Initial Report. Action item #2: EPDP Team to review proposed language in relation to natural vs. legal person for inclusion in the Initial Report and come prepared to discuss this on Thursday's meeting. d. Review of outstanding action items * See https://community.icann.org/x/NwSNBQ e. Other updates, if applicable * Responsible parties for processing - need further info on what should be updated / discussed. To be added to agenda for Thursday's meeting. See also new agenda item 5. 3. Review of outstanding items for Initial Report and proposed approach Objective of discussion: 1. Confirm list of outstanding items to be considered in relation to Initial Report and approach for addressing these a. Review outstanding issues punch list (to be circulated) b. Confirm approach for addressing these c. Confirm next steps, if any * See email sent by Caitlin re. outstanding issues. * Idea is to introduce certain topics via email followed by EPDP Team call, certain topics can hopefully be addressed via email, some items where volunteers are needed. * Objective of the document and table is to track items that have been flagged as requiring further discussion and proposed approach. 4. Commence addressing outstanding items a. Technical contact redaction – any concerns in relation to proposed language for inclusion in the Initial Report? * Possible language to address this issue: In accordance with the EDPB’s guidance that GDPR does not apply to legal persons and personal data identifying individual employees (or third parties) acting on behalf of the registrant should not be made publicly available by default in the context of WHOIS: If the Registered Name Holder elects to provide contact information for a technical contact that differs from the Registered Name Holder, the Registrar is required to obtain consent from the technical contact prior to publication. One suggested method of obtaining this consent is to include this consent in the WHOIS Accuracy Program Specification Section 1.f.i. verification email. * Concerns expressed about relying on consent, especially if it is not provided by the data subject directly. If a RNH provides Tech contact data without consent, isn't the RNH responsible, not the registrar? * Adding on to an existing system could be problematic - something that needs further consideration, but not within the context of the current deliberations. * Previous agreement reached to continue to collect limited set of data elements (optional for RNH to provide) for technical contact, namely name, email and telephone. Concept of optional captured in data elements workbook C based on previous preliminary agreement: Optional data elements for the Registered Name Holder (RNH) to provide, but required for the registrar to offer as data elements the RNH may provide. * How do contracted parties currently handle tech contact info collection? Some registrars have stopped collecting that data - see also EPAG court case. Some are still collecting but have noted this is a potential vulnerability. * Should it also be optional for registrars to provide noting some of the issues? In that case a registrant can choose a registrar that provides this option if this is important for the registrant to provide. * Consent is used by others such as .CAT and ccTLDs so it is not necessarily a path that cannot be pursued. * Note that EDPB advice states: "registrants should be provided with the option of providing contact details for persons other than themselves if they wish to delegate these functions and facilitate direct communication with the persons concerned". In this context it is also noted that "it should be ensured that the individual concerned is informed". Consider asking a clarifying question to the EDPB concerning how this information process should take place and what, if any, additional obligations are there for the registrar, or whether this is purely a registrant responsibility. * The registrant is responsible for breaching the other individual's privacy, if such is the case. However, the registrar is responsible for ensuring that consent was obtained. * Individual registrars may voluntarily take on this risk and offer this option, if this is no longer a requirement. * EDPB advice should alleviate some of the legal concerns - may require further clarification from EDPB. * Document in the Initial Report the possible technical and legal challenges involved and outline the two different positions in relation to whether this should be required or optional for registrars to provide. Indicate that clarifying questions will be asked from the EDPB to further help inform deliberations in relation to this topic. Note that registrars may have legal liability for a RNH providing data about a third party, which is why they want the option. Action item #3: Support team to draft proposed language for inclusion in the Initial Report reflecting today's discussion. b. Data retention – any concerns in relation to proposed language for inclusion in the Initial Report? * Good reasoning to set out data retention period based on all the work that went into the data elements workbooks to discuss retention. * No opposition to include this in the Initial Report. * Consider harmonizing the data retention period across all the data elements workbooks. Action item #4: Support team to mark language in relation to data retention as agreed in the Initial Report and harmonize data retention periods across data elements workbooks. c. Confirm next steps, if any 5. Responsibilities - data processing See slides presented by Thomas Rickert Starting point: * We wanted to make a distinction between ICANN Purposes and other purposes * Reason was to identify which the areas that ICANN should govern and enforce are * We kept the language and called everything „ICANN purposes“ – that causes confusion * We have removed the things that ICANN should not govern – good. * We should make adjustments, though Status Quo / legal background: * Controller, Joint Controller and Processors are mentioned * Let‘s look at the Art. 29 (WP 169) distinctions * Let‘s discuss the micro vs the macro level * Liability issues – two layers * Data subjects claims – joint and several responsibility (indemnifications to balance) * Authorities‘ sanctions (Authorities will go after the wrongdoer) * Let‘s not be afraid of a joint controller scenario Way forward * Let‘s make everything part of a joint controller agreement * Let‘s specify the roles and responsibilities in there * Let‘s make indemnifications match the roles * We can still have parties outsourcing work (EBERO and Escrow e.g.) * Suggestion to change the language referring to "ICANN purposes" but describe that these are purposes that are governed by ICANN through consensus policies. * Determine for whole document that parties are joint-controllers, and document in joint controller agreement for which areas which party is responsible (for example, for Ebero and escrow only one party would be responsible). * Need to clarify the role of the different parties - important aspect of the Initial Report. Need a fair reflection of who asks for what and who does what. Those parties should take responsibility. * Indemnification by ICANN - would ICANN be willing to do this? Would change risk Question for ICANN Org: Is indemnification provided by ICANN through a joint controller agreement an option? (proposed rewording: if EPDP agrees on policy that requires ICANN to indemnify, would the ICANN legal team and Board oppose it?) Action item #5: Thomas to translate slides into language for proposed inclusion in the Initial Report for EPDP Team consideration prior to Thursday’s meeting. 5. Wrap and confirm next meeting to be scheduled for Thursday 8 November at 14.00 UTC. a) Confirm action items b) Confirm questions for ICANN Org, if an 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

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 08 November 2018 at 14:00 UTC
by Andrea Glandon Nov. 6, 2018

Nov. 6, 2018

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays at 14:00 UTC 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/qg68BQ Thank you. Kind Regards, Andrea

1 0

FW: [Ext] RE: General RySG comments on the first draft of the ePDP initial report
by Marika Konings Nov. 6, 2018

Nov. 6, 2018

Marc, thank you for the RySG input. Please find below in blue some responses / feedback in relation to your comments. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of "Anderson, Marc via Gnso-epdp-team" <gnso-epdp-team(a)icann.org> Reply-To: "Anderson, Marc" <mcanderson(a)verisign.com> Date: Monday, November 5, 2018 at 4:12 PM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] General RySG comments on the first draft of the ePDP initial report General RySG comments on the first draft of the ePDP initial report The RySG ePDP team is submitting the following general comments on the draft initial report dated 1 November 2018. We are simultaneously working on more detailed and substantive feedback to the specific points of the Report, but felt it was important to go on the record with this high-level feedback as soon as possible, given the short time remaining until the 19 November target to publish that report. To provide context for this feedback, we would like to remind the ePDP Leadership and Working Group of the RySG’s goal statement for participating in the ePDP: The Registries Stakeholder Group’s goal is to participate actively and in good faith towards a consensus policy that addresses the questions set forth in the EPDP Charter. The RySG believes that any consensus policy developed by the EPDP must provide a clear path for compliance with the GDPR, be commercially reasonable and implementable, takes into account our differing business models, and does not inhibit innovation. Months into our work, this statement still reflects our goals for this working group and the lens through which we view the preliminary draft of the Initial Report. Scope of the Initial Report The RySG ePDP team wishes to emphasize that the focus of the Initial Report for this first phase of the ePDP should be on affirming or altering the requirements of the Temporary Specification to ensure that ICANN’s contracted parties are able to comply with the GDPR in fulfilling the services they are required to provide. As currently drafted, the Initial Report does not make clear whether the scope of the ePDP includes only RDDS or all data processing activities undertaken by ICANN’s contracted parties; we recommend that such a distinction be made clearly at the outset of the Report. We also recommend that the Report provide answers to all the Charter questions that pertain to this first phase of the ePDP’s work. Any items that fall outside of the scope as stated above should be reserved for a later phase of the ePDP and, by extension, a subsequent report. Thanks for your feedback. We look forward to receiving suggestions for how to clarify the scope further beyond the language that is quoted from the charter. Highlighted in red are the charter questions for which no draft response is currently provided, but the hope is that some willing volunteers will be able to suggest proposed language for inclusion. Please note that no issues or questions related to the second phase of the EPDP’s work have been included. The report and the policy recommendations contained therein should be straightforward and easy to understand The report as currently drafted is difficult to read and understand, in particular for those readers who have not been actively participating in or consistently observing the work of the ePDP. We recommend that ICANN staff take particular care in explaining the terminology used in the report and providing sufficient context around the discussions that led up to the conclusions reached, where necessary. Furthermore, as the ePDP charter calls for this Initial Report to be sent to the EDPB for feedback on the applicability of the law in relation to the proposed recommendations, it is particularly important that the Report and attendant policy recommendations be written in a clear and straightforward manner that can facilitate such a review. Staff will review the draft Initial Report and aim to clarify terminology where possible. One option would be to include a glossary that explains in further detail some of the terminology that is used in the Initial Report? In relation to the EDPB, the idea would be to focus the questions for the EDPB in a separate letter as feedback has indicated that it is unlikely that the EDPB would review the Initial Report in its entirety. Of course, the Initial Report would be included as well, but the EPDP Team may want to focus on which questions and/or recommendations it may want to call specific attention to and call those out separately. Of course, any recommendations for making the policy recommendations clearer are welcome! Use of the purpose workbooks We believe that one of the reasons the current draft of the Initial Report is so difficult to follow is because it relies so heavily on the purpose worksheets that the Working Group developed. The RySG understood these worksheets to be a tool to aid the deliberations of the Working Group. The text contained in the worksheets has little meaning outside of the context of the discussion and deliberations of the Working Group and as such the workbooks are not suitable for wholesale inclusion in the Initial Report. We are also concerned that the completed worksheets have not been fully vetted by the ePDP Working Group. The Group’s deliberations have focused primarily on the purpose statement itself and the Group has not discussed the later sections of the worksheets in depth if at all, particularly since new versions of the worksheets were published following ICANN 63. Despite this fact, the Initial Report relies heavily on these later sections of the worksheets. Given the lack of discussion and, by extension, the absence of agreement on these portions, we find this approach to be problematic. The idea is to include the data elements workbooks as an annex so those interested can refer to it, but distill the most relevant parts into the body of the Initial Report which has already been done for a number of the Charter Questions that pertain to parts of the data elements workbooks. The EPDP Team was requested to review all data element workbooks by Friday 2 November to flag any issues that needed further discussion / consideration. So far, only input has been received in relation to purpose M and the responsibilities assigned to the different parties which have been added to the list of items to be further considered. If there are other areas that need further consideration, please call these out as soon as possible. Source of the (26) policy recommendations While the Initial Report devotes substantial text to the worksheets, it is not clear to the RySG ePDP team how the 26 preliminary policy recommendations were developed. There seems to be no clear connection between the discussions of the Working Group thus far and the specific recommendations contained in the Initial Report. We note the disclaimer on page 9 that “all content, and especially the draft recommendations will need to be cross-checked with the final language agreed to by the ePDP team before publication”. To aid in that cross-checking, it would be helpful if staff could cite the provenance of each recommendation, whether it be discussions during a particular meeting(s),one of the purpose worksheets, or an email thread. In light of the lack of clarity around the source of the 26 policy recommendations, the RySG ePDP team is particularly concerned about their presentation in the Initial Report. The phrasing of the recommendations implies that the Working Group reached consensus on these recommendations, and it is our understanding that no such consensus has yet been achieved. The initial report should not present recommendations on items where the group did not reach consensus. The majority of the policy recommendations are direct results of the work on the data elements workbooks and aim to reflect those (Preliminary Recommendations #1, #4, #5, #6, #7, #8, #9, #10, #11, #15, #17). Others are: * The result of policy recommendations that were agreed to in the context of the discussion on the data elements workbooks (Preliminary recommendation #2, #3), * Small team efforts (Preliminary Recommendations #12, #13, #14, #16), * Suggested during the LA F2F meeting in the context of a small group discussion (#18), * Derived from the discussions on the triage report and input provided in response to the triage survey (Preliminary Recommendations #19, #20, #21, #22, #23, #24, #25), * Aiming to capture recent discussions (Preliminary Recommendation #26). Do note that all items in blue in the Initial Report are still under discussion / review. The EPDP Team was asked to flag any other preliminary recommendations that require further discussion by Monday 5 November so that these can be added to the list of outstanding items. Ability to implement policy recommendations In addition to our concerns about the presentation of the policy recommendations in the Initial Report, it is also not immediately clear what the implementation impacts of those recommendations will be. As one of the parties who will have to implement the policy recommendations contained in the Final Report, it is important to us that such implications are duly considered when developing the recommendations. Please suggest language for inclusion in the report to capture this aspect. The Initial Report is expected to capture “A statement on the WG discussion concerning impact of the proposed recommendations, which could consider areas such as economic, competition, operations, privacy and other rights, scalability and feasibility” so this contribution will be very helpful in that regard. Similarly, this is usually also a question that is called out for public comment. Questions for community The draft of the Initial Report lists 10 questions for the community. The RySG ePDP team feels there are additional questions on which we should be asking the community to supply feedback, and will be providing suggestions along with our detailed comments. Great, thank you. Closing thoughts The RySG ePDP team wants to thank Staff and the Leadership team for all their hard work assembling this draft and their support getting us this far. We realize this is a first draft and work in progress. As stated we are working on specific and substantive comments for more detailed review but hope these general comments will be helpful as we move from first draft to a final version of the Initial Report. Marc Anderson mcanderson(a)verisign.com<mailto:mcanderson@verisign.com> Cell: 571.521.9943 Office: 703.948.3404 12061 Bluemont Way, Reston, VA 20190 Verisign.com [verisign.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.verisign.com_&d=DwM…> [Description: Description: Description: Verisign™]

1 0

Contracted Parties and Small Teams #1 and #2
by James M. Bladel Nov. 6, 2018

Nov. 6, 2018

ePDP Colleagues and WG Leadership - This morning, Registry and Registrar representatives met to discuss the status of potential recommendations from Small Group #1 (Legal vs. Natural) and Small Group #2 (Geographic Regions) in our Draft Initial Report. We concluded that there are some legal bases supporting these distinctions under GDPR and other data protection laws, and note that our Initial Report supports this. However, we reiterate our numerous high-level concerns against making any Consensus Policy recommendations for contractual requirements in these areas. Our concerns involve: * Legal - Aside from GDPR, other data protection laws are less clear on the distinction between legal and natural persons. Future regulations may contain contrary requirements. Furthermore, data of legal entities may contain or consist of personal information of natural persons, which would be entitled to protection under the GDPR and similar data protection regimes. Likewise, the geographic distinctions also create uncertainties. * Technical - Contracted Parties are uniquely situated to assess the current level of the technological means available to us, and it is our stated position that a technical basis to reliably and confidently make such a distinction does not exist. Especially because any distinction schema would be dependent upon Registrant Self-Identification, which is fraught with error. * Commercial - Developing and deploying this technology will involve significant costs, which may be prohibitive for smaller organizations and a barrier to market entry. Regardless of whether the distinction(s) are applied to new registrations or legacy domain names, it would be a logistical nightmare for Contracted Parties, and a source of confusion for Registrants, many of whom could lose access to their registrations. * Asymmetrical Risks vs. Benefits - Contracted Parties would assume all regulatory risks of such an obligations, exclusively for the benefit of unburdened third parties. * Scope - The distinction between Legal and Natural persons, or geographic regions, does not currently exist in the Domain Name System. Therefore, any recommendation mandating this change is outside the scope of the ePDP, and possibly the “picket fence” of Registrar and Registry contracts. As a result, and for the avoidance of doubt, Contracted Parties oppose/reject any recommendations for new contractual requirements in the ePDP Draft Initial Report, and will remain opposed to these recommendations as we move towards final recommendations. Thank you, J. ------------- James Bladel GoDaddy

9 13

Organization of outstanding initial report items
by Caitlin Tubergen Nov. 6, 2018

Nov. 6, 2018

Dear EPDP Team, In an effort to organize the outstanding issues in the Initial Report, ICANN Support Staff has created the attached Outstanding Issues Table. As previously noted, all outstanding issues in the Initial Report are highlighted in either blue, which denotes items currently under discussion, or red, which denotes items that have not been discussed. The table is intended to serve as a tool to assist in organizing the outstanding issues, and it’s divided into three categories, which denote the proposed method of review as follows: Outstanding Items to be Discussed by Mailing List, followed by EPDP Team Call Outstanding Items where an EPDP Volunteer is needed to draft proposed answers to Charter Questions Outstanding Items to be addressed via Mailing List, followed by call only if call is deemed necessary Admin or Policy Issues to be addressed via Mailing List The table also details: the corresponding Initial Report page(s) overarching topic specific issue proposed deadline relevant notes (which may include, for example, an email or wiki reference) Below, please find a high-level summary of the issues in each category. Items to be introduced via email, followed by EPDP Team call Purpose M (UDRP) – the remaining issue is disclosure of data subject information to possible UDRP Complainant, prior to filing the complaint. Since UDRP has not yet commenced: (a) is Purpose B sufficient for this data disclosure; (b) do the UDRP Rules need to be updated to reflect this new processing activity? Note: disclosure to complainant is not currently required under the UDRP Rules. Geographic Basis Differentiation – EPDP Team to discuss two compromise approaches (email from Monday, 5 November). Legal vs. Natural Persons-- EPDP Team to discuss two compromise approaches (email from Monday, 5 November). Disclosure of Technical Contact – EPDP team to confirm the proposed language that notes if a registrant optionally provides technical contact information, it should be that registrars must obtain the required consent in order to disclose this information Redaction of Registration Data – The EPDP Team recommends that redaction must be applied as follows to the data elements that are included in the initial report table. These data elements were discussed but had not received the full consensus of the group and should be discussed before going to public comment as an open issue: 1. Registrant Organization (currently shown as published) 2. Registrant City (currently shown as redacted) 3. Registrant State / Province (currently shown as redacted) Responsible Parties – Does the EPDP Team agree with the designation of responsible parties within the responsible parties document? Please refer specifically to the provided definition of joint controller within the document. Items where an EPDP Volunteer is needed to draft proposed answers to Charter Questions Data Processing Terms – EPDP Team Member needed to draft responses to Charter Questions k2, l4, m4, having to do with responsibilities in processing data. This is the replacement for language in sections 5-7 in the temporary specification. Issues to be addressed via email thread Data Escrow - On Thursday’s call, EPDP members noted ICANN should take geographical implications into account during the registry/registrar transition process. Support staff has drafted the following language: [The EPDP Team recommends that when designating a gaining registrar or emergency back-end registry operator (“EBERO”) to take over for a registrar or registry operator, ICANN shall consider the geographical implications. For example, if the failing registrar/registry is located within the European Economic Area and therefore subject to the GDPR, ICANN shall endeavor to appoint a gaining registrar or EBERO within the EEA, and ICANN shall update its procedures accordingly.][1] Data Retention - Does the EPDP Team agree with a de facto data retention period of registration period + one year? (The one year period conforms to the specific statute of limitations under the Transfer Dispute Resolution Policy.) Third-party Beneficiaries - A suggestion was made during the LA F2F meeting with respect to third-party beneficiaries – are there any concerns about adding this preliminary recommendation to the report? [The EPDP Team recommends that identification of Data Controllers & Processors or other recommendations made in this report will not affect “No Third-Party Beneficiary” clauses in existing ICANN-Contracted Party agreements.] Admin or Policy Issues to be addressed when Initial Report is Completed Sunsetting WHOIS 30-day Comment Period Draft language and preliminary recommendations concerning: Corresponding Consensus Policy updates Policy implementation (avoidance of gap b/w Temp Spec expiry and Policy Effective Date) Policy impact change analysis Thank you. Best regards, Marika, Berry and Caitlin [1] With respect to gaining registrars, ICANN shall update its De-Accredited Registrar Transition Procedure. With respect to EBEROs, ICANN shall update its gTLD Registry Transition processes.

1 0

Re: [Gnso-epdp-team] Contracted Parties and Small Teams #1 and #2
by Alan Greenberg Nov. 5, 2018

Nov. 5, 2018

James, you had earlier suggested that we remove fields such as admin contact and even tech contact. Can you explain how you proposed to address cases where the registrant had unique contents for those fields requiring the registrar to decide which one to use in the new merged fields. Or would you unilaterally just pick the values that were to be in the new RDS field(s). Perhaps how you planned to address that would help us understand how we might handle this case. Alan At 05/11/2018 05:57 PM, James M. Bladel wrote: Correct, Matt. I presume there would be -some- consequence for registrant inaction? If not, then it�s an Honor System. Or in this case, the default �punishment� would probably be redaction from WHOIS/RDS, because the registrar couldn�t leave the classification to chance. ------------- James Bladel GoDaddy ________________________________ From: Matt Serlin <matt(a)brandsight.com> Sent: Monday, November 5, 2018 4:53:43 PM To: Alan Greenberg; James M. Bladel; Mark Svancarek (CELA); gnso-epdp-team(a)icann.org Subject: Re: [Gnso-epdp-team] Contracted Parties and Small Teams #1 and #2 Alan � you called for having a �hard deadline� for existing registrants to make this determination so the logical next step would be some sort of impact to the domain name registration in cases where there was no response, correct? Any suggestion of a policy recommendation that results in registrants potentially having their domain name suspended or worse should be considered very carefully and have majority support within the group�something which I don�t believe would be the case here. Regards, Matt From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Alan Greenberg <alan.greenberg(a)mcgill.ca> Date: Monday, November 5, 2018 at 3:49 PM To: "James M. Bladel" <jbladel(a)godaddy.com>, "Mark Svancarek (CELA)" <marksv(a)microsoft.com>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: Re: [Gnso-epdp-team] Contracted Parties and Small Teams #1 and #2 James, the Whois Verification in the 2013 RAA called for domains to be suspended in some circumstances (as you have just described). What provisions have been discussed in the EPDP that would similarly require suspension? Alan At 05/11/2018 04:28 PM, James M. Bladel wrote: Mark � Shortly following the launch of the 2013 RAA’s requirements for WHOIS Verification, registrars noted that approx. 800,000 domains had been suspended in the first few months. The number continued to climb for a few years, and most were categorized as “false positives” Here’s some coverage of that data at the time. https://domainnamewire.com/2014/06/24/over-800000-domain-names-suspended-du… Any program that depends on Registrant self-categorization, self-declaration, or receipt & acting upon a notice has a huge error factor. For GoDaddy in 2014, the RAA verification rate was in the high 70% or low 80%, meaning that service to tens of thousands of customers was delayed or disrupted. It’s this experience that causes Contracted Parties (but particularly Registrars) to be skeptical of any requirement to just “send an email” or “have the Registrant check a box.” It doesn’t scale. J. ------------- James Bladel GoDaddy From: "Mark Svancarek (CELA)" <marksv(a)microsoft.com> Date: Monday, November 5, 2018 at 15:14 To: "James M. Bladel" <jbladel(a)godaddy.com>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: RE: Contracted Parties and Small Teams #1 and #2 James, can you clarify this: “many of whom could lose access to their registrations.” From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> On Behalf Of James M. Bladel Sent: Monday, November 5, 2018 10:57 To: gnso-epdp-team(a)icann.org Subject: [Gnso-epdp-team] Contracted Parties and Small Teams #1 and #2 ePDP Colleagues and WG Leadership - This morning, Registry and Registrar representatives met to discuss the status of potential recommendations from Small Group #1 (Legal vs. Natural) and Small Group #2 (Geographic Regions) in our Draft Initial Report. We concluded that there are some legal bases supporting these distinctions under GDPR and other data protection laws, and note that our Initial Report supports this. However, we reiterate our numerous high-level concerns against making any Consensus Policy recommendations for contractual requirements in these areas. Our concerns involve: Legal - Aside from GDPR, other data protection laws are less clear on the distinction between legal and natural persons. Future regulations may contain contrary requirements. Furthermore, data of legal entities may contain or consist of personal information of natural persons, which would be entitled to protection under the GDPR and similar data protection regimes. Likewise, the geographic distinctions also create uncertainties. Technical - Contracted Parties are uniquely situated to assess the current level of the technological means available to us, and it is our stated position that a technical basis to reliably and confidently make such a distinction does not exist. Especially because any distinction schema would be dependent upon Registrant Self-Identification, which is fraught with error. Commercial - Developing and deploying this technology will involve significant costs, which may be prohibitive for smaller organizations and a barrier to market entry. Regardless of whether the distinction(s) are applied to new registrations or legacy domain names, it would be a logistical nightmare for Contracted Parties, and a source of confusion for Registrants, many of whom could lose access to their registrations. Asymmetrical Risks vs. Benefits - Contracted Parties would assume all regulatory risks of such an obligations, exclusively for the benefit of unburdened third parties. Scope - The distinction between Legal and Natural persons, or geographic regions, does not currently exist in the Domain Name System. Therefore, any recommendation mandating this change is outside the scope of the ePDP, and possibly the “picket fence” of Registrar and Registry contracts. As a result, and for the avoidance of doubt, Contracted Parties oppose/reject any recommendations for new contractual requirements in the ePDP Draft Initial Report, and will remain opposed to these recommendations as we move towards final recommendations. Thank you, J. ------------- James Bladel GoDaddy _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

1 0

Fwd: Re: Small Team #1
by Alan Greenberg Nov. 5, 2018

Nov. 5, 2018

This message was supposed to have gone to the entire list. My apologies for not catching it earlier. Alan >Date: Fri, 02 Nov 2018 22:51:15 -0400 >To: Matt Serlin <matt(a)brandsight.com> >From: Alan Greenberg <alan.greenberg(a)mcgill.ca> >Subject: Re: [Gnso-epdp-team] Small Team #1 > >Good questions. > >As a first approximation (and without taking the >time to fully analyze this), one could use the >Organization field to determine status (as I >believe some registrars do now) serving notice >to the registrant (through the registrar >contact) just as you would of there is a renewal >without a credit card on file or if the credit >card had expired. If there is no contact >established using the registrar's best contact >details, on renewal use the presumed status >based on Org field, having fully tract the >attempts to contact registrant without any >reply. I presume you would in parallel change >your terms and conditions (as all registration >agreements allow) to advise of how you will be treating this. > >Registrars have in the last weeks suggesting >that we completely eliminate some fields such as >admin or tech contact. Surely if we were to do >that the registrar would have to contact a >registrant who had unique values in those fields >asking for direction on how to proceed. Or would >you just arbitrarily make changes without the registrant knowing?? > >Alan > > >At 02/11/2018 10:22 PM, you wrote: >>Thanks Alan for the perspective...may I ask >>what you envision would happen if a registrant >>of an existing domain name does not provide >>information about whether they are a natural or >>legal person by the “hard deadline” you >>describe below? Would the domain name then be >>revoked? Would the registrar be expected to >>make that determination in the absence of a response from the registrant? >> >>Thank you for the clarification. >> >>Regards, >>Matt >> >> > On Nov 2, 2018, at 8:13 PM, Alan Greenberg >> <alan.greenberg(a)mcgill.ca> wrote: >> > >> > There are sufficient competing redline versions that I will not >> > contribute another. We support the edits recently proposed by the GAC. >> > >> > However, I wish to make it clear that in the view of the ALAC, the >> > end-point must be that the WHOIS/RDS record distinguish between >> > natural and legal persons. It is fine to defer the implementation >> > plan, but that plan must end with all every gTLD record be flagged as >> > to whether the registrant is a legal or natural person. It is >> > appreciated that this cannot happen overnight, but at worst, the >> > implementation must set a hard deadline, preferably no later than the >> > next registration renewal. >> > >> > Alan >> > >> > _______________________________________________ >> > Gnso-epdp-team mailing list >> > Gnso-epdp-team(a)icann.org >> > https://mm.icann.org/mailman/listinfo/gnso-epdp-team

1 0

General RySG comments on the first draft of the ePDP initial report
by Anderson, Marc Nov. 5, 2018

Nov. 5, 2018

General RySG comments on the first draft of the ePDP initial report The RySG ePDP team is submitting the following general comments on the draft initial report dated 1 November 2018. We are simultaneously working on more detailed and substantive feedback to the specific points of the Report, but felt it was important to go on the record with this high-level feedback as soon as possible, given the short time remaining until the 19 November target to publish that report. To provide context for this feedback, we would like to remind the ePDP Leadership and Working Group of the RySG's goal statement for participating in the ePDP: The Registries Stakeholder Group's goal is to participate actively and in good faith towards a consensus policy that addresses the questions set forth in the EPDP Charter. The RySG believes that any consensus policy developed by the EPDP must provide a clear path for compliance with the GDPR, be commercially reasonable and implementable, takes into account our differing business models, and does not inhibit innovation. Months into our work, this statement still reflects our goals for this working group and the lens through which we view the preliminary draft of the Initial Report. Scope of the Initial Report The RySG ePDP team wishes to emphasize that the focus of the Initial Report for this first phase of the ePDP should be on affirming or altering the requirements of the Temporary Specification to ensure that ICANN's contracted parties are able to comply with the GDPR in fulfilling the services they are required to provide. As currently drafted, the Initial Report does not make clear whether the scope of the ePDP includes only RDDS or all data processing activities undertaken by ICANN's contracted parties; we recommend that such a distinction be made clearly at the outset of the Report. We also recommend that the Report provide answers to all the Charter questions that pertain to this first phase of the ePDP's work. Any items that fall outside of the scope as stated above should be reserved for a later phase of the ePDP and, by extension, a subsequent report. The report and the policy recommendations contained therein should be straightforward and easy to understand The report as currently drafted is difficult to read and understand, in particular for those readers who have not been actively participating in or consistently observing the work of the ePDP. We recommend that ICANN staff take particular care in explaining the terminology used in the report and providing sufficient context around the discussions that led up to the conclusions reached, where necessary. Furthermore, as the ePDP charter calls for this Initial Report to be sent to the EDPB for feedback on the applicability of the law in relation to the proposed recommendations, it is particularly important that the Report and attendant policy recommendations be written in a clear and straightforward manner that can facilitate such a review. Use of the purpose workbooks We believe that one of the reasons the current draft of the Initial Report is so difficult to follow is because it relies so heavily on the purpose worksheets that the Working Group developed. The RySG understood these worksheets to be a tool to aid the deliberations of the Working Group. The text contained in the worksheets has little meaning outside of the context of the discussion and deliberations of the Working Group and as such the workbooks are not suitable for wholesale inclusion in the Initial Report. We are also concerned that the completed worksheets have not been fully vetted by the ePDP Working Group. The Group's deliberations have focused primarily on the purpose statement itself and the Group has not discussed the later sections of the worksheets in depth if at all, particularly since new versions of the worksheets were published following ICANN 63. Despite this fact, the Initial Report relies heavily on these later sections of the worksheets. Given the lack of discussion and, by extension, the absence of agreement on these portions, we find this approach to be problematic. Source of the (26) policy recommendations While the Initial Report devotes substantial text to the worksheets, it is not clear to the RySG ePDP team how the 26 preliminary policy recommendations were developed. There seems to be no clear connection between the discussions of the Working Group thus far and the specific recommendations contained in the Initial Report. We note the disclaimer on page 9 that "all content, and especially the draft recommendations will need to be cross-checked with the final language agreed to by the ePDP team before publication". To aid in that cross-checking, it would be helpful if staff could cite the provenance of each recommendation, whether it be discussions during a particular meeting(s),one of the purpose worksheets, or an email thread. In light of the lack of clarity around the source of the 26 policy recommendations, the RySG ePDP team is particularly concerned about their presentation in the Initial Report. The phrasing of the recommendations implies that the Working Group reached consensus on these recommendations, and it is our understanding that no such consensus has yet been achieved. The initial report should not present recommendations on items where the group did not reach consensus. Ability to implement policy recommendations In addition to our concerns about the presentation of the policy recommendations in the Initial Report, it is also not immediately clear what the implementation impacts of those recommendations will be. As one of the parties who will have to implement the policy recommendations contained in the Final Report, it is important to us that such implications are duly considered when developing the recommendations. Questions for community The draft of the Initial Report lists 10 questions for the community. The RySG ePDP team feels there are additional questions on which we should be asking the community to supply feedback, and will be providing suggestions along with our detailed comments. Closing thoughts The RySG ePDP team wants to thank Staff and the Leadership team for all their hard work assembling this draft and their support getting us this far. We realize this is a first draft and work in progress. As stated we are working on specific and substantive comments for more detailed review but hope these general comments will be helpful as we move from first draft to a final version of the Initial Report. Marc Anderson mcanderson(a)verisign.com<mailto:mcanderson@verisign.com> Cell: 571.521.9943 Office: 703.948.3404 12061 Bluemont Way, Reston, VA 20190 Verisign.com<http://www.verisign.com/>

1 0

Reminder - Action items due today, Friday 2 November
by Marika Konings Nov. 5, 2018

Nov. 5, 2018

Dear All, As a reminder, the following action items are due today, Friday 2 November COB, in order to allow the leadership team and staff to plan the meetings and agenda’s going forward: * Each group (SG/C/AC) to review the responsible parties overview for all purposes and identify which designations need to be further considered. See https://docs.google.com/document/d/1-rdfchOwpANFVKOtnM_9bPp-zT4JAvTN8dJqebd…. * Each group (SG/C/AC) to review latest versions of data elements workbooks and flag any issues that need to be reviewed prior to publication of Initial Report. See https://community.icann.org/x/5AC8BQ. * Each group (SG/C/AC) to express the group's views and/or proposed edits on small team #1 responses to charter questions and preliminary recommendations with the mailing list (see original version and input received to date attached). * Each group (SG/C/AC) to express the group's views and/or proposed edits on the revised responses of the small team #2 charter question responses with the mailing list (see original version and input received to date attached). 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…>.

6 5

Re: [Gnso-epdp-team] Request for Additional Time on the Initial Report
by Marika Konings Nov. 5, 2018

Nov. 5, 2018

Dear EPDP Team, As a reminder, we are first and foremost looking for you to flag any responses to charter questions and/or preliminary recommendations that need further discussion / consideration beyond those items that have already been flagged in the Initial Report (in blue). This will facilitate the planning of meetings & agenda’s going forward. This information should be provided as soon as possible (ideally by the end of today). Substantive comments / edits to the Initial Report can follow after that, ideally by Wednesday 7 November at the latest. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Margie Milam <margiemilam(a)fb.com> Date: Monday, November 5, 2018 at 1:12 PM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Request for Additional Time on the Initial Report HI – On behalf of the BC, we also request additional time to submit comments on the Initial Report. Similar to the Registrars, we are not in a position to commit to a specific day to get them submitted at this point. All the best, Margie

1 0