October 2018 - Gnso-epdp-team

Recordings, Attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP Small Team Meeting #3 held Wednesday, 10 October 2018
by Andrea Glandon Oct. 10, 2018

Oct. 10, 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 Small Team #3 call held on Wednesday, 10 October 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/8AO8BQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-10oct18… <https://urldefense.proofpoint.com/v2/url?u=https-3A__audio.icann.org_gnso_g…> AC Recording: https://participate.icann.org/p4vtgefqcqa/<https://participate.icann.org/p4vtgefqcqa/?OWASP_CSRFTOKEN=569d53d7fc4c3255…> ** 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

**REMINDER** Meeting Invitation / Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call Small team #1 / Thursday, 11 October 2018 at 17:00 UTC
by Julie Bisland Oct. 10, 2018

Oct. 10, 2018

Dear all, Non-members can follow the EPDP small team #1 taking place on Thursday, 11 October 2018 at 17: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/KAWrBQ Thank you. Kind Regards, Terri Agnew

1 0

***REMINDER*** Meeting Invitation / Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 11 October 2018 at 13:00 UTC
by Julie Bisland Oct. 10, 2018

Oct. 10, 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

Re: [Gnso-epdp-team] Notes & action items from today's meeting
by Trang Nguyen Oct. 10, 2018

Oct. 10, 2018

Dear All, As per action item #3 below, Dan and I as ICANN Org liaisons reviewed the draft "Lawful Basis" memo<https://community.icann.org/download/attachments/95094053/Lawful%20Basis%20…> circulated on Monday. There are some areas where there is considerable change from the contents of the Temporary Specification, such as redefining and assigning owners to the "purposes", as well as the characterization of the "responsible parties" and their roles. It's understandable that the EPDP Team is considering changes from what was in the Temporary Specification as per the EPDP charter<https://gnso.icann.org/sites/default/files/file/field-file-attach/temp-spec…>. ICANN Org however has been directed<https://www.icann.org/resources/board-material/resolutions-2018-05-17-en> by the Board to implement the Temporary Specification. Accordingly, as liaisons from ICANN Org we are unable to convey an official ICANN position that differs from the Temporary Specification at this time. We will however continue to follow the EPDP Team's discussions carefully and supply whatever information we can to help advance the Team's discussions. Best, Trang and Dan ICANN Org Liaisons From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Tuesday, October 2, 2018 at 9:20 AM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Notes & action items from today's meeting Dear All, Please find below the notes and action items from today’s meeting. In order to facilitate the signing up for the small teams, please use the following link https://docs.google.com/document/d/1ChEYy-cZmT3qTD62-HsoVmddD96m6cbkSOv5dmA…. As a reminder, please self-organize and assign max. 1 member from each group per small team. Call details will be sent to all, but only designated members are expected to attend (view only AC will be available for others interested to follow the deliberations). Best regards, Caitlin, Berry and Marika ============= EPDP Team Meeting #16 Tuesday, 2 October 2018 Notes and Action Items High-level Notes/Actions: Action item #1: add to Purpose C a second processing activity that is focused on disclosure of technical contacts to third parties t to communicate or notify RNH of technical and/or administrative issues (third parties 6.1(f)). Action item #2: Regarding the Legal Basis document, RySG to provide additional data processing steps by Wednesday 3 October COB. Action item #3: EPDP Team to review lawful basis memo and proposed designations for each purpose and processing activity and communicate by Wednesday COB any objections to the proposed designations Action item #4: Leadership to develop methodology to be developed to further consider idea of ICANN having direct contract with registrants. Action item #5: Alan Greenberg to write statement why optional provision of admin/tech contact is important. Action item #6: EPDP Team to review planning and schedule and share any feedback on the list. 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) * Recap EPDP Team F2F meeting - see high level notes circulated and posted on the wiki (https://community.icann.org/x/rQarBQ) Feedback welcome on what worked well and what didn't. * Meeting schedule going forward - to be discussed under item 5 on the agenda. * Review of outstanding action items - see https://community.icann.org/x/NwSNBQ * Other updates, if applicable 3. Legal basis for purposes and related processing activities Objective of discussion: (1) Agree on legal basis for different purposes and related processing activities a) Review legal basis memo outlining how to differentiate between Art 6.1(b) and Art 6.1(f) and discuss how this can be applied to purposes identified and related processing activities b) Agree on legal basis for purposes and related processing activities * See memo that was circulated prior to this meeting * Lawful test designed by Thomas facilitated the discussions but there was still confusion around what it means "necessary for performance of a contract" * Example found from the UK Information Commissioner's Office - processing must be necessary for the delivery of your part of the contract. If the processing is only necessary to maintain your business model more generally, this lawful basis will not apply. * Lawful test in combination with example applies to the EPDP Team purposes. Highlighted in blue is where small team came to agreement on lawful basis, those in orange, based on leadership team assessment. * For purpose A, does this just concern data for WHOIS or is it broader than that - this is focused on the data that is collected by the registrar, regardless of where it is. * Purpose C - focused on registrar communication, but this is mainly for other parties, why is that not included? If it is for other parties, the lawful basis would be 6.1(f). Add second processing activity focused on third parties (6.1(f)). May also be captured under purpose B? * May need to distinguish between what is collected and what goes into an RDDS? For example, in relation to Purpose N. Purpose N not limited to Spec 13, would also include Spec 12 gTLDs. Policy recommendations to cover the circumstances and purposes through which additional data elements are collected, even if those are not published or disclosed through RDDS. * In Purpose A, is a processing activity missing? Responding to requests from Registered Name Holder for purpose A. Should RNH be mentioned as a separate party? RNH is the data subject. * For Purpose A, transmission of registration data - why is this both 6.1(b) and 6.1(f) - isn't protecting against abuse a necessary part of the contract? * For Purpose E, isn't this also 6.1(b) as it is part of the broader requirements? Small team discussed what would present best case for success presenting this to DPAs and agreed on 6.1(f). * BC would support ICANN Org having a direct relationship with registrant to allow for 6.1(b) if this is currently prevented because ICANN does not have a direct contractual relationship with registrants. * For purpose F, why not 6.1(b)? In theory you could abolish contractual compliance and domain name registration would still work, hence 6.1(f) argument. * Need additional processing activity in M for party that files complaint and needs access to information. Needs to be further considered. * Helpful way to lay this out visually, makes it easier to understand. Groups need a bit more time to review and comment. * EPDP Team to review memo and especially link to CIO web-site. * Also note that there where disagreement may persist, this could be called out in the Initial Report as a question for which specific input is requested especially from DPAs. Action item #1: add to Purpose C a second processing activity that is focused on disclosure of technical contacts to third parties access to this information to communicate or notify RNH of technical and/or administrative issues (third parties 6.1(f)). Action item #2: Regarding the Lawful Basis document, RySG to provide additional data processing steps EPDP Team to review this document and come back with feedback by Wednesday 3 October COB. Action item #3: EPDP Team to review Lawful Basis memo and proposed designations for each purpose and processing activity and communicate by Wednesday COB any objections to the proposed designations Action item #4: Leadership to develop methodology to be developed Small team to further consider idea of ICANN having direct contract with registrants. 4. Review data elements workbook for purpose C - Enable communication or notification to the Registered Name Holder and/or their delegated parties of technical and/or administrative issues with a Registered Name (see https://community.icann.org/x/5AC8BQ) Objective of discussion: (1) Review data elements workbook for purpose C as completed by small team during LA F2F meeting (2) Agree on data elements needed for this purpose as well as responses to different questions in data elements workbook a) Review data elements workbook for purpose C b) Discuss any outstanding items / questions c) Finalize data elements workbook for purpose C * See data elements workbook for purpose C (see https://community.icann.org/x/5AC8BQ) * Mandatory fields to be collected under 6.1b, optional fields to be collected under 6.1(a) - consent. * What does optional mean? If no admin/tech contact info is provided, does it then default back to the registrant information? * If admin/tech contact info is provided, consent will need to be provided by the admin/tech contact. * If there is no reason to collect the data, would it go against the principle of data minimisation? Is option that is provided to RNH, only those that want to make use of this would opt for it, not a requirement. * In practice it is often a duplicate and no unique information is provided. * You could define two different products: 1 where the registrant acts for all contacts 2 where he / she wishes to designate additional contacts. In such case, both could be 6 I b and collection of third party that would occur based on Art. 14. * Why is making it an optional field problematic? As no one is required to do anything? Under GDPR you will still need to explain why data is collected. Action item #5: Alan Greenberg to write statement why optional provision of admin/tech contact is important. 5. Share list of outstanding issues and plan for addressing these * See planning document circulated prior to the meeting * How to sign up for small groups? Groups expected to self-organize - ideally max. 1 rep per group. Could use google doc to have an idea of attendance. Action item #6: EPDP Team to review planning and schedule and share any feedback on the list. 6. Wrap and confirm next meeting to be scheduled for Thursday 4 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…>.

8 10

Legal Basis Discussion
by Kurt Pritz Oct. 10, 2018

Oct. 10, 2018

Hi Everyone: Following on Caitlin’s earlier memo that described remaining issues having to do with the determination of Legal Basis, I wish to raise some points in regard to our last full-team meeting where we debated different legal bases for third-party escrow of personal data. . Please excuse another longish email. To facilitate my own understanding and help steer future debate, please let me know where you agree and don’t by number (and if you don’t, why). 1. Whether 6(1)b or 6(1)f applies to Data Escrow is a legal question not a policy question. Once we realized there were differences in team members’ opinion as to whether 6(1)b attached, additional discussion was not fruitful because it was not a policy debate. No one could debate, “6(1)b should be the legal basis for third-party data escrow as a matter of policy.” For the case of Data Escrow, given the current set of facts and elements in GDPR, 6(1)b either is or is not a legal basis for processing to escrow personal data. That will be decided for a DPA. GDPR is a law that has elements and an impartial decider will determine of those elements are met by the data processing described in our policy. 2. It is reasonable for us to debate / discuss whether, under a specific set of circumstances, a legal basis exists for processing data. If we find that a legal basis exists (after determining processing is necessary and principles of minimization are applied), then we include that processing step under our list of purposes. In most (i.e., all or nearly all) cases, we will be correct because we will have done the appropriate analysis. However, it will be for a DPA to review the policy or its implementation before that fact is known for sure. 3. It is our process (and I think our policy) that, in linking a data processing step with a legal basis, we select the first one that clearly attaches, considering them in the following order: a. 6(1)a Consent b. 6(1)b Necessary for performance of contract c. 6(1)f Legitimate interest not overridden by the interests or fundamental rights and freedoms of the data subject If it is debatable whether, say, 6(1)b attaches, we should be able to go on to 6(1)f without having to make the 6(1)b call first. See number 5 below. 4. Regardless of the Legal Basis selected, the same data will processed every time. Taking as an example Data Escrow with a third party provider, the data elements selected must be necessary for the purpose in accordance with the principles of minimization. Then, whether the legal basis is 6(1)b or 6(1)f, the same data will be transmitted to the escrow provider every time. The legal basis test is only performed once, when this new policy in enforced and becomes operational, i.e., where GDPR compliance is demonstrated. I think this is the same in every case. If that is correct, I don’t see why we would urge that one legal basis be selected over another for any reason other than it would be most likely to be accepted by the DPA. 5. At this stage of the game, I don’t understand why we have to pick one legal basis. I understand the practice of ultimately relying on one legal basis, however in the formation of new policy, cannot different scenarios be tested? If several team members think that 6(1)b attaches to data escrow, why must we be forced to either put all our eggs in that basket or ignore it completely? As stated above, this is not a policy decision, it is a legal determination. Why cannot we iterate these issues with DPAs, saying, “Look, this data escrow thing is clearly in the best interests of the data subject and we are only processing the data necessary to accomplish this purpose. We think Art.6(1)b applies here but are not sure. We are certain that 6(1)f applies but if 6(1)b applies that will make our analysis and yours easier.” I don’t think the intent of the new law is to force uninformed decisions. I don’t know of any other arena (except, ironically, maybe the existing Conflict of National Laws Policy) where these choices must be made blindly. Should we be reaching out to DPAs on this issue? I hope you find this a helpful guide to our thinking on this and would appreciate feedback on these thoughts. Best regards, Kurt

3 2

Meeting Invitation / Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call Small team #1/ Thursday, 11 October 2018 at 17:00 UTC
by Terri Agnew Oct. 9, 2018

Oct. 9, 2018

Dear all, Non-members can follow the EPDP small team #1 taking place on Thursday, 11 October 2018 at 17: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 Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u Agenda wiki page: https://community.icann.org/x/KAWrBQ Thank you. Kind Regards, Terri Agnew

1 0

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