November 2018 - Gnso-epdp-team

Recordings, Attendance & AC chat / GNSO Temp Spec gTLD RD EPDP / Tuesday, 06 November 2018
by Andrea Glandon Nov. 7, 2018

Nov. 7, 2018

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 Tuesday, 06 November 2018 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/qA68BQ MP3: https://audio.icann.org/gnso/gnso-epdp-temp-spec-gtld-registration-data-06n… AC Recording: https://participate.icann.org/p1qdyha6o2k/<https://participate.icann.org/p1qdyha6o2k/?OWASP_CSRFTOKEN=d68452e1ebd0e38d…> ** 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

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

Request for Additional Time on the Initial Report
by Margie Milam Nov. 5, 2018

Nov. 5, 2018

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

Proposed Agenda and items for input - EPDP Team Meeting #23
by Marika Konings Nov. 5, 2018

Nov. 5, 2018

Dear All, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Tuesday 5 November at 14.00 UTC. In relation to agenda item 4, please review the following and provide your feedback on the mailing list to help inform the discussion. * Technical contact consent In relation to the data elements that are optional to provide for the Registered Name Holder (RNH), the following language was added to the preliminary recommendation to reflect that the registrar may not have a direct contractual relationship with the data subject whose information is provided by the RNH: If the Registered Name Holder elects to provide contact information for a technical contact who does not have a direct contractual relationship with the registrar, the registrar is required to redact or obtain all necessary consent from the technical contact prior to publication. However, noting that it is currently not proposed that technical contact information would be published, we would suggest making the following update: If the Registered Name Holder elects to provide contact information for a technical contact who does not have a direct contractual relationship with the registrar, the registrar is required to redact or obtain all necessary consent from the technical contact prior to publication any disclosure. Question for the EPDP Team: are you comfortable with the inclusion of this revised language as part of preliminary recommendation #10? If not, please provide your rationale and proposed changes / edits prior to the meeting. * Data retention This recommendation is derived from Data Elements Workbook A. Are there any concerns about this recommendation? The EPDP Team recommends that Registrars are required to retain the herein-specified data elements for a period of one year following the life of the registration. This retention period conforms to the specific statute of limitations within the Transfer Dispute Resolution Policy (“TDRP”). Other relevant parties, including Registries, escrow providers and ICANN Compliance, have separate retention periods less than or equal to one year accordingly and in line with the GDPR requirements. Question for the EPDP Team: are you comfortable with the inclusion of this preliminary recommendation? If not, please provide your rationale and proposed changes / edits prior to the meeting. Note that in relation to small team #1 and #2 discussions, the leadership team will be putting forward a proposed path forward shortly. Best regards, Caitlin, Berry and Marika EPDP Meeting #23 Agenda Tuesday, 5 November 2018 1. Roll Call & SOI Updates (5 minutes) 2. Welcome and Updates from EPDP Team Chair (5 minutes) * Proposed approach for reviewing and finalizing the Initial Report * Update on F2F planning * Proposed next steps in relation to small team #1 and #2 language for inclusion in the Initial Report * Review of outstanding action items * Other updates, if applicable 1. 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 * Review outstanding issues punch list (to be circulated) * Confirm approach for addressing these * Confirm next steps, if any 1. Commence addressing outstanding items * Technical contact redaction – any concerns in relation to proposed language for inclusion in the Initial Report? * Data retention – any concerns in relation to proposed language for inclusion in the Initial Report? * Confirm next steps, if any 1. Wrap and confirm next meeting to be scheduled for Thursday 8 November at 14.00 UTC. * Confirm action items * Confirm questions for ICANN Org, if any 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…>.

5 6

Re: [Gnso-epdp-team] Further Input from the IPC/BC on Small Team #1 and #2 issues
by Alan Greenberg Nov. 5, 2018

Nov. 5, 2018

Quote from your message: "It is a black-and-white breach of consumer expectations." Ayden, I am delighted that as opposed to some of your colleagues, you now believe that consumer protection is fully within ICANN's remit. And that we need to build "ethics" into all of our contracts. I fear you may have some difficulty in getting agreement on who's ethics to select. Lastly, please consider that although other jurisdictions have and will continue to enact privacy regulations, they will not all have a baseline of those rules in the GDPR. I am afraid that in the long term, we will have no choice to to adhere to a varying set of regulations and contracted parties that wish to straddle jurisdictions will have to adapt. Regarding cost, it may be unfortunate that some of our new rules will impose costs on contracted parties and thus registrants. Just as the costs of GDPR itself, which are not trivial, are being borne by them. Alan At 04/11/2018 06:35 AM, Ayden Férdeline wrote: I agree with Farzaneh; all domain name registrants should be shown a baseline of respect, regardless of whether or not they live in a jurisdiction with strong and enforced privacy protections. This is as much an ethical consideration as it is a legal one. While in some other sectors there are fuzzy questions around what information is private and sensitive, and what is innocuous and does not need to be protected, in our situation the case is very simple. There is demonstrable harm that can result from the disclosure of registration data. And look on Twitter at the messages that registrars receive from consumers upset that their registration data has been made public (or “sold” is the perception many consumers have). It is a black-and-white breach of consumer expectations. No one is registering a domain name with the implicit understanding that their contact information will be obtained by a third party. I note this appreciating that some third parties, like law enforcement, will have a need to access registration data, but relying on consumers to themselves take steps to protect their personal information is not going to fly. You can’t ask someone to check a box noting whether or not they are a legal or natural person, because most registrants won’t know the answer or why the distinction matters. What if a natural person becomes confused and indicates they are a legal person? I don’t believe the BC and IPC's proposed language that, “Registrar is entitled to rely on this data in making legal determinations including, without limitation, those related to GDPR and relevant data protection laws,” would shield the contracted party in any meaningful way. Under European Union law at least, standard contract terms must be fair. A registrant cannot sign away a right. A contract is not allowed to create an imbalance between your rights and obligations as a consumer and the rights and obligations of sellers and suppliers. What differentiates the GDPR from its weaker, 1995 predecessor is that it tries to correct the power imbalance that exists between a data controller and a data subject. There were natural information asymmetries that had not self-corrected. The right to know what information has been collected about you in the GDPR, and the right to ask that it be corrected or deleted (also in the GDPR) all support the thesis that there is a power imbalance at play here. The onus in the GDPR is on those with more power - whoever is collecting and processing personal information - to behave in a reasonable way towards consumers and to put the interests of the individual above their own. I know that I have only referenced the GDPR above but that I am asking that GDPR-equivalent protections be applied much more broadly to all registrants. I say this for three reasons. Primarily, because I think it is not unthinkable that increased data protection regulations will be coming to other markets in the near future, including the United States. However there is also the question of cost and whether it is fair to impose upon the contracted parties (and, ultimately, domain name registrants) the cost of achieving compliance with the GDPR by building a separate, parallel process/system for the EU market and a separate, parallel process/system for other markets, or whether it is more economical to simply convert all of one's business processes to conform to the more stringent regulation. And finally, ethics: just because someone lives in a jurisdiction that does not guarantee a right today does not mean there is not an ethical duty of care to deliver it. Kind regards, Ayden Férdeline ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, 4 November 2018 07:37, farzaneh badii <farzaneh.badii(a)gmail.com> wrote: Dear Diane, How can registrars determine the applicable law even if the geographical information is accurate? I don't think registrars can actually determine which law outside of their own jurisdiction applies to their registrants even if they know the geographical location. For example, as far as I know EU citizens anywhere in the world are protected by GDPR. So their geographical location does not determine what law applies. Registrars have to abide by their local laws, the court of law determines the applicable law and some registries have the choice of law clauses in their agreements with registrars which cannot be in conflict with the local laws of the registrars. All in all determining the "jurisdiction" of data subject is not dependent only on the geographical location of the registrant in this case. Also I think every domain name registrant regardless of where they are located deserve minimum data protection. They are consumers by the way! I am getting increasingly puzzled by IPC/BC interpretation of "accuracy" of personal information of data subjects under GDPR. In my opinion the concept of accuracy in GDPR is actually supposed to protect data subjects and not to be used against them. Accurate information is not about keeping the data accurate so that it can be displayed and accessed and mined by many around the world! The accuracy of data is a right given to data subjects so that inaccurate data cannot be used against them in court and other forums, or be denied a service or end in violating their rights. I believe they have the right for their information to be accurate and not the responsibility (under GDPR) to maintain it accurately. The registrars under GDPR have to maintain the data of domain name registrants "uptodate" to reduce privacy risks. They don't have to keep the database accurate so that they can distinguish between legal and natural persons. I believe by ICO you mean Information Commissioners Office. Specifically this page: https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-r… The natural v legal distinction is not only burdensome for the CPs or opens them to liability. It is dangerous for noncommercial/not for porfit/ advocacy organizations that have registered domain names and are vulnerable to attacks of all sorts. I assume IPC/BC wants this distinction so that the org personal sensitive data won't be redacted. I would like to know why. I would like to know why while some groups are fiercely working to have access to personal and sensitive data of domain name registrants for their legitimate interest, also work towards exposing domain name registrants sensitive data to the world. Farzaneh On Fri, Nov 2, 2018 at 10:13 PM Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: This all sounds right to me. Alan At 02/11/2018 09:28 PM, Plaut, Diane wrote: Dear EPDP Team- In our efforts to overcome a significant hurdle through our EPDP work � that CPs have expressed they cannot rely on the accuracy of Registrant input and, therefore, are hesitant to distinguish between legal and natural persons or count on country information input by Registrantâ��s because if it is no not accurate, they are concerned they will be liable for identifying the person incorrectly or determining the applicable law incorrectly. We have discussed in the EPDP the prospect of trying to get input from DPAs to confirm that it is reasonable to count on Registrant input. Thomas Rickert has most recently proposed in Barcelona, setting up a meeting with the EDPB and I have expressed my support and desire to partake in this and the legal effort. In the meanwhile, I think it is beneficial for us to try to do our own research and show DPA insight on this topic. To this end, I provide below, guidance from the ICO on this topic. The IPC/BC wishes to add this to the Small Team #1and #2 comments in support of our positions on the issues of supporting the distinction of legal and natural persons and applying relevant country laws. The Accuracy of information provided by data subjects Article 5(1)(d)/(2) GDPR provides that controllers have an obligation to demonstrate compliance with the requirement that: Personal data shall be�accurate and, where necessary, keept up tto date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (â��accuracyâ��). According to the ICO, this means that controllers must take all reasonable steps to ensure that the personal data they hold is not incorrect or misleading as to any matter of fact. However, the GDPR does not explicitly distinguish between personal data provided by the data subject, provided by a third party or created by the controller – the same obligation applies in each such caase. As to whether it is possible to rely on the data subject for the accuracy of the information, the ICO has confirmed in its guidance that this is possible. In particular, the ICO states that: â��In some cases it t is reasonable to rely on the individual to tell you when their personal data has changed, such as when they change address or other contact details. It may be sensible to periodically ask individuals to update their own details, but you do not need to take extreme measures to ensure your records are up to date, unless there is a corresponding privacy risk which justifies this.â� Howeever, if the controller learns that information is no longer accurate/up to date (either from the data subject or from other information which comes to light), the controller should update its records accordingly. The ICO also recognizes that it may be impractical to check the accuracy of personal data someone else provides. In such cases, the ICO suggests that controllers must: Â· accurately record the information provided; Â· accurately record the source of the information; Â· take â��reasononable stepsâ� in the circumstances to ensure the accurracy of the information; and Â· carefully consider any challenges to the accuracy of the information. Given that the data subject itself inputs and supplies the data registration information (elements) in issue, there is a strong argument that under the above guidance by the ICO, it is reasonable to reply on the accuracy of this information for purposes of distinguishing between legal and natural persons and for purposes of correct geographical information in relation to applicable law purposes. Moreover, in addition to and to support the above, the IPC and BC further strongly support the following legal recommendation be added to both Small Team #1 and Small Team #2 input that contractual provisions be added to agreements so that overall accuracy standards are achieved, stating: The above-identified Registrant represents and warrants that the data provided herein is true, complete and accurate. It could even go one step further and expressly say that Registrar is entitled to rely on this data in making legal determinations including, without limitation, those related to GDPR and relevant data protection laws. Nothing in the above, limits the application of the ICO guidance from supporting greater accuracy required by all parties. Sincerely, Diane Diane Plaut General Counsel and Privacy Officer Direct +1 646-899-2806 â�¨ diane.plaut(a)corsearch.com<mailto:diane.plaut@corsearch..com> 220 West 42nd Street, 11th Floor, New York, NY 10036, United Statesâ�¨www.corsearch.com Join Corsearch on Twitter<https://twitter.com/corsearch> Linkedin<https://www.linkedin.com/company/2593860/> Trademarks + Brands<http://trademarksandbrands.corsearch.com/> Customer Service/Platform Support: 1 800 SEARCH1â�¢ (1 800 732 72441)â�¨ Corsearch.USCustomerService(a)corsearch.com<mailto:Corsearch.USCustomerService@corssearch.com> Confidentiality Notice: This email and its attachments (if any) contain confidential information of the sender. The information is intended only for the use by the direct addressees of the original sender of this email. If you are not an intended recipient of the original sender (or responsible for delivering the message to such person), you are hereby notified that any review, disclosure, copying, distribution or the taking of any action in reliance of the contents of and attachments to this email is strictly prohibited. If you have received this email in error, please immediately notify the sender at the address shown herein and permanently delete any copies of this email (digital or paper) in your possession. _______________________________________________ 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

1 0

Re: [Gnso-epdp-team] Further Input from the IPC/BC on Small Team #1 and #2 issues
by Alan Greenberg Nov. 5, 2018

Nov. 5, 2018

Just to note that as Hadia has since pointed out, her first sentence was a simplification with she covered a few lines down with "The data rights of the registrants is determined by their location (not their citizenship) in addition to the location of the controller and processor." Farzi's original statement "For example, as far as I know EU citizens anywhere in the world are protected by GDPR" may well have been accurate but by this point in the EPDP, hopefully everyone knows that this is not the case. Alan At 04/11/2018 01:44 PM, Alan Woods wrote: Just wish to jump in on Hadiaâ€™s point alone (I have many thoughts on the submissions but letâ€™s see how the leadership team present the divergence, and we can respond accordingly) But that being said, I am moved to this email, to clarify a point of law, as Hadia, you are somewhat mistaken and clarification is needed to avoid further confusion. To your point Hadia, you are only looking at half the picture. If mere residency of the data subject were the sole determinative factor, then yes I could accept the validity of that argument; however, the GDPR applies to all European data not just the data of European resident persons. E.g. If I am an EU citizen, residing in Mongolia, but I use a European registrar, then the GDPR will apply to my registration data; If I am a US citizen residing in Europe and chose an American registrar , the GDPR applies; If I am a US citizen, residing in Mongolia, and I use a South African registrar, but via a EU reseller, then the GDPR applies... and so on... We must be clear that this task of properly identifying the GDPRâ€™s applicability is not as simple or straightforward a task as it is being lauded by some. Kind regards, Alan On Sun 4 Nov 2018 at 17:45, farzaneh badii <farzaneh.badii(a)gmail.com<mailto:farzaneh.badii@gmail.com> > wrote: The question was whether accurate Geo location can help CPs identify applicable laws. Yes GDPR applies to data subjects who are "in" the EU. And a lot of sources on Google say that EU citizens are not protected by GDPR when outside of the EU and it applies to those who are "in" the EU when data being processed. So non resident EU citizens (A French national living in China) is not a GDPR data subject. There are still arguments over that as well. The only thing that might be clear is that those physically in the EU at the time of registration (regardless of their nationality) are data subject just to make sure gdpr coverage goes beyond citizenship. But it is not clear what would happen to EU citizens on vacation or long stays in other countries. Does being "in" the EU refer to the "location" of data subject at the time of registration or does it for EU citizens refer to the main place of residence? A French citizen who registers a domain name on vacation in the Caribbean is not physically present in the EU at the time of registration. Is that person not subject to GDPR because they were not in the EU ? Or if they register a domain in Port of Spain indicating their location as Paris then what would happen ?Is there a EDPB avice on this? All in all, yes GDPR applies to those who are "in" the EU regardless of their nationality. But in the case of domain name registration, geographical location does not clarify the applicable law in my opinion. Many other factors have to be taken into account. What is being in the EU? does that mean where they have their main residency? where they pay taxes? where their cruise is taking them? If we don't have clarity on this we cannot simply say if they make their geographical location clear we have established the applicable law correctly. Hadia I am glad you are asking which organizations would want to hide their physical address from the public. I hope this can provide some explanation as to why I get irritated when we are lumping all organizations together and ask for their sensitive data to be exposed to the public: Organizations that are critical of their governments and even if established abroad can be under threat Organizations that work for minority rights and women rights Organizations that are trying to hold various actors accountable Organizations that analyze and criticize religious extremists Human rights law firms/HR lawyers in certain parts of this world are in prison ... I can continue some say we are not here to protect and advance human rights. We are not here to violate HR and put people in danger either. We are not here to protect all consumers globally from whatever fraud regardless of whether it relates to DNS. We are not here to facilitate all kinds of law enforcement action that do not relate to security stability resiliency of DNS, we are not here to protect trademark and IP at any cost and at a global scale and beyond ICANN mission. Does distinguishing between legal and natural person help with advancing ICANN purpose and mission or third party interest? Please tell me how. I wish someone could answer my question. For the past three months, this group was dominated by access to WHOIS sensitive personal data discussion. We compromised. Access is now an ICANN purpose. Is it not enough? Is it not enough to pursue your purpose? Why is there a need for distinguishing between legal vs natural persons? If you have legitimate interest you can access anyway. Please let me know why it's not enough to give access to legitimate interest parties and redact orgs sensitive data too. On Sun, Nov 4, 2018 at 10:08 AM Arasteh < kavouss.arasteh(a)gmail.com<mailto:kavouss.arasteh@gmail.com>> wrote: Dear All There are avalanche of contradicting messages Everyone pushes for its own views Pls ce the validity of all statement Haida Pls clarify what you said about GDPR against a clause of articles to validate what you stated . Others are talking of accuracy They are requested to explore what accuracy they are looking by giving examples Fritz is kindly requested to reconcile all these contradictory statements Regards Kavouss Sent from my iPhone On 4 Nov 2018, at 15:02, Hadia Abdelsalam Mokhtar EL miniawi <Hadia(a)tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hi Farzi, Just a quick clarification GDPR does not apply to EU citizens not residing in the EU. The GDPR is not concerned with the citizenship it is concerned with where the person is located. If you leave an EU country and travel to a non EU country you are no longer protected by the GDPR. The data rights of the EU citizens located outside of the EU is protected by the laws of the territory that they are at. The data rights of the registrants is determined by their location (not their citizenship) in addition to the location of the controller and processor. And with regard to protecting registrants we should also not forget the necessity of protecting the registrants against domains hijacking and thefts which could be devastating to the domain name holder not only financially but in terms of accessibility to the site in case it is a not for profit web page or domain and the rights of the registrants to be able to pursue their rights in this regard. Finally and on another note which legal entities or businesses would like to be kept hidden?? Best Hadia From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of farzaneh badii Sent: Sunday, November 04, 2018 9:38 AM To: Alan Greenberg Cc: gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>; alex(a)the-online.net<mailto:alex@the-online.net>; GNSO EPDP Subject: Re: [Gnso-epdp-team] Further Input from the IPC/BC on Small Team #1 and #2 issues Dear Diane, How can registrars determine the applicable law even if the geographical information is accurate? I don't think registrars can actually determine which law outside of their own jurisdiction applies to their registrants even if they know the geographical location. For example, as far as I know EU citizens anywhere in the world are protected by GDPR. So their geographical location does not determine what law applies. Registrars have to abide by their local laws, the court of law determines the applicable law and some registries have the choice of law clauses in their agreements with registrars which cannot be in conflict with the local laws of the registrars. All in all determining the "jurisdiction" of data subject is not dependent only on the geographical location of the registrant in this case. Also I think every domain name registrant regardless of where they are located deserve minimum data protection. They are consumers by the way! I am getting increasingly puzzled by IPC/BC interpretation of "accuracy" of personal information of data subjects under GDPR. In my opinion the concept of accuracy in GDPR is actually supposed to protect data subjects and not to be used against them. Accurate information is not about keeping the data accurate so that it can be displayed and accessed and mined by many around the world! The accuracy of data is a right given to data subjects so that inaccurate data cannot be used against them in court and other forums, or be denied a service or end in violating their rights. I believe they have the right for their information to be accurate and not the responsibility (under GDPR) to maintain it accurately. The registrars under GDPR have to maintain the data of domain name registrants "uptodate" to reduce privacy risks. They don't have to keep the database accurate so that they can distinguish between legal and natural persons. I believe by ICO you mean Information Commissioners Office. Specifically this page: https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-r… The natural v legal distinction is not only burdensome for the CPs or opens them to liability. It is dangerous for noncommercial/not for porfit/ advocacy organizations that have registered domain names and are vulnerable to attacks of all sorts. I assume IPC/BC wants this distinction so that the org personal sensitive data won't be redacted. I would like to know why. I would like to know why while some groups are fiercely working to have access to personal and sensitive data of domain name registrants for their legitimate interest, also work towards exposing domain name registrants sensitive data to the world. Farzaneh On Fri, Nov 2, 2018 at 10:13 PM Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: This all sounds right to me. Alan At 02/11/2018 09:28 PM, Plaut, Diane wrote: Dear EPDP Team- In our efforts to overcome a significant hurdle through our EPDP work â€“ that CPs have expressed they cannot rely on the accuracy of Registrant input and, therefore, are hesitant to distinguish between legal and natural persons or count on country information input by RegistrantÃ¢€™s because if it is not accurateate, they are concerned they will be liable for identifying the person incorrectly or determining the applicable law incorrectly. We have discussed in the EPDP the prospect of trying to get input from DPAs to confirm that it is reasonable to count on Registrant input. Thomas Rickert has most recently proposed in Barcelona, setting up a meeting with the EDPB and I have expressed my support and desire to partake in this and the legal effort. In the meanwhile, I think it is beneficial for us to try to do our own research and show DPA insight on this topic. To this end, I provide below, guidance from the ICO on this topic. The IPC/BC wishes to add this to the Small Team #1and #2 comments in support of our positions on the issues of supporting the distinction of legal and natural persons and applying relevant country laws. The Accuracy of information provided by data subjects Article 5(1)(d)/(2) GDPR provides that controllers have an obligation to demonstrate compliance with the requirement that: Personal data shall be…accurate and, where necessary, keept up tto date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (Ã¢€˜accuracyÃ¢€™). According to the ICO, this means that controllers must take all reasonable steps to ensure that the personal data they hold is not incorrect or misleading as to any matter of fact. However, the GDPR does not explicitly distinguish between personal data provided by the data subject, provided by a third party or created by the controller – the same obligation applies in each such caase. As to whether it is possible to rely on the data subject for the accuracy of the information, the ICO has confirmed in its guidance that this is possible. In particular, the ICO states that: Ã¢€œIn somome cases it is reasonable to rely on the individual to tell you when their personal data has changed, such as when they change address or other contact details. It may be sensible to periodically ask individuals to update their own details, but you do not need to take extreme measures to ensure your records are up to date, unless there is a corresponding privacy risk which justifies this.Ã¢€ However, if the controller learns that information iis no longer accurate/up to date (either from the data subject or from other information which comes to light), the controller should update its records accordingly. The ICO also recognizes that it may be impractical to check the accuracy of personal data someone else provides. In such cases, the ICO suggests that controllers must: Ã‚Â· accurately record the information provided; Ã‚Â· accurately record the source of the information; Ã‚Â· take Ã¢â‚¬œreasonable stepsÃ¢€ in the circumstances to ensure e the accuracy of the information; and Ã‚Â· carefully consider any challenges to the accuracy of the information. Given that the data subject itself inputs and supplies the data registration information (elements) in issue, there is a strong argument that under the above guidance by the ICO, it is reasonable to reply on the accuracy of this information for purposes of distinguishing between legal and natural persons and for purposes of correct geographical information in relation to applicable law purposes. Moreover, in addition to and to support the above, the IPC and BC further strongly support the following legal recommendation be added to both Small Team #1 and Small Team #2 input that contractual provisions be added to agreements so that overall accuracy standards are achieved, stating: The above-identified Registrant represents and warrants that the data provided herein is true, complete and accurate. It could even go one step further and expressly say that Registrar is entitled to rely on this data in making legal determinations including, without limitation, those related to GDPR and relevant data protection laws. Nothing in the above, limits the application of the ICO guidance from supporting greater accuracy required by all parties. Sincerely, Diane Diane Plaut General Counsel and Privacy Officer Error! Filename not specified. Direct +1 646-899-2806 Ã¢€Â¨ diane.plaut(a)corsearch.com<mailto:diane.plaaut@corsearch.com> 220 West 42<https://maps.google.com/?q=220+West+42&entry=gmail&source=g>nd Street, 11th Floor, New York, NY 10036, United StatesÃ¢€ÂÂ¨www.corsearch.com<http://www.corsearch.com/> Join Corsearch on Twitter<https://twitter.com/corsearch> Linkedin<https://www.linkedin.com/company/2593860/> Trademarks + Brands<http://trademarksandbrands.corsearch.com/> Customer Service/Platform Support: 1 800 SEARCH1Ã¢„Â¢ (1 8000 732 7241)Ã¢€Â¨ Corsearch.USCustomerService(a)corsearch.com<mailto:Corsearch.USCustomerServiice@corsearch.com> Confidentiality Notice: This email and its attachments (if any) contain confidential information of the sender. The information is intended only for the use by the direct addressees of the original sender of this email. If you are not an intended recipient of the original sender (or responsible for delivering the message to such person), you are hereby notified that any review, disclosure, copying, distribution or the taking of any action in reliance of the contents of and attachments to this email is strictly prohibited. If you have received this email in error, please immediately notify the sender at the address shown herein and permanently delete any copies of this email (digital or paper) in your possession. _______________________________________________ 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 _______________________________________________ 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 -- 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. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

1 0

**REMINDER** Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 06 November 2018 at 14:00 UTC
by Julie Bisland Nov. 5, 2018

Nov. 5, 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/qA68BQ Thank you. Kind Regards, Julie

1 0

Re: [Gnso-epdp-team] Further Input from the IPC/BC on Small Team #1 and #2 issues - the way forward
by Hadia Abdelsalam Mokhtar EL miniawi Nov. 5, 2018

Nov. 5, 2018

Hi all, With regard to the distinction between natural and legal persons I would like to start with some factual points 1. The GDPR applies to the processing of personal data of natural persons and not to personal data that concerns legal persons; recital 14 says " This regulation does not cover the processing of personal data which concerns legal persons and in particular undertakings established as legal persons" 2. We are not the ones who decided on this distinction the GDPR did and ICANN is not in the business of making laws 3. The CPs are concerned because · The information of legal persons might as well be personal information of natural persons. (Which might put the CPs at risk) · The registrants might identify themselves incorrectly (Which might put the CPs at risk) · They are not sure about the practicality and implementation of this distinction. To address the concerns of the contracted parties 1. Some registries are already making this distinction like EURid where the registrar agreement defines personal data as follows " “Personal Data” means any information relating to an identified or identifiable natural person. An identifiable person is one who can be identified, directly or indirectly, in particular, by reference or identification number or by one or more factors specific to his or her physical, physiological, mental, economic, cultural or social identity" some other registries have also taken this approach. Looking at all the red-lines and clean versions provided by all groups with regard to the work of small team 1. We all agree in the recommendations section on having the GDD staff commence a research on how currently ccTLDs and CPs make the distinction between the natural and legal persons. I assume that the research will not only tackle the implementation or the technological aspect of this but also the legal aspects and the risks associated 2. Dianne, Thomas and others have suggested to try to get guidance from the DPAs or EC in this regard. I believe that after we get the results of the above, we might be able to reach consensus on the matter. Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Thomas Rickert Sent: Monday, November 05, 2018 1:36 PM To: Diane Plaut Cc: Alex Deacon; Gnso-epdp-team; gnso-epdp-team(a)icann.org Subject: Re: [Gnso-epdp-team] Further Input from the IPC/BC on Small Team #1 and #2 issues Hi Diane, I am still waiting for a response from the EC. Will let all of you know once there is news to report. All the best, Thomas Am 05.11.2018 um 02:02 schrieb Plaut, Diane <Diane.Plaut(a)corsearch.com<mailto:Diane.Plaut@corsearch.com>>: Dear Thomas- Thank you for thoughtful analysis, as usual. I agree that we have to get further input from other DPAs, and I have told you that I very much want to support and be part of that effort (the meeting you offered to set up). This was a starting point to push this effort forward, and I believe a good starting point because the ICO is recognized as a source of moderate guidance. Getting DPA guidance is an important and essential effort that we both know needs to happen to allow the EPDP to come up with practical solutions to the legal application of data protection laws, and specifically the GDPR, to answer the charter questions and advance a working DNS system. Please let me know if you were able to make progress on setting up the meeting in November, as discussed. Sincerely, Diane On Nov 4, 2018, at 2:59 PM, Thomas Rickert <epdp(a)gdpr.ninja<mailto:epdp@gdpr.ninja>> wrote: Hi Diane, all, Thanks for doing research on this and sharing information from the ICO with the group. This has sparked off quiet some discussion, which is good. Reading all the e-mails I cannot help feeling that you are talking past each other, at least to a certain extent. We are trying to answer the question whether a distinction between natural and legal persons should be made. Some say that the distinction should not be made as there are risks when you make the distinction. If a legal person’s name is PII and if a contracted party then publishes that data, it will be in breach of the GDPR and potentially be at the risk of being fined. The ICO on the other hand, says that information from the data subject can be trusted. What that means is that the registrar does not have to do validation. Let’s say I mistype my name - that is nothing the registrar needs to investigate. But that is different from a sole trader who gives his name and tags it legal person. I do not think the ICO would go as far as saying that the data subject’s potentially inaccurate submission of information would include the legal consequences of being put into the bucket of legal entities. In fact, that could mean that the individual would get its data disclosed and not be able to exercise rights under GDPR. This is why I think we should try to get guidance from the DPAs or the EC. If they say the parties involved will not be sanctioned if they rely on the self-identification of a customer, that is fine. Absent such clarification, we need to continue the conversation…. I hope this helps. Best, Thomas Am 03.11.2018 um 02:28 schrieb Plaut, Diane <Diane.Plaut(a)corsearch.com<mailto:Diane.Plaut@corsearch.com>>: Dear EPDP Team- In our efforts to overcome a significant hurdle through our EPDP work – that CPs have expressed they cannot rely on the accuracy of Registrant input and, therefore, are hesitant to distinguish between legal and natural persons or count on country information input by Registrant’s because if it is not accurate, they are concerned they will be liable for identifying the person incorrectly or determining the applicable law incorrectly. We have discussed in the EPDP the prospect of trying to get input from DPAs to confirm that it is reasonable to count on Registrant input. Thomas Rickert has most recently proposed in Barcelona, setting up a meeting with the EDPB and I have expressed my support and desire to partake in this and the legal effort. In the meanwhile, I think it is beneficial for us to try to do our own research and show DPA insight on this topic. To this end, I provide below, guidance from the ICO on this topic. The IPC/BC wishes to add this to the Small Team #1and #2 comments in support of our positions on the issues of supporting the distinction of legal and natural persons and applying relevant country laws. The Accuracy of information provided by data subjects Article 5(1)(d)/(2) GDPR provides that controllers have an obligation to demonstrate compliance with the requirement that: Personal data shall be…accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’). According to the ICO, this means that controllers must take all reasonable steps to ensure that the personal data they hold is not incorrect or misleading as to any matter of fact. However, the GDPR does not explicitly distinguish between personal data provided by the data subject, provided by a third party or created by the controller – the same obligation applies in each such case. As to whether it is possible to rely on the data subject for the accuracy of the information, the ICO has confirmed in its guidance that this is possible. In particular, the ICO states that: “In some cases it is reasonable to rely on the individual to tell you when their personal data has changed, such as when they change address or other contact details. It may be sensible to periodically ask individuals to update their own details, but you do not need to take extreme measures to ensure your records are up to date, unless there is a corresponding privacy risk which justifies this.” However, if the controller learns that information is no longer accurate/up to date (either from the data subject or from other information which comes to light), the controller should update its records accordingly. The ICO also recognizes that it may be impractical to check the accuracy of personal data someone else provides. In such cases, the ICO suggests that controllers must: · accurately record the information provided; · accurately record the source of the information; · take “reasonable steps” in the circumstances to ensure the accuracy of the information; and · carefully consider any challenges to the accuracy of the information. Given that the data subject itself inputs and supplies the data registration information (elements) in issue, there is a strong argument that under the above guidance by the ICO, it is reasonable to reply on the accuracy of this information for purposes of distinguishing between legal and natural persons and for purposes of correct geographical information in relation to applicable law purposes. Moreover, in addition to and to support the above, the IPC and BC further strongly support the following legal recommendation be added to both Small Team #1 and Small Team #2 input that contractual provisions be added to agreements so that overall accuracy standards are achieved, stating: The above-identified Registrant represents and warrants that the data provided herein is true, complete and accurate. It could even go one step further and expressly say that Registrar is entitled to rely on this data in making legal determinations including, without limitation, those related to GDPR and relevant data protection laws. Nothing in the above, limits the application of the ICO guidance from supporting greater accuracy required by all parties. Sincerely, Diane Diane Plaut General Counsel and Privacy Officer <image001.png> Direct +1 646-899-2806<tel:+1%20646-899-2806>  diane.plaut(a)corsearch.com<mailto:diane.plaut@corsearch.com> 220 West 42nd Street, 11th Floor, New York, NY 10036, United States www.corsearch.com<http://www.corsearch.com/> Join Corsearch on Twitter<https://twitter.com/corsearch> Linkedin<https://www.linkedin.com/company/2593860/> Trademarks + Brands<http://trademarksandbrands.corsearch.com/> Customer Service/Platform Support: 1 800 SEARCH1™ (1 800 732 7241<tel:1%20800%20732%207241>) Corsearch.USCustomerService(a)corsearch.com<mailto:Corsearch.USCustomerService@corsearch.com> Confidentiality Notice: This email and its attachments (if any) contain confidential information of the sender. The information is intended only for the use by the direct addressees of the original sender of this email. If you are not an intended recipient of the original sender (or responsible for delivering the message to such person), you are hereby notified that any review, disclosure, copying, distribution or the taking of any action in reliance of the contents of and attachments to this email is strictly prohibited. If you have received this email in error, please immediately notify the sender at the address shown herein and permanently delete any copies of this email (digital or paper) in your possession. _______________________________________________ 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] Proposed approach for reviewing and finalizing the Initial Report - please take note of first deadline for Monday 5 November
by Marika Konings Nov. 5, 2018

Nov. 5, 2018

Dear All, Please note that there was a mix up in the dates / days in the table below, this has now been updated so please use this version as your reference. Also, as requested, please find attached a Word version of the Initial Report. Please do not redline, but use the following form to provide your input https://docs.google.com/document/d/1SoNTnvvadNQ8nX_-OxN4mtsd-gfLNxT54GXSXyG…. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Thursday, November 1, 2018 at 4:23 PM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed approach for reviewing and finalizing the Initial Report - please take note of first deadline for Monday 5 November Dear All, Per our discussion today, please find hereby the proposed approach for reviewing and finalizing the Initial Report. Attached you will find the version of the Initial Report that was presented during the meeting earlier today. Line numbers have been included to facilitate referencing / identifying sections. Please take specific note of the first deadline for Monday 5 November to flag responses to charter questions and/or preliminary recommendations that need to be considered (apart from those that have already been identified). When What By whom Why Monday 5 November Team to flag responses to charter questions and/or preliminary recommendations that need to be considered and why, identifying concerns/issues to be further discussed (as a reminder, all items highlighted in blue will be further considered / reviewed and so need not be raised). This is intended to capture sections requiring additional discussion - specific edits not needed at this point, just a general description of the discussion or re-litigation that is recommended. EPDP Team members To allow leadership team & staff plan meeting schedule and topics to be addressed in upcoming meetings. Tuesday 6 November Put forward list of outstanding issues & call schedule to address outstanding issues Leadership Team / Support Team Plan remaining meetings as well potential additional ones to address issues identified Wednesday 7 November (at the latest) Submit specific substantive comments / edits on the mailing list by: · Identifying the line number and issue of concern · Put forward proposed changes (factoring in the view points of others and discussions held until date – no reopening of previously agreed upon items) · Outline the rationale for proposed change(s) Submit these by using this google doc: https://docs.google.com/document/d/1SoNTnvvadNQ8nX_-OxN4mtsd-gfLNxT54GXSXyG… EPDP Team Groups (SG/C/ACs – not individual comments) Capture and create inventory of specific comments to be reviewed and addressed by the EPDP Team. Thursday 8 November Share list of comments that need further review / discussion. Schedule additional calls as needed to review and discuss substantive comments submitted. Leadership team / Support Team Develop systematic way for reviewing input provided with the objective of finalizing the Initial Report for publication Friday 16 November Publish proposed final version of Initial Report for EPDP Team review. Minor updates (grammatical issues or other) can be flagged off-list to staff for fixing prior to publication. Support Team Allow for ‘final’ review to identify minor issues that should be fixed prior to publication. Monday 19 November Publish Initial Report for public comment Support Team We appreciate that meeting these deadlines will require substantial work from all involved – we hope we can count on your support. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

2 1

Decision on face to face meeting
by Stephanie Perrin Nov. 5, 2018

Nov. 5, 2018

Can we please know the decision on when the face to face meeting will be held? Some of us have other face to face meetings to attend in December, and need to know in order to plan travel. Thanks Stephanie Perrin

1 0

Further Input from the IPC/BC on Small Team #1 and #2 issues
by Plaut, Diane Nov. 5, 2018

Nov. 5, 2018

Dear EPDP Team- In our efforts to overcome a significant hurdle through our EPDP work – that CPs have expressed they cannot rely on the accuracy of Registrant input and, therefore, are hesitant to distinguish between legal and natural persons or count on country information input by Registrant’s because if it is not accurate, they are concerned they will be liable for identifying the person incorrectly or determining the applicable law incorrectly. We have discussed in the EPDP the prospect of trying to get input from DPAs to confirm that it is reasonable to count on Registrant input. Thomas Rickert has most recently proposed in Barcelona, setting up a meeting with the EDPB and I have expressed my support and desire to partake in this and the legal effort. In the meanwhile, I think it is beneficial for us to try to do our own research and show DPA insight on this topic. To this end, I provide below, guidance from the ICO on this topic. The IPC/BC wishes to add this to the Small Team #1and #2 comments in support of our positions on the issues of supporting the distinction of legal and natural persons and applying relevant country laws. The Accuracy of information provided by data subjects Article 5(1)(d)/(2) GDPR provides that controllers have an obligation to demonstrate compliance with the requirement that: Personal data shall be…accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’). According to the ICO, this means that controllers must take all reasonable steps to ensure that the personal data they hold is not incorrect or misleading as to any matter of fact. However, the GDPR does not explicitly distinguish between personal data provided by the data subject, provided by a third party or created by the controller – the same obligation applies in each such case. As to whether it is possible to rely on the data subject for the accuracy of the information, the ICO has confirmed in its guidance that this is possible. In particular, the ICO states that: “In some cases it is reasonable to rely on the individual to tell you when their personal data has changed, such as when they change address or other contact details. It may be sensible to periodically ask individuals to update their own details, but you do not need to take extreme measures to ensure your records are up to date, unless there is a corresponding privacy risk which justifies this.” However, if the controller learns that information is no longer accurate/up to date (either from the data subject or from other information which comes to light), the controller should update its records accordingly. The ICO also recognizes that it may be impractical to check the accuracy of personal data someone else provides. In such cases, the ICO suggests that controllers must: · accurately record the information provided; · accurately record the source of the information; · take “reasonable steps” in the circumstances to ensure the accuracy of the information; and · carefully consider any challenges to the accuracy of the information. Given that the data subject itself inputs and supplies the data registration information (elements) in issue, there is a strong argument that under the above guidance by the ICO, it is reasonable to reply on the accuracy of this information for purposes of distinguishing between legal and natural persons and for purposes of correct geographical information in relation to applicable law purposes. Moreover, in addition to and to support the above, the IPC and BC further strongly support the following legal recommendation be added to both Small Team #1 and Small Team #2 input that contractual provisions be added to agreements so that overall accuracy standards are achieved, stating: The above-identified Registrant represents and warrants that the data provided herein is true, complete and accurate. It could even go one step further and expressly say that Registrar is entitled to rely on this data in making legal determinations including, without limitation, those related to GDPR and relevant data protection laws. Nothing in the above, limits the application of the ICO guidance from supporting greater accuracy required by all parties. Sincerely, Diane Diane Plaut General Counsel and Privacy Officer [cid:image001.png@01D3CA70.18FC1D40] Direct +1 646-899-2806  diane.plaut(a)corsearch.com<mailto:diane.plaut@corsearch.com> 220 West 42nd Street, 11th Floor, New York, NY 10036, United States www.corsearch.com<http://www.corsearch.com/> Join Corsearch on Twitter<https://twitter.com/corsearch> Linkedin<https://www.linkedin.com/company/2593860/> Trademarks + Brands<http://trademarksandbrands.corsearch.com/> Customer Service/Platform Support: 1 800 SEARCH1™ (1 800 732 7241) Corsearch.USCustomerService(a)corsearch.com<mailto:Corsearch.USCustomerService@corsearch.com> Confidentiality Notice: This email and its attachments (if any) contain confidential information of the sender. The information is intended only for the use by the direct addressees of the original sender of this email. If you are not an intended recipient of the original sender (or responsible for delivering the message to such person), you are hereby notified that any review, disclosure, copying, distribution or the taking of any action in reliance of the contents of and attachments to this email is strictly prohibited. If you have received this email in error, please immediately notify the sender at the address shown herein and permanently delete any copies of this email (digital or paper) in your possession.

10 15

Requested Edits to Recommendation 8
by Ayden Férdeline Nov. 4, 2018

Nov. 4, 2018

Dear all, I wish to propose a small modification to the language in Recommendation 8 for clarity. The current text reads as follows: The EPDP Team recommends that redaction must be applied as follows to the data elements that are collected. Data elements not redacted must appear in a freely accessible directory: I request it be modified to read: The EPDP Team recommends that redaction must be applied as follows to the data elements that are collected. Data elements neither redacted nor anonymized must appear in a freely accessible directory: In the table itself, for the field of email, "No" should be revised to "Yes. Anonymized Email Address OR Web Form to be provided." In addition, I request that footnote 7 be revised from: Per the current temp spec requirement: 2.5.1. 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 So to read: The EPDP Team recommends that the 17 May 2018 temp spec requirement 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, continue to be in effect. Thank you. Kind regards, Ayden Férdeline (NCSG)

1 0

Location of the next f2f meeting
by Arasteh Nov. 3, 2018

Nov. 3, 2018

Dear Kurt I understands from the results of Doodle that meeting time after 15 Jan. Received mire vote Pls kindly take into account my obstacle to enter in USA based on inappropriate and unilateral imposition of general ban on the nationals from my country I would have no problem to travel to any other country As you know I will be in ITU PP-18 till 16 November and will be back to Geneva on 17 .11 Pls kindly preserve , respect , defend my legitimate rights Regards Kavouss Sent from my iPhone

1 0

Small Team #1
by Alan Greenberg Nov. 3, 2018

Nov. 3, 2018

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

3 2

Purpose M - UDRP Information
by Margie Milam Nov. 3, 2018

Nov. 3, 2018

Hi- Following up on the action items for this item, please find attached our suggested changes to Purpose M, which include input from the IPC and the BC. We have asked for these additions because it is important to ensure that the complainant is able to fully assess the strength of the claim and the nature of the bad faith of the registrant in order to prove the elements of the dispute resolution process (URS/UDRP). To avoid the filing of ungrounded UDRP complaints, this purpose is fulfilled by making the disclosure before the complaint is filed. Also with regard to the other dispute resolution processes, we note that PDDRPs can be brought based on systemic registrant behavior, and thus there may be instances where this purpose would be relied on to access registrant contact data. Under the PDDRP, the subject matter of the dispute is the gTLD and its use by the operator - including any second-level domain names registered to the registry operator or a related third-party, to the extent the registry operator is complicit in trademark infringement. Similarly RRDRPs are available to complainants to prove a registry is not complying with its registration restrictions, which may require access to registration data, as it relates to the registration restriction. For example, if there is a TLD that is limited to registrants located in a particular geographic region, those elements would need to be accessed for this purpose. There are also registries that have specific RPMs that would fall under this purpose. For example some registries have voluntarily adopted RPMs in their contracts, which would also appear to fall in this Purpose M category (for example, .XXX added a “Rapid Evaluation Service Policy” procedure in their registry agreement to address abusive registrations). Finally, to address Kristina’s concern about potential abuse, there are ways to address this so that it is not grounds for a phishing expedition, such as: * Requiring the trademark holder to represent that they have a good faith intent to file a UDRP or other dispute resolution mechanism or cybersquatting action * Dispute resolution providers should be able to audit requests to ensure that the requester filed a UDRP/URS or legal complaint, or in good faith determined that no grounds existed. Have a great weekend everybody! Margie

1 0

Further IPC Input to Purpose M
by Plaut, Diane Nov. 3, 2018

Nov. 3, 2018

Dear EPDP Team- Attached please find further comments from the IPC on Purpose M. In sum, the proposed change (1), and supporting comments are meant to preserve on the one hand, due process for registrants, and on the other -- related–hand, to permit third party dispute resolution providers to administer claims of abusive registration (see in this respect the comment with references to the UDRP Rules para 4 on “notice”). It is, moreover, worth noting that the ability of providers to undertake their roles keeps contracted parties out of such disputes and flows by contract (RRA and RAA) to registrants in the case of the UDRP. The textual change under MPA-4 from “implement” to “administer” merely reflects more accurately the nature of what dispute resolution providers do (it being for the registrar e.g., to actually “implement” a UDRP transfer decision). Sincerely, Diane Diane Plaut General Counsel and Privacy Officer [cid:image001.png@01D3CA70.18FC1D40] Direct +1 646-899-2806  diane.plaut(a)corsearch.com<mailto:diane.plaut@corsearch.com> 220 West 42nd Street, 11th Floor, New York, NY 10036, United States www.corsearch.com<http://www.corsearch.com/> Join Corsearch on Twitter<https://twitter.com/corsearch> Linkedin<https://www.linkedin.com/company/2593860/> Trademarks + Brands<http://trademarksandbrands.corsearch.com/> Customer Service/Platform Support: 1 800 SEARCH1™ (1 800 732 7241) Corsearch.USCustomerService(a)corsearch.com<mailto:Corsearch.USCustomerService@corsearch.com> Confidentiality Notice: This email and its attachments (if any) contain confidential information of the sender. The information is intended only for the use by the direct addressees of the original sender of this email. If you are not an intended recipient of the original sender (or responsible for delivering the message to such person), you are hereby notified that any review, disclosure, copying, distribution or the taking of any action in reliance of the contents of and attachments to this email is strictly prohibited. If you have received this email in error, please immediately notify the sender at the address shown herein and permanently delete any copies of this email (digital or paper) in your possession.

1 0

BC Comments to Small Team #2
by Margie Milam Nov. 2, 2018

Nov. 2, 2018

Hi Please find attached BC comments to Small Team #2. All the best, Margie

1 0

BC Comments -Small Team #1
by Margie Milam Nov. 2, 2018

Nov. 2, 2018

Hi- As promised, here are the changes requested by the BC on the small team #1. All the best, Margie

1 0

Further Input on Purpose E from IPC
by Plaut, Diane Nov. 2, 2018

Nov. 2, 2018

Dear Kurt, Marika and EPDP Team- Further to yesterday’s call, I wanted to add IPC input and legal opinion in relation to Purpose E. We all very much appreciate the incredible job that Marc A. did and his output is spot on. The language used, clarity of intent and structure of the Purpose is sound. The IPC herein supports the present draft but further wishes to clarify and confirm its Triage support for the BC in addition of 6(1)(b) as a legal basis for Purpose E, particularly in light of Marc and Berry Cobb’s work. Here is the basis for our position: First, in stating the legal analysis it is understood that: In order to rely on Art. 6(1)(b) GDPR (contractual necessity), the processing must be necessary for the performance of A CONTRACT (or to take steps at the request of the data subject before entering into a contract) TO WHICH THE DATA SUBJECT IS PARTY. The GDPR does not therefore specify that the controller must be a party to the contract with the data subject, only that the data subject must be party to a contract which necessitates the processing in question by the controller. As result, there is an argument that ICANN's processing of registrants' personal data is necessary for the performance of the contract between registrants and registrars/registries, notwithstanding that ICANN is not a party to that contract in this context. We believe that there is a basis to show privity of contract here because there are the following contractual obligations flowing from the registrant through the registrars/registries and ICANN in order to provide escrow as per the RAA: 3.6 Data Escrow. During the Term of this Agreement, on a schedule, under the terms, and in the format specified by ICANN, Registrar shall submit an electronic copy of the data described in Subsections 3.4.1.2<http://3.4.1.2> through 3.4.1.5<http://3.4.1.5> to ICANN or, at Registrar's election and at its expense, to a reputable escrow agent mutually approved by Registrar and ICANN, such approval also not to be unreasonably withheld by either party. The data shall be held under an agreement among Registrar, ICANN, and the escrow agent (if any) providing that (1) the data shall be received and held in escrow, with no use other than verification that the deposited data is complete, consistent, and in proper format, until released to ICANN; (2) the data shall be released from escrow upon expiration without renewal or termination of this Agreement; and (3) ICANN's rights under the escrow agreement shall be assigned with any assignment of this Agreement. The escrow shall provide that in the event the escrow is released under this Subsection, ICANN (or its assignee) shall have a non-exclusive, irrevocable, royalty-free license to exercise (only for transitional purposes) or have exercised all rights necessary to provide Registrar Services. Based on the above, together with the recommendations that are proposed in Purpose E to update the escrow agreements to provide for the “appropriate contractual provisions” to make clear the contractual obligations and relationships of the parties and bring the agreements into line with current data protection laws, as well as the need for Data Processing Agreements (which require that each party’s data processing activities and responsibilities are set forth), the contractual nexus between ICANN and the data subject will be made clearer and the support for the [additional] legal basis of 6(1)(b) clarified. As a result, BC/IPC ask that the Initial Report include 6(1)(b) as a basis, simply to provide for the clear obligation of the escrow data to be provided without concern of inconsistent application under 6(1)(f) by individual registrars and registries. It is clear from the great work of Marc and Berry that this is a clear goal of Purpose E, to provide clarity and uniform practice around the obligations in relation to escrow. Diane Diane Plaut General Counsel and Privacy Officer [cid:image001.png@01D3CA70.18FC1D40] Direct +1 646-899-2806  diane.plaut(a)corsearch.com<mailto:diane.plaut@corsearch.com> 220 West 42nd Street, 11th Floor, New York, NY 10036, United States www.corsearch.com<http://www.corsearch.com/> Join Corsearch on Twitter<https://twitter.com/corsearch> Linkedin<https://www.linkedin.com/company/2593860/> Trademarks + Brands<http://trademarksandbrands.corsearch.com/> Customer Service/Platform Support: 1 800 SEARCH1™ (1 800 732 7241) Corsearch.USCustomerService(a)corsearch.com<mailto:Corsearch.USCustomerService@corsearch.com> Confidentiality Notice: This email and its attachments (if any) contain confidential information of the sender. The information is intended only for the use by the direct addressees of the original sender of this email. If you are not an intended recipient of the original sender (or responsible for delivering the message to such person), you are hereby notified that any review, disclosure, copying, distribution or the taking of any action in reliance of the contents of and attachments to this email is strictly prohibited. If you have received this email in error, please immediately notify the sender at the address shown herein and permanently delete any copies of this email (digital or paper) in your possession.

1 0

Re: [Gnso-epdp-team] Reminder - Action items due today, Friday 2 November - RySG - Small Team #1
by Alan Woods Nov. 2, 2018

Nov. 2, 2018

Dear all, Please find attached the responses and edits of the Joint Contracted Parties to Small Team #1 document. Please note that I have attached a red-line and a clean version for ease of review. Kind regards, Alan Woods [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <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.

1 0

Re: [Gnso-epdp-team] Reminder - Action items due today, Friday 2 November - RySG - Small Team #2
by Rosette, Kristina Nov. 2, 2018

Nov. 2, 2018

* 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). Hi, The RySG supports the proposed changes put forth by NCSG and opposes the proposed changes put forth by IPC. Kristina From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Marika Konings Sent: Friday, November 02, 2018 9:55 AM To: gnso-epdp-team(a)icann.org Subject: [Gnso-epdp-team] Reminder - Action items due today, Friday 2 November 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…>.

1 0

Proposed approach for reviewing and finalizing the Initial Report - please take note of first deadline for Monday 5 November
by Marika Konings Nov. 2, 2018

Nov. 2, 2018

Dear All, Per our discussion today, please find hereby the proposed approach for reviewing and finalizing the Initial Report. Attached you will find the version of the Initial Report that was presented during the meeting earlier today. Line numbers have been included to facilitate referencing / identifying sections. Please take specific note of the first deadline for Monday 5 November to flag responses to charter questions and/or preliminary recommendations that need to be considered (apart from those that have already been identified). When What By whom Why Monday 5 November Team to flag responses to charter questions and/or preliminary recommendations that need to be considered and why, identifying concerns/issues to be further discussed (as a reminder, all items highlighted in blue will be further considered / reviewed and so need not be raised). This is intended to capture sections requiring additional discussion - specific edits not needed at this point, just a general description of the discussion or re-litigation that is recommended. EPDP Team members To allow leadership team & staff plan meeting schedule and topics to be addressed in upcoming meetings. Tuesday 6 November Put forward list of outstanding issues & call schedule to address outstanding issues Leadership Team / Support Team Plan remaining meetings as well potential additional ones to address issues identified Wednesday 9 November (at the latest) Submit specific substantive comments / edits on the mailing list by: · Identifying the line number and issue of concern · Put forward proposed changes (factoring in the view points of others and discussions held until date – no reopening of previously agreed upon items) · Outline the rationale for proposed change(s) Submit these by using this google doc: https://docs.google.com/document/d/1SoNTnvvadNQ8nX_-OxN4mtsd-gfLNxT54GXSXyG… EPDP Team Groups (SG/C/ACs – not individual comments) Capture and create inventory of specific comments to be reviewed and addressed by the EPDP Team. Thursday 10 November Share list of comments that need further review / discussion. Schedule additional calls as needed to review and discuss substantive comments submitted. Leadership team / Support Team Develop systematic way for reviewing input provided with the objective of finalizing the Initial Report for publication Friday 16 November Publish proposed final version of Initial Report for EPDP Team review. Minor updates (grammatical issues or other) can be flagged off-list to staff for fixing prior to publication. Support Team Allow for ‘final’ review to identify minor issues that should be fixed prior to publication. Monday 19 November Publish Initial Report for public comment Support Team We appreciate that meeting these deadlines will require substantial work from all involved – we hope we can count on your support. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

2 1

Notes and action items from today's EPDP Team meeting - 1 November 2018
by Caitlin Tubergen Nov. 1, 2018

Nov. 1, 2018

Dear EPDP Team, Please find below the notes and action items from today’s EPDP Team meeting. Best regards, Marika, Berry and Caitlin EPDP Team Meeting #22 Thursday, 1 November 2018 High-level Notes/Action Items Action Item #1: Further to today’s discussion, ICANN Support Staff will update the Purpose A workbook to include a reference regarding transparency of collection to the Registrant/Data Subject for purpose of escrow. ICANN Support Staff will also make notation/reference under E-PA1, which is collection of registration data for the purpose of escrow. Action Item #2: Berry to summarize his issue summary of today’s Purpose E analysis via email to the list. Action Item #3: ICANN Support Staff to draft a recommendation for Purpose E for the EPDP Team’s review regarding noting the jurisdictional impact to gaining registrar/ebero designation. Action Item #4: EPDP Leadership Team to publish a methodology for the EPDP Team to review and comment on the Initial Report in a consistent manner. 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) Reminder to complete F2F Doodle Poll b) Review of outstanding action items c) Other updates, if applicable Please flag any items that need further consideration by the EPDP Team by Friday, 2 November. Please be judicious with any edits to the Initial report, as some of the language is a result of previous debate and compromise from the EPDP Team. Should the Team consider supplemental comment periods? In following the GNSO Guidelines for EPDPs, there is no requirement for a supplemental public comment period. The draft timeline covers required steps; however, the Team may consider if additional public comment periods are necessary or desired after reviewing the public comments. Re: optional provision of recommendations to GAC, this should be required, and the EPDP Team should ask for GAC comments before Board consideration. Response: optional only references public forum discussion as optional. The report will be provided to the GAC for review. 3. Purpose E Data Elements Workbooks (Escrow) Objective of discussion: 1. Confirm Collection Processing Activity 2. Confirm data elements 3. Review Purpose E Data Elements Workbook (see https://community.icann.org/display/EOTSFGRD/e.+Data+Elements+Workbooks?pre… and https://community.icann.org/display/EOTSFGRD/e.+Data+Elements+Workbooks?pre…) a) Confirm content of purpose E Data Elements Workbook b) Confirm next steps, if any EPDP Team Discussion: Background: During the LA F2F, the small team only focused on registrar escrow. In Barcelona, Marc A. provided feedback for registry escrow, and Berry incorporated the edits into the new Purpose E template. Ultimate objective: Rys/Rrs processing of registration data for escrow is compliant with GDPR. Appendix B in the Temp Spec deals specifically with escrow. There does not seem to be any disagreement in the Team that escrow is not a legitimate purpose; however, the escrow agreements should be refreshed to take into account GDPR. The data elements workbook includes a recommendation for ICANN, escrow agents and contracted parties to enter into data processing agreements. The Registry Purpose E was modeled after the registrar purpose E. There is a departure from the other workbooks in page 2 for the lawfulness of processing. For processing activity 1, registry data escrow is a downstream processing activity, and no data elements are collected for the purpose of escrow, so the processing activity of collection is likely taking place under a different purpose, e.g., purpose A or C. Question for the Team: for EBERO, are there data elements needed that are not currently identified within Purpose E? For collection under escrow, there should be an acknowledgement of collection for this purpose, so the purpose does not need to change later. Note: Staff can make a reference back to Purpose A (reflecting registrant rights) regarding transparency to the Registrant/Data Subject. And we can make notation/reference here under E-PA1. Action: Berry to summarize Purpose E analysis via email to the list. A jurisdiction for a registrar in the event of a failing registrar could present issues, i.e., if terminating registrar is in Europe, and the gaining registrar is in North America, this may cause an issue. Action: support staff to draft recommendation for EPDP Team's review re: jurisdictional impact for registrar/ebero transition. EPDP Team to review the graphics in the workbooks to confirm this is an accurate representation. The lawful basis for escrow should be 6(1)(b) - could this be added to the workbook? A note will be added to the Initial Report that some members of the EPDP Team believe processing under Purpose E is lawful under 6(1)(b). Contracted parties are comfortable processing data for the purposes of escrow under 6(1)(f). If the team is focusing on baseline activities, 6(1)(f) probably makes the most sense. Does this workbook refer to collection by registrar or receiving the data by the registry? Answer: this processing refers to collection from the registrar. The intent is that the collection occurs at the registrar from the registrant, and subsequently is transferred from the registrar to the registry. 4. Draft Initial Report a) Overview of Initial Report template b) Open issues and explanation of highlighted items c) Approach for EPDP Team edits to Initial Report The draft initial report can be downloaded here: https://community.icann.org/display/EOTSFGRD/2018-11-01+EPDP+Team+call+%2322. Chapter 3 of the Initial Report was circulated to the group following the LA meeting; however, this has been updated since the Team last saw it to reflect discussion through ICANN63. Chapter 2 contains requirements to educate the reader on how the Team deliberated on the contents of Chapter 3, i.e., overview of the team’s methodology - discussion summary indexes, data elements workbooks, F2F meetings, small teams, etc. Chapter 3 aims to capture all of the deliberation on the charter questions up through ICANN63. There is highlighting and color-coding to emphasize outstanding issues. Items highlighted in yellow are flags for staff to populate supporting documentation (such as completed data elements workbooks, once reviewed by the EPDP Team). Items highlighted in blue reflect documents still under discussion, e.g., Small Team 1 and 2 language that is not yet finalized. Blue highlights also denote areas where ICANN Support Staff has suggested language for the Team to review. Staff-suggested language appears in brackets. Items highlighted in red have not been discussed in detail, and it would be helpful if EPDP Team members volunteer to provide draft responses to red items. Annex B includes the EPDP Membership and attendance records. Annex C captures the community input the Team received as a result of early input. For each section, there will be questions the team will ask the community for input on in an effort to get targeted feedback. While it is not complete, it will be helpful for the Team to review and focus on the highlighted items as it reviews the draft initial report. >From a staff support perspective, the initial homework would be for the Team to mark items in blue, i.e., what items that are not currently flagged should be flagged for further review/discussion? Any clarifications or minor copy edits can be sent to support staff off-list; however, there please be mindful of the delicate balance b/w clarifying language and changing the substance of the recommendation. Leadership Team will brainstorm how to best organize and allow for EPDP Team feedback to the initial report. 5. Wrap and confirm next meeting to be scheduled for Tuesday, 6 November at 1400 UTC. a) Confirm action items b) Confirm questions for ICANN Org, if any

2 3

Fwd: IPC Comments and redlined documents
by Alex Deacon Nov. 1, 2018

Nov. 1, 2018

Hi Diane. I just realized this email you sent on Friday went to the wrong address so didn't make it to the full epdp list. Can you resend it to gnso-epdp-team(a)icann.org (an not gnso-epdp-team-bounces(a)icann.org) ? Thanks. Alex ---------- Forwarded message --------- From: Plaut, Diane <Diane.Plaut(a)corsearch.com> Date: Tue, Oct 30, 2018 at 5:57 PM Subject: IPC Comments and redlined documents To: Marika Konings <marika.konings(a)icann.org>, Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org> Cc: Alex Deacon <alex(a)colevalleyconsulting.com>, Brian King < brian.king(a)markmonitor.com> Hi Marika- Attached please find the IPC’s input on the action items due yesterday. We apologize for the delay, we have all been working very hard on this output post the ICANN meeting and needed to circulate and get input from our constituents. *Action Item #2 -- Small Team #1 Legal vs. Natural * It is the IPC's position that it is important and feasible for contracted parties to differentiate between legal and natural persons. We believe that this distinction is supported and encouraged by the construct of the GDPR and that is valuable for all parties in the practical application of the law as it relates to WHOIS and the DNS framework and ecosystem. The IPC submits the attached redline with further output and clarification for consideration by the team. *Action Item #3 - Small Team #2 Geographic Distinction* See attached redline for consideration. *Action Item #5 - Processing Activities and Responsible Parties* The IPC requests additional time to review this document. Any comments we may have will be included in our comments to the Purpose Workbooks due November 5th. Sincerely, Diane, Alex and Brian *Diane Plaut* General Counsel and Privacy Officer [image: cid:image001.png@01D3CA70.18FC1D40] Direct +1 646-899-2806 diane.plaut(a)corsearch.com 220 West 42nd Street, 11th Floor, New York, NY 10036, United States www.corsearch.com Join Corsearch on Twitter <https://twitter.com/corsearch> Linkedin <https://www.linkedin.com/company/2593860/> Trademarks + Brands <http://trademarksandbrands.corsearch.com/> Customer Service/Platform Support: 1 800 SEARCH1™ (1 800 732 7241) Corsearch.USCustomerService(a)corsearch.com *Confidentiality Notice:* This email and its attachments (if any) contain confidential information of the sender. The information is intended only for the use by the direct addressees of the original sender of this email. If you are not an intended recipient of the original sender (or responsible for delivering the message to such person), you are hereby notified that any review, disclosure, copying, distribution or the taking of any action in reliance of the contents of and attachments to this email is strictly prohibited. If you have received this email in error, please immediately notify the sender at the address shown herein and permanently delete any copies of this email (digital or paper) in your possession. -- ___________ *Alex Deacon* Cole Valley Consulting alex(a)colevalleyconsulting.com +1.415.488.6009

2 1

Recordings, Attendance & AC chat / GNSO Temp Spec gTLD RD EPDP / Thursday, 01 November 2018
by Julie Bisland Nov. 1, 2018

Nov. 1, 2018

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 Thursday, 01 November 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/pg68BQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-01nov18… AC Recording: https://participate.icann.org/p9nqid6q6w4/<https://participate.icann.org/p9nqid6q6w4/?OWASP_CSRFTOKEN=847b74aafca1ee2e…> ** 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, Julie Bisland

1 0

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 06 November 2018 at 14:00 UTC
by Julie Bisland Nov. 1, 2018

Nov. 1, 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/qA68BQ Thank you. Kind Regards, Julie

1 0

Re: [Gnso-epdp-team] Please review - action items and outstanding items
by Marika Konings Nov. 1, 2018

Nov. 1, 2018

Dear All, Please note an updated link for action item #3 as on the original link the redlines were not visible. Do also note that this version now includes the additional changes that Kristina referred to during the meeting. See https://drive.google.com/a/icann.org/file/d/1tamJeyaq4nC8HHQelSeln_BB8fnVlz…. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Thursday, October 25, 2018 at 1:29 PM To: EPDP <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Please review - action items and outstanding items Dear EPDP Team, Following this week’s EPDP Team meetings, please find below and attached the outstanding action items and related deadlines, outstanding charter questions (not yet discussed) and punch list of items in relation to the data elements workbooks. Please take note that Staff’s provision of an updated and comprehensive data matrix and updated Initial Report draft is dependent on timely delivery of input on the below items. If you believe anything is missing from the list below, please let us know. Thank you for all your support - safe travels home! Caitlin, Berry and Marika =================== EPDP Team Action items ICANN63 Action item #1 – CPH to confirm whether or not purpose A strikethrough language can be removed by Thursday 25 October. (COMPLETED – deletion of strikethrough language confirmed) Action item #2 - 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 by Monday 29 October. (see https://docs.google.com/document/d/1U6POLQhFNGu1Bo1k0rCluiaVZ27-OKIPpU8K8N1…) Action item #3 - 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 by Monday 29 October. (see https://drive.google.com/a/icann.org/file/d/1tamJeyaq4nC8HHQelSeln_BB8fnVlz…) Action item #4 – 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 by Friday 2 November. (see https://community.icann.org/x/5AC8BQ) Action item #5 – Each group (SG/C/AC) to review the responsible parties overview for all purposes and identify which designations need to be further considered by Monday 29 October. (see https://docs.google.com/document/d/1-rdfchOwpANFVKOtnM_9bPp-zT4JAvTN8dJqebd…) Note: Staff’s provision of an updated and comprehensive data matrix and updated Initial Report draft is dependent on timely delivery of the above feedback. Outstanding Charter Questions (not discussed yet or addressed through ongoing work) q) Sun-setting WHOIS Contractual Requirements q1) After migration to RDAP, when can requirements in the Contracts to use WHOIS protocol be eliminated? q2) If EPDP Team’s decision includes a replacement directory access protocol, such as RDAP, when can requirements in the Contracts to use WHOIS protocol be eliminated? b) Collection of registration data by registrar: b3) How shall legitimacy of collecting data be defined (at least for personal data collected from European registrants and others in jurisdictions with data protection law)? k) ICANN's responsibilities in processing data k2) In addition to any specific duties ICANN may have as data controller, what other obligations should be noted by this EPDP Team, including any duties to registrants that are unique and specific to ICANN’s role as the administrator of policies and contracts governing gTLD domain names? l) Registrar's responsibilities in processing data l4) What are the registrar's responsibilities to the data subject with respect to data processing activities that are under ICANN’s control? m) Registry's responsibilities in processing data m4) What are the registry's responsibilities to the data subject based on the above? Outstanding items in data elements workbooks Purpose B Punch List: * Confirm staff-suggested responses for Purpose Rationale questions * Confirm data elements (note: Purpose B data elements are dependent on the completion of all other workbooks, as Purpose B only references data already collected) Purpose C Punch List: * Confirm staff-suggested response for Purpose Rationale questions * Confirm staff-suggested note re: definition of optional (footnote 2 in workbook) * Confirm data elements Purpose E (Registrar Data Escrow) Punch List: * Confirm Collection Processing Activity (Purpose does not necessarily require collection) * Confirm data elements Purpose F Punch List: * Confirm staff-suggested response for Purpose Rationale questions * Confirm data elements Purpose M Punch List: * Determine inclusion/exclusion of RDDRP, PDDRP, and PICDRP RPMs within the purpose statement (adjust PAs if excluded) * Confirm staff-suggested responses for Purpose Rationale questions * Confirm Processing Activities structure, especially Disclosure and Retention * Confirm Data Elements Purpose N Punch List: * Determine if Purpose Statement is an ICANN Purpose (note Collection PA indicates ICANN as a Joint Controller) * Confirm Processing Activities structure, especially Disclosure and Retention * Confirm Data Element (Other Data) Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

3 2