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

Notes from Small Group #2 - geographic basis
by Caitlin Tubergen Oct. 9, 2018

Oct. 9, 2018

Dear All, For your information, please find below the notes and action items of small team #2, which met last week to discuss: h) Applicability of Data Processing Requirements h1) Should Registry Operators and Registrars (“Contracted Parties”) be permitted or required to differentiate between registrants on a geographic basis? h2) Is there a legal basis for Contracted Parties to differentiate between registrants on a geographic basis? Best regards, Marika, Berry and Caitlin Small Group 2 High-level agreements (Geographic Basis) Charter question h1) Should Registry Operators and Registrars (“Contracted Parties”) be permitted or required to differentiate between registrants on a geographic basis? 1. The group seems to agree that contracted parties should be permitted to differentiate on a geographic basis, but there is not agreement whether differentiation should be required or explored. 2. The members who believe geographical differentiation should NOT be required identified several concerns. Specifically, those not in support noted: the actual location of the registrant is not alone dispositive of whether GDPR applies especially because of the widespread industry use of additional processors (e.g., backend registry service providers and resellers for registry operators and registrars, respectively). data subjects need to be informed at the time of collection about how their personal data is being processed, i.e. what data is collected, to whom it is transferred, how long it is stored etc. Also, information on the data subject’s rights needs to be provided, such as the right of access, right to rectification, right to erasure and the right to data portability. Not having a common approach for all registered name holders would give some RNHs these rights, while others would not get such rights. That would potentially lead to two classes of RNHs, which should be avoided. ICANN is about “one world - one Internet”, i.e., global standards and interoperability. Such interoperability would be lost and fragmentation in the marketplace would occur if there were no requirement for taking a single approach at the global level. there are significant liability implications for Contracted Parties if they are incorrect any consensus policy needs to be commercially reasonable and implementable, and in the current market place, differentiation based on geographic location will be difficult to scale ICANN policies should not create competitive advantages for some contracted parties over others - such as a policy may result in certain ICANN accredited Registrars and/or gTLD Registry Operators to seem less appealing to customers (RNHs) due to their establishment in jurisdictions with less stringent privacy protection 3. The members who believe geographical differentiation SHOULD be required; however, they identified several concerns. Specifically, those in support of required differentiation noted: When GDPR was adopted, the global nature of the DNS was not taken into account. It therefore may be shortsighted of the EPDP Team to just focus on GDPR. Applying GDPR to all registrants would undermine the role of sovereign states to be able to enforce their own laws and regulations. Businesses are always required to take into account local laws when choosing to do business with various countries; therefore, cost is not necessarily a persuasive argument to not require differentiation. The Expert Working Group developed a rules engine; perhaps the group can recommend future exploration of the EWG rules engine to see if it is feasible. 4. Some expressed that one option for future exploration could be to consider the EWG rules engine to see if this is a feasible differentiation mechanism or if a differentiation mechanism could be developed in the future. For background, the EWG Report reflected the consensus position of experts convened by the ICANN Board of Directors in 2012 to propose a new policy for WHOIS that complied with applicable privacy regulations, including GDPR. The EWG Report states: The RDS could provide for a legal compartmentalization. Specifically, data elements could be tagged according to the applicable law for the data subject (i.e., the Registrant) and treated accordingly. To achieve this legal compartmentalization, the RDS could implement a “rules engine” that would apply the applicable data protection laws to each specific transfer. More specifically, “rules engine” refers to a feature that could be implemented within the RDS to manage (a) the storage, collection and processing of domain name information based on Registrant, Contact, Registrar, Registry, and RDS jurisdictions (represented by the following data elements: Registrant and Contact Country Code, Registrar and Registry Jurisdictions), and (b) data protection laws of the applicable jurisdictions, in accordance with ICANN's future defined policy for the RDS. The EWG then made the following recommendation: 107. An information system to apply data protection laws (i.e., a “rules engine”) and localization of RDS data storage must be considered as two means of implementing the high level of data protection required. This must be ensured through standard contractual clauses, which flow from a logical privacy policy for the RDS ecosystem. Charter question h2) Is there a legal basis for Contracted Parties to differentiate b/w registrants on a geographic basis? Yes, there is a legal basis for contracted parties to differentiate b/w registrants on a geographic basis. However, the location of the registrant alone is not a dispositive indicator if the GDPR applies. If the controller or any processor is within the EU, the GDPR will also apply. 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. h) Applicability of Data Processing Requirements h1) Should Registry Operators and Registrars (“Contracted Parties”) be permitted or required to differentiate between registrants on a geographic basis? · The group needs to define the data subject. There are five possible options: o 1. Anyone who is physically located within the borders of the EU, so his data is being processed while he resides in the EU - that would include tourists or people on business trips (and this could extend to months) o 2. A resident of the EU (that is a non EU citizen who has residency in an EU country) and is within the EU borders o 3. An EU citizen who is within the EU borders o 4. An EU citizen or resident who is physically located anywhere and whose data is being processed o 5. A data subject who is located anywhere and his data is being processed in the EU · The group should work on a policy with the type of data covered by GDPR and the types of data that are not. · The group needs to distinguish two layers: (1) what is compliant with GDPR; (2) the policy. Regarding compliance, it's not just entities/persons in the EU, we must also discuss controllers/processors. The policy question to ask: do we want fragmentation in the marketplace - do we want operators to distinguish b/w those who fall under GDPR and who don't? ICANN is about avoiding fragmentation and interoperability of the marketplace. Accordingly, it may be preferred to registries/registrars to treat all customers the same. · From a policy perspective, this is not the first time that privacy and data protection laws has come up at ICANN. We need to be compliant with GDPR, but the policy should not be restricted to GDPR as privacy laws will change over time. It would be more straightforward across the board if the policy didn't only apply to the EU. Contracted parties should not have to differentiate on a geographic basis. · The group needs to focus on where the processing activities are occurring - does the controlling/processing activities occur in the EU? Q: How does the group feel about the proposal that registry/registrar should apply the same standards across the board for data processing? · Registry operators should not be required to differentiate b/w registrars on a geographic basis for the following reasons: o the actual location of the registrant is not alone dispositive of whether GDPR applies o significant liability implications of being wrong o importantly for registries, practical implementation consideration. The RySG believes that any consensus policy needs to be commercially reasonable and implementable. There could be a situation where a Ry (the controller) is not in the EU, the RNH is not in the EU, but the backend provider is. There is also a large reseller market in the registrar space. There are some scaling issues in thinking of all of the various scenarios. · From a policy point of view, it would be better to have a non-fragmented internet. From a practical and implementation point of view, this may not be an easy thing to do. · There was a consensus recommendation that came out of the EWG - they came up with the rules engine, which was the approach to apply the applicable policy for privacy laws. When GDPR was adopted, the DNS was not taken into account. It is shortsighted of us to just focus on GDPR. · The contracted parties may be permitted to differentiate b/w registrants on a geographic basis - the policy should not be applied in a universal manner. The group needs to also take into account data protection laws worldwide. · The group is trying to cope with policy vs. practical implementation issues. Being mindful of the Team's scope, which is to try to make the Temp Spec permanent and not a blue-sky redesign. Is specific geographic implementation possible? o 1. Many countries are busy implementing their own privacy laws, partly b/c they want to set themselves up as a trading partner with the EU. o 2. The GDPR covers EU citizens data. o 3. The group is stuck with the ICANN model. There is a clear legal obligation for the publishing and processing of data. Any outcome of the discussion needs to be commercially reasonable. The only feasible and commercially reasonable position we can use at the moment is to implement the Temp Spec globally, but there may well be PDPs aimed at recognizing resellers that could help in identifying properly European individuals in the system. · ICANN has done a lot over the years to strengthen registrant rights. It is hard to explain to some registrants that they do not have the same rights as other registrants. Registrars needs to inform registrants about what data is used and for what - does this group want registrars to have to differentiate by registrant - this could lead to confusion and fragmentation. · There is also an issue of sovereignty. To apply EU rules to non-EU entities is not a good result. · We all, as companies, have to comply with the laws that apply to us. Just because it is costly is not a persuasive argument. · Cost of implementation should be a consideration and is a persuasive point. The cost for law enforcement and IP to access redacted data is also significant. The issue here is shifting the cost from one entity to another. · The Team should look at the matter from a policy point view saying that I would rather not see a fragmented Internet and all registrants to have the same level of protection everywhere · From a practical and implementation point of view, it will be very difficult to differentiate between registrants based on location; however, it is up to the registries and registrars to speak to this. · The future of the Internet and evolving technologies promises the need for global policies. In addition, and the Team must take into consideration the impact of its decisions on the business and industry. Recap: 1. The group would agree that contracted parties should be permitted to differentiate, but there is not agreement whether differentiation should be required. 2. The group thinks more work can be done regarding implementation of differentiation, e.g., associated costs, practicalities, etc. · Based on interventions by group members (Thomas, Hadia, Emily, Amr) there are group members that contracted parties should not be required to differentiate based on geographic basis - this may be rough consensus. · The small team should not use the term consensus as that term has a specific meaning in the GNSO. · We've addressed the legal basis in Charter Question h2. · For h1, it would be best to summarize the key issues identified. · Could part of the recommendation be to explore the EWG's rule engine?

1 0

Notes and action items EPDP Team meeting #18
by Marika Konings Oct. 9, 2018

Oct. 9, 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 #18 Tuesday, 9 October 2018 Notes and Action Items High-level Notes/Actions: Action item #1: Volunteers needed to specify what types of 'rights' are included in purpose A and what does that mean for data elements that need to be transferred to registries. Volunteers that came forward during the call: Kristina Rosette, Emily Taylor, Milton Mueller, Mark Svancarek, Chris Lewis-Evans. Action item #2: Staff to circulate data elements workbook overview of outstanding issues and leads (see attached) Action item #3: Staff to reach out to possible leads for those purposes for which there was no lead confirmed during the call. Action item #4: Leads to publish latest version of respective data elements workbook to EPDP Team mailing list by Monday 15 October at the latest. Questions for ICANN Org from the EPDP Team: None 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) Additional travel support for ICANN63 * The Team members receiving travel support are: Thomas Rickert, Alan Woods, Milton M., Amr E., and Kavouss A. b) Request for independent legal counsel to assist the EPDP * The Leadership Team is requesting more detail including details re: statement of work. * There will be call to discuss this further Wednesday, 10 October at 22:00UTC. * Please note there are budget limitations to the request as well as approval process via the PCST. More details provided tomorrow. c) Lawful basis memo – any other input that should be recorded in the latest version? * Members should read through the updated memo that was circulated to the mailing list yesterday and note where they would like their SG/C/AC added to denote disagreement with the lawful basis identified. d) ICANN63 High Interest Topic Session Planning * The Leadership Team will pass along the draft agenda for the HIT shortly. All groups encouraged to nominate a member to present on the panel. * Presenters are representing the EPDP Team as a whole, not their respective group. e) Review of outstanding action items * Registrars and Registries have outstanding action items that are needed in advance of Thursday's meeting, specifically - Purpose B Workbook. * See https://community.icann.org/x/NwSNBQ for other outstanding items f) Other updates, if applicable 3. Review outstanding questions in relation to charter question c) Transfer of data from Registrar to Registry (blue signifies has not been discussed yet): c1) What data should registrars be required to transfer to the registry? c2) What data is required to fulfill the purpose of a registry registering and resolving a domain name? c3) What data is transferred to the registry because it is necessary to deliver the service of fulfilling a domain registration versus other legitimate purposes as outlined in part (a) above? c4) Is there a legal reason why registrars should not be required to transfer data to the registries, in accordance with previous consensus policy on this point? c5) Should registries have the option to require contact data or not? c6) Is there a valid purpose for the registrant contact data to be transferred to the registry, or should it continue to reside at the registrar? (note: the two items in cursive are the primary focus of today’s discussion, but the others are related and should be used to provide context to the transfer topic as necessary) Objective of discussion: (1) Review outstanding charter questions and review data elements workbook for purpose A with focus on what data elements need to be transferred from registrar to registry (2) Agree on data elements needed to be transferred as well as responses to outstanding charter questions a. Review data elements workbook for Purpose A b. Deliberate on outstanding questions c. Agree on proposed response to charter questions * See documentation circulated by Berry to the mailing list * Issue of transfer and what data needs to get transferred - build this up from the ground up and group's work to data, instead of focusing immediately on existing practices and requirements. * Some issues may come up that are not directly related to transfers. * Purpose A, M and N have all listed processing activities around the transfer of data. * See also latest version of lawful basis memo - tool by which the EPDP Team can identify the lawful basis for each of the processing activities for each purpose. See additional processing activities identified for purpose A. Need to undertake inventory for each processing activity with regards to data elements needed / used. * See data elements matrix - focused on what data elements need to be collected. Second version could be a summary matrix of data elements that are transferred, and possibly a third one further down the line that would focus on data elements for access. * Collect or not column - one data element marked as required for collection will show up here in green, optional elements are yellow, any data element not identified is red. Starter draft of where we are at today - will need to be updated as data elements workbooks get updated. * See Purpose A data elements workbook - redline version. See new section re. lawfulness of processing test. See also new column "fields to be transferred". * Is lawful basis distinction for transfer of data necessary or not? If yes, need to consider data elements for each lawful basis. * Should a small group be tasked to come up with the list of fields to be transferred? * What needs to be transferred from registrar to registry to ensure a working domain name registration? * What is difference between transfer and disclosure? May be helpful to define these so that difference is clear. Talking here about transfer in the context of establishing the rights of the RNH - what data must be transferred in order to ensure this. Not the traditional use of disclosure, but what data is necessary to make the domain name registration operational and properly allocated. * In a data ecosystem, it is necessary to map the various processors. The registry is a processor, and disclosure to them is necessary, in order for the primary purpose of data collection, namely to make the name resolve properly and function. Is it required to register or administer a domain name or to protect the DNS? If so, then possibly. * Is purpose A about allocation of a string to a registrant? If so, what data is needed? Is this broader than just allocating the string? May be taking a too narrow view if focus is solely on allocation of string. Need to be in agreement on what the purpose means to be able to fill out this worksheet. Maybe start with allocation of string as a starting point? Other aspects may already be covered as part of other purposes? * As soon as data gets transferred from registrar to registry, liability comes into play as well as jurisdictional issues. * May need to consider rationale of Thick WHOIS PDP WG, but need to appreciate that this work was undertaken several years ago (pre-GDPR). * Make this registrant centric - it is not about what the registry may want. If this is not the place for registrant rights, it would need to be incorporated somewhere else. * Purpose is specific that it relates to the rights in a registered name, not about the whole eco-system. * Agreement that this is registrant centric, that it relates to the registrant to exercise its rights, disagreement to how far these rights extend into the eco-system. * Let's stick for now on narrowly focused purpose of rights of the RNH in a registered name. If we're looking at the minimum data required to make a domain name actually work, it would only be domain name and nameservers, no personal data is required to be transferred. Going beyond that, you may need to rely on different aspects of the GDPR. Are there any other data elements that are needed, for example updated, created and expiration data? Registries to opine on this. These data elements are not created by or collected from registrar or registrant but these are artefacts of registering or updating a string, created at the registry level. * ICANN has developed a registrant rights document - maybe that could serve as a starting point to fully understand registrant rights in the context of a domain name registration? * Need to look at each right to identify what data elements are needed? For example, to be able to attach a domain name registration, you need to identify the registrant, but you would need to ask who needs to identify the registrant and for which purpose? It may only be the registrar who needs to do this, not the others in the chain (ICANN, registries). * Activation in the DNS and allocation to the registrant are two must fundamental activities. In order to activate in the DNS, you need the name servers. Name servers is currently an optional data element but required to be supported. If a registrant only wants to register a domain name but not have it resolve, it does not need to indicate name servers. * May need to clarify the language around registrant rights? Consider using registrant benefits and responsibilities? Action item #1: Volunteers needed to specify what types of 'rights' are included in purpose A and what does that mean for data elements that need to be transferred to registries. Volunteers that came forward during the call: Kristina Rosette, Emily Taylor, Milton Mueller, Mark Svancarek, Chris Lewis-Evans. 4. Update on status of remaining data elements workbooks & open items Objective of discussion: (1) Confirm status of data elements workbooks (2) Identify volunteers to address any open items a. Review status of remaining data elements workbooks & open items b. Identify volunteers to address any open items & confirm timeline * Staff pulled together this list that aims to provide an overview of the different data elements workbooks and outstanding issues / questions. Objective is to identify a lead for each data elements workbook who would take ‘ownership’ of the data elements workbook with the objective to get it into a near final state by next Monday 15 October to allow for review by the EPDP Team prior to commencing travel to ICANN63. This near final state should include any updates as a result of recent EPDP Team deliberations and/or input that has been received from ICANN Org, as well as identifying any outstanding items that require further EPDP Team consideration. * The data elements workbooks are an essential element for the Initial Report as such it is of key importance that these are carefully reviewed, and any outstanding items are identified so that these can be discussed and resolved either prior or during ICANN63. Action item #2: Staff to circulate data elements workbook overview of outstanding issues and leads (see attached) Action item #3: Staff to reach out to possible leads for those purposes for which there was no lead confirmed during the call. Action item #4: Leads to publish latest version of respective data elements workbook to EPDP Team mailing list by Monday 15 October at the latest. 5. Wrap and confirm next meeting to be scheduled for Thursday 11 October at 13.00 UTC. a. Confirm action items b. 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…>.

1 0

Recordings, Attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP held Tuesday, 09 October 2018
by Andrea Glandon Oct. 9, 2018

Oct. 9, 2018

Dear all, Please find the attendance and AC chat attached to this email. The MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Tuesday, 09 October 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/KwWrBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-09oct18… <https://urldefense.proofpoint.com/v2/url?u=https-3A__audio.icann.org_gnso_g…> AC Recording: https://participate.icann.org/p5acnjfn3n7/<https://participate.icann.org/p5acnjfn3n7/?OWASP_CSRFTOKEN=f6d5901d864c668f…> ** 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

Meeting Invitation / Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 11 October 2018 at 13:00 UTC
by Andrea Glandon Oct. 9, 2018

Oct. 9, 2018

Dear all, Non-members can follow the EPDP call taking place on Tuesday’s and Thursday’s at 13: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/LQWrBQ Thank you. Kind Regards, Andrea Glandon

1 0

***REMINDER*** Meeting Invitation / Alternates & Observers / GNSO Temp Spec gTLD RD EPDP Small Team #3 call/ Wednesday, 10 October 2018 at 13:00 UTC
by Julie Bisland Oct. 9, 2018

Oct. 9, 2018

Dear all, Non-members can follow the EPDP Small Team Meeting #3 Wednesday, 10 October 2018 at 13: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/8AO8BQ Thank you. Kind Regards, Andrea Glandon

1 0

Re: [Gnso-epdp-team] Fwd: Responses to EPDP Questions
by Alan Greenberg Oct. 9, 2018

Oct. 9, 2018

Farzaneh, I find this comparison offensive. Any access to personal information of domain name registrants will need to be compliant with data protection laws. You may not agree with others on where the balance point is, but presuming that any collection or access (which will implicitly be limited to those with specific needs) will be unlawful is incorrect. Alan At 09/10/2018 03:05 AM, farzaneh badii wrote: >Only some groups' priority is to have access to personal information >of domain name registrants. Other groups priorities are: protecting >registrants personal information and compliance with data protection laws!

2 1

Fwd: Responses to EPDP Questions
by Marika Konings Oct. 9, 2018

Oct. 9, 2018

Dear All, Please find below additional responses from ICANN Org to a number of outstanding questions. We’ll get these posted shortly on the related wiki page. Best regards, Caitlin, Berry and Marika ————————————— The EPDP Team previously requested a summary of ICANN org’s contacts and engagements with the EPDP and DPAs. ICANN org provided a response, which is provided again below for reference: QUESTION: Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data? RESPONSE: ICANN org has been open and transparent with our engagements with the EDPB and DPAs. All of the formal written communications from EDPB and DPAs are published on ICANN correspondence. In addition, we’ve had informal verbal conversations with the EDPB and DPAs to educate, inform, and ask for guidance. Summaries of those informal conversations are published in blogs. To assist the EPDP Team in its work, ICANN org will provide the EPDP Team with a compiled list of correspondence received and blogs published thus far, including the topic of each correspondence/blog. As follow-up to the above response, attached is a summary of correspondence between ICANN org and the EPDP/DPAs, as well as announcements and blogs relating to ICANN org’s GDPR-related efforts. The document is marked as draft so that the EPDP Team can review and provide suggestions for re-organization or re-structuring of the content to best meet the EPDP Team’s needs. QUESTION: For which ICANN policies is admin/tech contact information currently a required data element and/or referenced in the policy? RESPONSE: Administrative and technical contact information is referenced in the following ICANN policies and procedures: * Registry Registration Data Directory Services Consistent Labeling and Display Policy<https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en>. Output requirements for administrative and technical contact information. * Thick WHOIS Transition Policy for .COM, .NET, .JOBS<https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02…>. Guidance to registry operators for handling output of administrative and technical contact information where no data exists in the SRS during the period when registrars begin sending Thick WHOIS data to registry operators for all new registrations. * Rules for Uniform Domain Name Dispute Resolution Policy<https://www.icann.org/resources/pages/udrp-rules-2015-03-11-en>. Notifications of complaints include administrative and technical contacts information. * WHOIS Data Reminder Policy<https://www.icann.org/en/resources/registrars/consensus-policies/wdrp>. WDRP notices may be presented to the registrant either directly or through the administrative contact. * Transfer Policy<https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en>. Administrative contact along with the registered name holder have the authority to approve or deny a transfer request. Because of this role, the administrative contact is referenced in parts of the transfer process as well as in the Registrar Transfer Dispute Resolution Policy. * Uniform Rapid Suspension System (URS) Rules<http://newgtlds.icann.org/en/applicants/urs/rules-28jun13-en.pdf>. Notifications of complaints include administrative and technical contacts information. QUESTION: We have spent most of this meeting exploring the role of compliance at ICANN, in order to support a proposal that ICANN has an implicit contract with the registrant and that therefore 6 1 b applies as a grounds for processing. This would also facilitate ICANN operating a UAM on behalf of those who want the data. It might also explain Goran’s initiative in seeking some kind of recognition by EU authorities that ICANN has a kind of quasi-regulator status, as the authority vested with the responsibility to manage the DNS. Given that all of this is outside the current configuration of ICANN as data controller, which would be more clear had we done a DPIA and had we adequate data maps to work with….can we either get back to our Charter questions that we were mandated to address by the GNSO, or get a full explanation of what is going on and why we continue to be focused on the access question. RESPONSE: This request appears to be directed at the EPDP Team and not ICANN org as ICANN org does not dictate the direction of the EPDP Team’s discussion. QUESTION: Why hasn’t a Data Protection Impact Assessment been carried out to clarify data flows and ICANN’s relationship with the data subject in light of its acknowledged role as a joint controller and Article 35 of the GDPR? RESPONSE: This question was also asked during the Data Protection/Privacy Update Webinar hosted by ICANN org on 8 October 2018. John Jeffrey, ICANN’s General Counsel and Secretary provided the following response: “This is something that has been considered since the very beginning. One of the issues is when to do that in a way that is most timely and useful and how to do that. We continue to evolve the thinking of how the interpretation of GDPR applies to WHOIS. We have a number of questions which have been addressed directly to the DPAs and the EDPB and we’ve have an ongoing discussion with the EC about how to interpret the GDPR. We believe that those are a better format at this point than doing the assessment, but we continue to evaluate whether that assessment would be the right thing to do and when.” The presentation for the webinar is posted here<https://www.icann.org/en/system/files/files/presentation-data-protection-pr…>, and the Adobe Connect recording is here<https://participate.icann.org/p29vt2uxodx/>. The question and response start at 0:27:00 in the Adobe Connect recording.

5 5

Request for independent legal counsel to assist the EPDP
by Stephanie Perrin Oct. 9, 2018

Oct. 9, 2018

Hello everyone, please find attached a request to hire outside counsel with expertise in data protection law, to assist us with the analysis on the EPDP. The RySG, RrSG, and NCSG representatives on the EPDP are all in support of this proposal, which as you know was foreseen in the Charter and in our earlier GNSO discussions. Thank you. Stephanie Perrin

4 3

Small team #3 background information
by Marika Konings Oct. 9, 2018

Oct. 9, 2018

Dear All, In preparation for the small team #3 meeting on Wednesday, please find attached two background documents. The first one captures the charter questions, relevant EDBP advice, relevant Temporary Specification sections and related questions to ICANN Org. The second document captures the input provided by the EPDP Team to date through the triage surveys and early input. As a reminder, please make sure that max. one rep per group has been assigned to this small team (see https://docs.google.com/document/d/1ChEYy-cZmT3qTD62-HsoVmddD96m6cbkSOv5dmA…) The small team #3 meeting is scheduled for Wednesday 10 October from 13.00 – 15.00 UTC (call details have been circulated separately). 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…>.

1 0

Proposed Agenda - EPDP Team meeting #18 Tuesday 9 October at 13.00 UTC
by Marika Konings Oct. 8, 2018

Oct. 8, 2018

Dear All, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Tuesday 9 October at 13.00 UTC. Best regards, Caitlin, Berry and Marika EPDP Meeting #18 Agenda Tuesday, 9 October 2018 1. Roll Call & SOI Updates (5 minutes) 2. Welcome and Updates from EPDP Team Chair (5 minutes) * Additional travel support for ICANN63 * Request for independent legal counsel to assist the EPDP * Lawful basis memo – any other input that should be recorded in the latest version? * ICANN63 High Interest Topic Session Planning * Review of outstanding action items * Other updates, if applicable 1. Review outstanding questions in relation to charter question c) Transfer of data from Registrar to Registry (blue signifies has not been discussed yet): * c1) What data should registrars be required to transfer to the registry? * c2) What data is required to fulfill the purpose of a registry registering and resolving a domain name? * c3) What data is transferred to the registry because it is necessary to deliver the service of fulfilling a domain registration versus other legitimate purposes as outlined in part (a) above? * c4) Is there a legal reason why registrars should not be required to transfer data to the registries, in accordance with previous consensus policy on this point? * c5) Should registries have the option to require contact data or not? * c6) Is there a valid purpose for the registrant contact data to be transferred to the registry, or should it continue to reside at the registrar? (note: the two highlighted in blue are the primary focus of today’s discussion, but the others are related and should be used to provide context to the transfer topic as necessary) Objective of discussion: (1) Review outstanding charter questions and review data elements workbook for purpose A with focus on what data elements need to be transferred from registrar to registry (2) Agree on data elements needed to be transferred as well as responses to outstanding charter questions * Review data elements workbook for Purpose A * Deliberate on outstanding questions * Agree on proposed response to charter questions 1. Update on status of remaining data elements workbooks & open items Objective of discussion: (1) Confirm status of data elements workbooks (2) Identify volunteers to address any open items * Review status of remaining data elements workbooks & open items * Identify volunteers to address any open items & confirm timeline 1. Wrap and confirm next meeting to be scheduled for Thursday 11 October at 13.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…>.

2 1