Dear EPDP Team, Please find below the notes and action items from today’s EPDP Team meeting. Best regards, Caitlin, Berry and Marika ======================== EPDP Team Meeting #21 Tuesday, 30 October 2018 Notes and Action Items High-level Notes/Actions: Action item #1: Margie to provide further details in relation to potential disclosure to complainant in relation to possible UDRP filing, in particular, distinguishing such a disclosure from that already provided for in Purpose B. Action item #2: Staff to produce updated clean version for Purpose M for EPDP Team adopting the recommendations made by Kristina and Diane. Amr to create clarifying question to ICANN staff regarding reasons for including or excluding PDDRP and RRDRP from this purpose. Action item #3: Kristina to connect with Milton and Amr to see how concerns can be addressed in relation to Purpose N, particularly whether Purpose N should be included in this policy, and suggest updates accordingly. Questions for ICANN Org from the EPDP Team: None Notes & Action items 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) Recap of ICANN63 meetings * The Team made meaningful progress on Purposes A, B and C, particularly in reference to the purpose statements. * Additionally, the Team reviewed language from the small teams re: geographic basis, reasonable access, and natural vs. legal persons. b) Update on F2F planning * Following Kurt's message to the Team, many people identified conflicts. * We will send a doodle poll to identify preferred dates. c) Review of outstanding action items * Please refer to Marika's email of Thursday, 25 October for action items. Important for groups to provide input as soon as possible. d) Other updates, if applicable 3. Purpose M Data Elements Workbook (Resolution of Disputes) Objective of discussion: (1) Determine inclusion/exclusion of RDDRP, PDDRP, and PICDRP RPMs within the purpose statement (adjust PAs if excluded) (2) Confirm staff-suggested responses for Purpose Rationale questions (3) Confirm Processing Activities structure, especially Disclosure and Retention (4) Confirm Data Elements a) Review Purpose M Data Elements Workbook (see https://community.icann.org/download/attachments/96207076/Purpose%20M%20-%20...) b) Confirm content of purpose M Data Elements Workbook c) Confirm next steps, if any * See updated version circulated by Diane * Proposed to refer in purpose statement to coordinate, operationalize and facilitate * Also added 'future developed domain name registration related dispute procedures' to make it future proof. * Distinct lawful basis depending on dispute resolution process * Update RRDRP (misspelled in current version) * See also ICANN Org response: The RDDRP, PDDRP, and PICDRP <https://newgtlds.icann.org/en/program-status/pddrp> are dispute resolution procedures where the gTLD registry operators themselves are the respondents. Under the Registrar Transfer Dispute Resolution Policy <https://www.icann.org/resources/pages/tdrp-2016-06-01-en> the respondents are registrars. This is different from URS and UDRP proceedings where individual domain registrants are the respondents. (Note: gTLD registry agreements may also contain other dispute resolution procedures, for example, .NAME has an “Eligibility Requirements Dispute Resolution Policy” <https://www.icann.org/resources/pages/appendix-11-2013-07-08-en>.) * PII may be involved in these registry dispute resolution procedures. * ROs are the respondents in PDDRP and RRDRP. ROs could also be the Complainants, but that seems very unlikely - esp. w/r/t PDDRP. RDPR procedures specify that the parties to the procedures are "harmed established institution and the gTLD registry operator." * Disclosure to complainant - should this be covered here? How is situation different from pre-GDPR, for example privacy/proxy registrations? Prior to filing there is no dispute, so doesn't this then fall under Purpose B? Need to be able to investigate prior to filing to avoid frivilous filings, but at the same time, avoid disclosure for other reasons ("fishing expedition"). Complainant needs to be able to establish that it has trademark rights in a registration. Action item #1: Margie to provide further details in relation to potential disclosure to complainant in relation to possible UDRP filing, in particular, distinguishing such a disclosure from that already provided for in Purpose B. Action item #2: Staff to produce updated clean version for Purpose M for EPDP Team adopting the recommendations made by Kristina and Diane. Amr to create clarifying question to ICANN staff regarding reasons for including or excluding PDDRP and RRDRP from this purpose. 4. Purpose N Data Elements Workbook (Validation of gTLD registration policy eligibility criteria) Objective of discussion: (1) Determine if Purpose Statement is an ICANN Purpose (note Collection PA indicates ICANN as a Joint Controller) (2) Confirm Processing Activities structure, especially Disclosure and Retention (3) Confirm Data Element (Other Data) a) Review Purpose N Data Elements Workbook (see https://community.icann.org/download/attachments/96207076/Purpose%20N%20-%20...) b) Confirm content of purpose N Data Elements Workbook c) Confirm next steps, if any * See latest version shared. * Would be lawful under 6(1)b for registrars and 6(1)f for registries. Depends on whether it is voluntary or whether it flows from the registry operator contract. * Is it necessary to include this information in the RDDS for Registry Operators? Brand registry group - to the extent that it is important for customer trust to be able to have some signal that the registrant is in fact who they say there are, there would be value in that. Similar responses from Registry SG members. * That doesn't seem to align with the purpose as described as it is not about trust - why should this be included in the RDDS? * Allowing registry operator to be transparent and accountable - aren't there other ways in which this can be done? How does it fit with the work of the EPDP Team? * This appears to be between Ry and Rr, no disclosure involved and only for the purpose limited to validation. * For any community restrictions, these are included in the contracts. Need to find a balance that doesn't add more into the policy recommendations then what is needed, but also allow registry operators to innovate within their TLDs. * Does it concern mainly legal persons? Mostly, but some do allow for natural person registration, for example .NYC. * Consider adding a question to the Initial Report to ask for input on whether this is needed or not? * Consider adding to the purpose statement "in order to", to provide some further explanation. * Registry operators will need to collect this information and will need to do so in compliance with GDPR. * Disclosure is not foreseen outside applicable registry operators and ICANN compliance, if necessary. Consider addressing this in data elements workbook. * If it is a registry purpose and not an ICANN purpose, does it belong here? But if it is in compliance with an ICANN contract, maybe it does? ICANN does not impose policies on any registry to have an eligibility policy. They choose it. Action item #3: Kristina to connect with Milton and Amr to see how concerns can be addressed in relation to Purpose N, particularly whether Purpose N should be included in this policy, and suggest updates accordingly. 5. Wrap and confirm next meeting to be scheduled for Thursday 1 November at 13.00 UTC. a) Confirm action items b) Confirm questions for ICANN Org, if any * For meetings next week, time will change to 14.00 UTC to accommodate for day light savings changes. Apologies to those who are not affected by DST. Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@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_gns...>.