November 2018 - Gnso-epdp-team

FW: [Ext] Fwd: Additional language for roles and responsibilities
by Marika Konings Nov. 19, 2018

Nov. 19, 2018

Dear All, Please see email from Thomas below which may not have made it to the list. Best regards, Caitlin, Berry and Marika Anfang der weitergeleiteten Nachricht: Von: Thomas Rickert <thomas(a)rickert.net<mailto:thomas@rickert.net>> Betreff: Additional language for roles and responsibilities Datum: 18. November 2018 um 21:59:10 MEZ An: "gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Kopie: Thomas Rickert <thomas(a)rickert.net<mailto:thomas@rickert.net>> All, As discussed during out last call, please find below an additional paragraph to be inserted after line 1628, i.e. at the end of Recommendation #13. The challenge was to keep the language concise, yet cover the most urgent operational questions that came up, while not stepping over the line and do work outside the picket fence. You will decide whether these parameters were met in the language below, but I hope it will at least serve as a starting point for our discussions. Kind regards, Thomas The EPDP Team understands that a joint controller situation between ICANN Org, Registries and Registrars requires work at a greater level of granularity than in this report. During the negotiations, the parties shall conduct a detailed review of the individual processing activities and the actions to be taken by the respective parties. A clear demarcation the processing activities covered by the JCA versus those carried out by either party outside the scope of the JCA shall be documented and reflected both in the private as well as in the public version of the JCA. The JCA shall ensure that the risks of data processing are shared adequately based on whose interests are concerned. Also, the JCA shall include indemnifications to ensure that no party shall ultimately be liable for another parties’ wrongdoing. The JCA shall recognize that parties are currently using third parties’ services or otherwise work with third parties, such as - Data Escrow Agents - EBEROs - Registry Service Providers - Registrar as a Service Providers - Resellers - Dispute Resolution Providers - the TMCH. This may or may not include processing of personal data by those third parties. Where personal data is processed by third parties, the respective joint controller will need to ensure that the data processing is carried out in a way compliant with GDPR. However, conditional to GDPR compliance, nothing in the JCA shall prevent the respective joint controller from engaging third parties and entering into the required agreements without further authorizations from the other joint controllers. The EPDP Team considers it out of scope of its work to prescribe in what form JCAs will be entered into, as long as a set of the minimum requirements as specified in the EPDP Team’s report, are met. It does appear advisable, though, to create one template, which can be amended to reflect situations that are not applicable industry-wide (such as eligibility requirements for registered name holders) and that JCAs are entered into per TLD between ICANN Org, the respective Registry Operator and registrars. A potential way to facilitate contracting would be to make the JCA part of the RRA, so there would be separate tri-partite agreements between ICANN Org, the Registry Operator and each registrar. Standardized parts of the JCA should include the informations that are legally required to be provided to the data subjects to allow for the use of the same language across all TLDs as much as possible.

2 1

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 20 November 2018
by Julie Bisland Nov. 19, 2018

Nov. 19, 2018

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

1 0

Proposed Agenda - Meeting #28
by Marika Konings Nov. 19, 2018

Nov. 19, 2018

Dear all, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Monday 19 November at 14.00 UTC for three hours. Best regards, Caitlin, Berry and Marika ========================= EPDP Meeting #28 Agenda Monday, 19 November 2018 1. Roll Call & SOI Updates (5 minutes) 2. Welcome and Updates from EPDP Team Chair (5 minutes) * Review of outstanding action items * Other updates, if applicable 1. Continue review & discussion of comments / input received on Initial Report Objective of discussion: (1) Review proposed changes / comments on the Initial Report that require EPDP Team consideration (2) Agree on if/how these proposed changes / comments are to be applied to the Initial Report * Commence review of proposed changes / comments on the Initial Report (see latest version attached) * Confirm approach for addressing these * Confirm next steps, if any 1. Other items to be finalized: * Purpose O – how to address in Initial Report * Additional language re. responsibilities section (Thomas) * Additional language re. UDRP (Margie) 1. Next steps for publication: * Public comment forum – Google form * Community Webinar * Letter to EDPB 1. Wrap and confirm next meeting to be scheduled for Tuesday 27 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…>.

2 1

Some badly needed wording fixes as we finalize interim report
by Mueller, Milton L Nov. 19, 2018

Nov. 19, 2018

All, I have been going through the Exec Summary of the interim report and have found some issues. Most of these are grammar or copy editing fixes that I hope we can accept without controversy. One of them has a substantive element, though. Footnote 2, page 4: “the EPDP Team anticipates taking a formal consensus call..” Shouldn’t this be “WILL take a formal consensus call…” To say "anticipates" sounds like we might not do so if it’s not convenient. We are required to take a consensus call Line 150-151: The wording of Preliminary Rec 2 is awkward and ungrammatical. It now reads: “The EPDP Team commits to develop and coordinate policy in the system for standardized access to non-public registration data portion of this EPDP regarding lawful access for legitimate third-party interests regarding abuse or intellectual property to data identified herein that is already collected.” This should be changed to: “The EPDP Team commits to develop and coordinate policy for disclosure of non-public registration data to third parties with legitimate interests.” Page 6, footnote 3. Delete. I thought we had agreed that after agreeing on Preliminary Agreement #3 that new policies on accuracy were out of scope. Page 6, footnote 4. This can be deleted, as the same text is included later on in page 7, lines 170-172 Milton Mueller

5 6

Re: [Gnso-epdp-team] Proposed Agenda - Meeting #28
by Marika Konings Nov. 19, 2018

Nov. 19, 2018

For those interested, you can find here the latest version of the Initial Report in which non-substantive updates were made as a result of the comments that were submitted between Friday and Sunday in the google doc: https://drive.google.com/a/icann.org/file/d/1zLpveft7yV85jirZpXjaczKfJyvXyn…. 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: Sunday, November 18, 2018 at 8:25 PM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed Agenda - Meeting #28 Dear all, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Monday 19 November at 14.00 UTC for three hours. Best regards, Caitlin, Berry and Marika ========================= EPDP Meeting #28 Agenda Monday, 19 November 2018 1. Roll Call & SOI Updates (5 minutes) 2. Welcome and Updates from EPDP Team Chair (5 minutes) * Review of outstanding action items * Other updates, if applicable 1. Continue review & discussion of comments / input received on Initial Report Objective of discussion: (1) Review proposed changes / comments on the Initial Report that require EPDP Team consideration (2) Agree on if/how these proposed changes / comments are to be applied to the Initial Report * Commence review of proposed changes / comments on the Initial Report (see latest version attached) * Confirm approach for addressing these * Confirm next steps, if any 1. Other items to be finalized: * Purpose O – how to address in Initial Report * Additional language re. responsibilities section (Thomas) * Additional language re. UDRP (Margie) 1. Next steps for publication: * Public comment forum – Google form * Community Webinar * Letter to EDPB 1. Wrap and confirm next meeting to be scheduled for Tuesday 27 November at 14.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

Re: [Gnso-epdp-team] Some badly needed wording fixes as we finalize interim report
by Alex Deacon Nov. 18, 2018

Nov. 18, 2018

Hi Amr, If you recall from our numerous discussions on this topic a main point of contention was around how specific we need to be GDPR compliant. The IPC has always argued that specificity is required - especially when defining which 3rd parties with legitimate interests may be granted access to non-public whois data. When we landed on the current wording for purpose 2 during the face to face meeting in Barcelona, I raised the concern that it was my experience that many do not believe that "security, stability and resiliency" include IP interests. This was confirmed as true by three people in the room. So it was and still is crystal clear to me vague language - including the language recently suggested by Milton - does not cover IP. I'm sure you can appreciate why this is a major concern for us. The compromise language addressed this major issue for the IPC - allowing us to move forward. If we all agree that abuse and intellectual property are legitimate interests then we should state it. As for why are these called out and others are not, the IPC believes they should all enumerated and plans to respond to Question #1 accordingly. I'll also refer you to my email to the list on Sep 12th (seems to long ago!) where I addressed this exact issue. "[...] Also, as you know personal data needs to be collected for specified, explicit and legitimate purposes. (Article 5(1)(b)) so given we removed "including but not limited to" we need to be explicit and not use general language. In addition the principle of transparency mentioned in recital 39 ("In particular, the specific purposes for which personal data are processed should be explicit and legitimate and determined at the time of collection of the personal data") and 58 ("The principle of transparency requires that any information addressed to the public or to the data subject be concise, easily accessible and easy to understand..." are relevant. This principal is further defined in Article 12(1) and Article 13(1). " Thanks. Alex On Sun, Nov 18, 2018 at 10:38 AM Amr Elsadr <aelsadr(a)protonmail.ch> wrote: > Hi, > > I recall that there were questions/concerns raised by this wording of the > recommendation that I don’t believe we ever got around to addressing. I’m > not sure what the purpose is of singling out abuse and intellectual > property in this recommendation. If there is a reason for doing this, it’d > be helpful to understand. > > I would imagine that a recommendation that reads similar to what Milton > suggested would cover both those categories. There are however, other > legitimate interests for which lawful disclosure/access to non-public > registration data is something we will need to work out in the next phase > of the EPDP, apart from abuse and intellectual property. Why do these two > get special status in this recommendation? > > Thanks. > > Amr > > On Nov 18, 2018, at 8:06 PM, Mark Svancarek (CELA) via Gnso-epdp-team < > gnso-epdp-team(a)icann.org> wrote: > > I think the awkwardness can be resolved simply by changing > > “standardized access to non-public registration data portion” > to > “standardized access to [the] non-public registration data portion”. > > Agree with Alex that we should not revise the compromise verbiage beyond > the addition of “the”, above. > > *From:* Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> *On Behalf Of *Alex > Deacon > *Sent:* Sunday, November 18, 2018 10:02 AM > *To:* milton(a)gatech.edu > *Cc:* gnso-epdp-team(a)icann.org > *Subject:* Re: [Gnso-epdp-team] Some badly needed wording fixes as we > finalize interim report > > Milton, All, > > I have to strongly object to Milton's suggestion that the text of Rec #2 > be updated as he suggests. We debated the language for Purpose B (now > purpose 2 of Rec #1) for weeks if not months - reviewing many versions and > numerous iterations. By the time we all got to Barcelona the current > language of purpose #2 is where we ended up and if you remember I expressed > the deep concern the IPC had with the language. > > In order to move forward James B. suggested a compromise - resulting in > what is now Rec #2 - addressing our concern and allowing us to move > forward. I greatly appreciated (and still appreciate) this pragmatic > suggestion from James and was encouraged that there was no objection from > any of us in the room. > > The request that we change the language of Rec #2 essentially undoes this > compromise and puts us back in time many weeks. A major change to the > intent of a recommendation such as this is inappropriate and must not be > allowed. > > Regards, > Alex > > > On Sat, Nov 17, 2018 at 9:14 PM Mueller, Milton L <milton(a)gatech.edu> > wrote: > > All, I have been going through the Exec Summary of the interim report and > have found some issues. Most of these are grammar or copy editing fixes > that I hope we can accept without controversy. One of them has a > substantive element, though. > > Footnote 2, page 4: “the EPDP Team anticipates taking a formal consensus > call..” > Shouldn’t this be “WILL take a formal consensus call…” To say > "anticipates" sounds like we might not do so if it’s not convenient. We are > required to take a consensus call > > Line 150-151: The wording of Preliminary Rec 2 is awkward and > ungrammatical. It now reads: > > “The EPDP Team commits to develop and coordinate policy in the system for > standardized access to non-public registration data portion of this EPDP > regarding lawful access for legitimate third-party interests regarding > abuse or intellectual property to data identified herein that is already > collected.” This should be changed to: > > “The EPDP Team commits to develop and coordinate policy for disclosure of > non-public registration data to third parties with legitimate interests.” > > Page 6, footnote 3. Delete. I thought we had agreed that after agreeing on > Preliminary Agreement #3 that new policies on accuracy were out of scope. > > Page 6, footnote 4. This can be deleted, as the same text is included > later on in page 7, lines 170-172 > > Milton Mueller > _______________________________________________ > Gnso-epdp-team mailing list > Gnso-epdp-team(a)icann.org > https://mm.icann.org/mailman/listinfo/gnso-epdp-team > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.o…> > > >

3 2

Response to ICANN org questions
by Caitlin Tubergen Nov. 18, 2018

Nov. 18, 2018

Dear EPDP Team, Below, please find answers to questions the EPDP Team posed to ICANN org: QUESTION: The Temporary Specification for gTLD Registration Data EPDP Team is currently considering language on a “Purpose M” regarding ICANN’s role in coordinating the development and implementation of policies concerning ICANN’s dispute resolution processes in the context of domain name registrations. Two of the processes currently being considered within scope of this purpose are the PDDRP (Post Delegation Dispute Resolution Process) and the RRDRP (Registry Restrictions Dispute Resolution Process). It would particularly be very helpful and important to the EPDP Team if ICANN could provide clarification on any point within the processes of PDDRPs and RRDRPs where processing of gTLD Registration Data is necessary for the dispute resolution processes to be completed. This clarification should identify which (if any) data elements within gTLD Registration Data are necessary, as well as all parties involved in the processing activities. RESPONSE: The PDDRP rules and the RRDRP rules each require the complainant (a trademark holder in PDDRP proceedings; an established institution in the relevant community in RRDRP proceedings) to “provide the name and address of the current owner of any at-issue domain name registration related to the dispute, to the best of the Complainant’s knowledge[.]” See PDDRP Rules, Section 3(b)(iv); RRDRP Rules, Section 3(b)(iv). The dispute resolution provider is required to serve the respondent (the registry operator) with a copy of the complaint, and to retain information related to the provider’s transmission of the complaint. Thus, these procedures may result in the complainant, provider, and/or respondent’s processing of gTLD registration data. It should be noted that neither of these procedures have been used yet. ICANN org would not process gTLD registration data in proceedings of either of these procedures because they are administered by independent dispute resolution service providers. However, if either procedure is used and ICANN org receives a panel’s decision, then that decision would include gTLD registration data. On another note, the current wording of Purpose M states: “coordinating the development and implementation of policies concerning ICANN’s dispute resolution processes in the context of domain name registrations.” It is unclear how developing and implementation of policy would involve processing of gTLD registration data or personal data. QUESTION: What is the rationale for not redacting organization field in the Temporary Specification? RESPONSE: Including the registrant organization field was determined to be consistent with ICANN org’s stated goal of complying with the GDPR while maintaining the WHOIS system to the greatest extent possible. The name of an organization refers to a legal person and not a natural person and therefore is arguably not covered under the GDPR. Additionally, the organization field is an optional field for registrants so to the extent that the registrant provides the organization name, the Temp Spec allows for publication of that information. Leading up to the development of the Temporary Specification, ICANN org consulted with the community and the DPAs to determine which data elements should continue to be made publicly available. Through the data matrix exercise where ICANN org asked contracted parties and interested stakeholders to identify user types and purposes of data elements required by ICANN policies and contracts, 40 user purposes for the registrant organization field were identified. For reference, Section 5.5.16(i) of the Interim Model for Compliance with ICANN Agreements and Policies in Relation to the European Union’s General Data Protection Regulation (also called the Cookbook) states that “the registrant “organization” would be required to be published (if applicable) so that registrations of legal entities would readily include the name of the entity.” -- Thank you. Best regards, Marika, Berry, and Caitlin

3 2

For review by Sunday 18 November - updated version of Initial Report
by Marika Konings Nov. 17, 2018

Nov. 17, 2018

Dear EPDP Team, Please find hereby the ‘hopefully almost final’ version of the Initial Report for your review: * Redline: https://drive.google.com/a/icann.org/file/d/15fRRL_ORRkspHI9HVNP3v3Zrpz-WBl… * Clean: https://drive.google.com/a/icann.org/file/d/1UOJZmbj99FjTRheqH2K-HKwp_Xxl31… As you will see, with the inclusion of the data element workbooks and the preliminary recommendations & questions in the executive summary, the report has become pretty lengthy (127 pages). To facilitate review by the community, you could consider making the report downloadable in separate parts, for example, by having the executive summary available for separate download and/or making the data element workbooks a separate download. As you review this latest version, please focus your input on any aspects that need to be updated as they are either insufficiently clear for the reader, incorrect or not reflecting accurately who is in support of a certain position. Please try to avoid reopening issues that have already been extensively discussed (you may consider starting a separate list of items that the EPDP Team should turn its attention to after the Initial Report has been published?). We hope that this version addresses all comments submitted to date and issues recently discussed, but if we’ve missed something, please also add this to the google doc comment form: https://docs.google.com/document/d/1SoNTnvvadNQ8nX_-OxN4mtsd-gfLNxT54GXSXyG…. As you add your comments to the google doc form, please be specific about which change you are proposing. Also, as you refer to the line number, please make clear whether this concerns the redline or clean version. Please submit your comments in the google doc table (https://docs.google.com/document/d/1SoNTnvvadNQ8nX_-OxN4mtsd-gfLNxT54GXSXyG…) by Sunday 18 November, end of day, at the latest. Thank you, 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 2

ICANN org response to EPDP question
by Caitlin Tubergen Nov. 17, 2018

Nov. 17, 2018

Dear EPDP Team, Below, please find ICANN org’s response to a question from today’s EPDP Meeting. Thank you. Best regards, Marika, Berry and Caitlin QUESTION: Is ICANN.org considering doing a DPIA, given the need for them to sort out their role? RESPONSE: A similar question was asked by the EPDP Team on 1 October 2018 to which ICANN org provided a response, which restated John Jeffrey’s comment on an 8 October 2018 webinar. To recap: In general, a DPIA is designed to (a) describe the processing and purpose of processing of personal data, including where applicable the legitimate interest pursued by the controller, (b) assess the processing necessity and proportionality, and (c) help manage the risks to the rights and freedoms of data subjects resulting from the processing. The elements of a DPIA are more fully described in Article 35(7) of the GDPR. Under Article 35(1), a DPIA is only required where a type of processing is “likely to result in a high risk to the rights and freedoms of natural persons”. ICANN org considered conducting a DPIA since early in the discussion of GDPR and gTLD registration data. One of the issues is when to do a DPIA that is most timely and useful--should the DPIA be conducted on the original requirements in the registry and registrar agreements, on the Temporary Specification which is temporary, or on the new requirements being discussed in the EPDP? We continue to evaluate whether that assessment should be performed and, if so, when. We are preparing some FAQs to provide further background on this topic, which we plan to publish next week. We will share with the EPDP Team a link to the FAQs once published.

2 1

Notes, action items from EPDP Team Meeting #27 - 16 November 2018
by Caitlin Tubergen Nov. 16, 2018

Nov. 16, 2018

Dear All, Below, please find the notes and action items from today’s EPDP Team meeting. As a reminder, our next meeting will be Monday, 19 November at 14.00 UTC. Best regards, Marika, Berry and Caitlin EPDP Team Meeting #27 16 November 2018 High-level Action Items Margie to suggest modifications to the UDRP/URS paragraph re: complainant access to registration data pre-filing to the list by COB today so other team members may opine on it. Support staff to note the issue of WHOIS accuracy to be discussed in Phase 2. Thomas to add language to the responsible parties text to recognize recent ICANN memo on the joint controllership topic. Support staff to send updated initial report draft with all relevant supporting documentation and relevant links. 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/uQXVBQ 1. Roll Call & SOI Updates 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 a. Review of outstanding action items b. Other updates, if applicable Today's goal is to continue going through the outstanding items for the Initial Report. Thomas will also have an opportunity to finish discussing his memo. ICANN Org liaisons may be asked to give a high-level overview of the memo. Benedict delivered Purpose O last night, so this will also be added to the agenda. The PCST (budget committee) decided to hold the third F2F in Toronto, Canada from 16 January - 18 January. Additionally, the team began a discussion about reengaging CBI. 3. Continue review & discussion of comments / input received on Initial Report Objective of discussion: (1) Review proposed changes / comments on the Initial Report that require EPDP Team consideration (2) Agree on if/how these proposed changes / comments are to be applied to the Initial Report a. Commence review of proposed changes / comments on the Initial Report The RrSG is meeting today to further discuss their comments, so for the Team's purposes today, we will not be discussing the Registrar issues at this time. Issues highlighted in green were dealt with yesterday. Beginning with Issue k, staff noted that per the PDP manual, recommendations to the GNSO Council can take many shapes or forms, including requests / advice to the GNSO Council. The recommendations, after adoption, are generally segregated to see who is responsible for carrying out the recommendation. If there is not a problem with asking the GNSO Council to do something, there may not be a problem. It would be helpful to go back to Kristina to better understand the issue. It will be important to specifically note when this group's work may impact other policies, including GNSO policies. Under letter m, what is the BC proposing to change? The BC notes problems with the functioning of the URS/UDRP since Complainants no longer have access to data prior to filing UDRP/URS complaints. This issue was highlighted on this list, so Support Staff added some language to the Initial Report to reflect the expressed issues, noting there is not currently consensus whether this should be a recommendation or not. If further clarification is needed, please write to the list. The Team does need to address the concern of unlimited access to non-public data under the guise of filing a UDRP. Action Item: Margie to suggest modifications to the UDRP/URS paragraph to the list so other team members may opine on it. Issue j: this was discussed early on in the context of the triage report. There was confusion regarding what "in another mechanism" means, so the text "determined by the EPDP Team" was added for further clarification. The mechanism may refer to future work in relation to access to full registration data. The team did speak at length about future work regarding standard access framework; however, why is there a mechanism for access to full registration data from the registry operator? If this language is confusing, it could be deleted. Do not see the value this bullet point provides - suggest removing. No disagreement to removing. This work is being addressed, just not at this stage. Preliminary recommendation 24 (letter n) - waiting for Kristina to provide further guidance. Going back to Issue n, it seems that agreement was reached to remove preliminary recommendation 24. (Note: this is now recommendation 21 in the updated report, so searching for exact language is better here.) Because this is confusing, can we discuss very deliberately what changes are proposed? On 14 November, ICANN published a report on the Transfer Policy. Any review of any policy that ICANN undertakes should look at the implications of GDPR. This recommendation may be unnecessary. Is there a way to inform the GNSO they should do this now? There is no value in the recommendation as its written now. The Team needs to consider accurate data and this should not be pushed further down the road and never dealt with. A recommendation, noting the question, is useful. Items T and U - accuracy of registration data. Coming out of the meeting in Los Angeles, we noted we would not diminish the accuracy recommendations. This is a parking lot issue. Registrar proposal - minor wording change, but this small change does not affect the meaning one way or the other, so it's OK to keep the previously-agreed to language. In that spirit, Rrs oppose the BC addition. All attempts to ensure accuracy have to be weighed, including the cost impact. How is accuracy defined here? It may be helpful to describe it here. The accuracy provision says that the data subject must be able to correct data. If the controller believes there are inaccuracies, the controller has the obligation to try to fix it. This is a parking lot issue so does not need to be discussed right now, so long as the report mentions it, that is sufficient. Action item: Support staff to note the issue of WHOIS accuracy will be considered further in Phase 2. Regarding issue v, this is an example of the team deliberating on the issue. The third sentence regarding other relevant parties is ambiguous and seems confusing to implement. b. Confirm approach for addressing these c. Confirm next steps, if any 4. Confirm / discuss any input on the Thomas’s Responsibilities text (if any) ICANN's summary of response to Thomas's memo: Instead of redlining, ICANN org thought it would be easier to read via a separate document. The Team's recommendation for joint controllership is different from what is currently in the Temp Spec. ICANN org's role is to provide information and implementation-related issues and concerns. Question: are there joint controllers or are they sole controllers? The examples the Art. 29 WP gives with respect to joint controllers are usually companies that operate on the same platform. How should the team work together going forward? ICANN org liaisons are flexible and are at the team's disposal to address this both in the initial report and after. The Team needs to get to a defendable solution to put in its Initial Report. Do any changes need to be made to the report at this time? There is a risk that ICANN org liaisons will go back into listening mode, and unless ICANN org liaisons are an active participant in the process, this Team cannot make progress. Who are the authors of the memo so that the Team can make direct contact with the authors? It would be helpful to offer concrete proposals to the community. Despite the Hamilton memo suggesting joint controllership, ICANN, in its cookbook suggests independent controllership. If this memo is not a position paper, what is it? Why did ICANN come to the conclusion that an independent controllership is present? If more analysis is necessary, how can ICANN come to the conclusion that a joint controllership is not present? ICANN memo has one primary driver - there is a fear that we move to a certain construction without knowing to the full extent what the liability could be. Art. 26 was established for scenarios where the data subject is confronted with complex data processing schemes with multiple parties. The Team should set up a dedicated group, including contracted parties, to set up a road map for items that need to be considered in a JCA. The alternatives are joint controllership or sole controllership for ICANN's purposes. There has been factual analysis to support joint controllership. The GDPR does not specify a joint controller agreement is necessary, but rather, a joint controller arrangement is necessary. In this instance, the RA, the RAA, and the RRA is the arrangement. This is something that should have been sorted out in 2017. While this memo is welcome, how can this report be released absent a balanced discussion of the controllership issue? If ICANN has issues with it, what will ICANN add to counter that and how can this be denoted in the report? The frustration is that this memo is coming so late in the day. While a written question may not have been directed to ICANN org, ICANN org was aware of the responsible parties analysis before the specific question was directed. If the Team manages to get to the finish line, we need assurance that this isn't going to be frustrated by an ICANN org determination that opposes the EPDP Team's conclusions. Where everyone agrees is that contracted parties and ICANN all need to sit down and work on a GDPR compliant arrangement. When ICANN says independent controller, is ICANN comfortable with co-controller instead? It's not a matter of what ICANN org is comfortable with, but rather - what is the correct classification under GDPR. If ICANN has any documentation that went into the cookbook regarding sole controllership, please share with the EPDP team. While the implementation may be difficult, the factual determination comes first. It may be best to list all of the places we agree and note the places we do not agree. When making edits on the google doc, please make it clear what line number you are referring to. 5. Wrap and confirm next meeting to be scheduled for Monday 19 November at 14.00 UTC. a. Confirm action items b. Confirm questions for ICANN Org, if any

1 0