Dear EPDP Team, Please find below the notes and action items from today’s meeting. The next EPDP Team meeting will be Thursday, 26 August at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV...> 1. EPDP Phase 2A Data Element Small Team to review the updated Google Doc<https://docs.google.com/document/d/1KfR9gYHuNMCkxlM9jM60C3o8eRDoCX7m/edit> and propose changes (if any) by today at 20:00 UTC. Note the following changes have been included in the updated document: (i) replaced “extended in RDAP” to “for the RDDS, (ii) shifted the “consistent with the EPDP Phase 2 recommendations” per Alan G’s comment in this doc, and (iii) deleted the “system” per Alan G’s comment that system is part of the title of SSAD. 2. Following the second reading of Recommendation 4, Support Staff to propose compromise language incorporating the feedback of Chris Lewis-Evans and Alan Woods by COB Tuesday, 24 August. (Please see p. 7 of the attached PDF.) 3. Following the third reading of Recommendation 1, Leadership will revert to the simplified version of the recommendation, unless a preference for Amr's version is indicated. 4. If EPDP Team Members have additional proposed updates to the recommendations discussed today (new recommendation on Code of Conduct and Recommendation 5 (email contacts)), please enter them into the NEW Google Doc<https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit> by COB Wednesday, 25 August. EPDP Phase 2A - Meeting #38 Proposed Agenda Tuesday 24 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) * Will allow minority statements to be submitted up to 10 September, which is the documents and motions deadline * However, the Final Report sans minority statements, will be submitted to the Council on 2 September 3. Continue review and updates to section 3 of Final Report - Responses to Council Questions & Recommendations (60 minutes) – see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit> As a reminder: timeline to get to Final Report 24 & 26 August – consider suggestions for further consideration & agree on updates to report 27 August – publish draft Final Report for EPDP Team review, consensus call. 30 August – deadline for minority statements – Note this has been updated to 10 September 31 August – finalize report and address any outstanding items, if any. * Update on status of recommendation #3 · Small team status update * The small team worked very well together to reach agreements – thank you to the small team for coming together to get to a compromise outcome. * The assignment sent out last week had five tasks for the small team: * 1. Was the kind element fit for purpose for the additional data element? Small team concluded that it was not, from a technology standpoint, in part because some of the kind element is subject to change * 2. If no, what data element(s) would be needed? The Team came to the conclusion that two data elements would be preferred for simplicity and flexibility. Loading a single data element with many values added to complexity and reduced flexibility. * 3. What options should be considered for the data elements? Each data element has four possible options. * 4. How does Rec. 3 need to be updated in light of the small team’s conclusions? The rec. has been updated in the text. * 5. What clarity can be given in terms of how these data elements would be implemented? There is not a clean way to redact personal data elements, so a group has been working on creating a new object around the redaction of the data elements. The group concluded that the same process would be repeated here – Org would work with the tech community to get these elements created. * EPDP recommends that a field or fields must be created - this is trigger to empower Org to get this implemented in conjunction with the technical community. These elements MAY be used by CPs would choose to use this. * The two data elements include four options: * Legal Status * The legal status distinction was not made. * Unspecified - Indicating the Registered Name Holder and/or registrar didn't specify. * Registered Name Holder is a Natural person * Registered Name Holder is a Legal person * Personal Data * The presence of personal data wasn't determined * Unspecified - Indicating the Registered Name Holder and/or registrar didn't specify * Registration data contains personal information * Registration data does NOT contain personal information * ICANN org liaisons assisted with running this by the GDS Technical Team * EPDP Team Feedback * Having listened to the dialogue over several weeks and the issues with GDPR and privacy, the direct statement over whether personal data is included is not secondary to many. Rather than characterizing that field as secondary, would give this equal status as legal v. natural. There is an option for registrants to say even though there is personal data here, there is the option to make it publicly available, but that would require a second field or interaction with the registrar. There is also a technical issue about how these data values are communicated. The correct structure is that the three base values and then there is the combination of these. * With respect to must be created or extended in RDAP – do these fields need to be published? If the legal environment changes, if these fields are created but not populated, this would be of little utility. * There is not an anticipated requirement at this time based on the recommendation of this EPDP for CPs to be obligated to populate the data in any case. The “must be created” is the trigger for ICANN org to work with the technical community to get this implemented. Everything else is optional. The data would be there for parties who choose to differentiate. * Maybe adding an implementation note could help make clear exactly what is intended here. Having the two fields may be less straightforward, but it does have the advantage of flexibility – CPs could use the personal v. non-personal data and not the legal v. natural. This approach, while not as clean, does give additional flexibility and supports that use case. * The language must be created or extended in RDAP. The original language said must be created – “or extended in RDAP” was an addition by ICANN org. Because the group is not exclusively married to RDAP, should remove that language. It could be used by CPs or could be used in RDAP. * Proposal: The EPDP Team recommends that a field or fields MUST be created, or MAY be extended in RDAP, that MAY be used by those Contracted Parties – that way, there is the option of an RDAP field but it’s not mandatory. The use of these fields must remain optional. * Phase 1 requires registrars to allow registrants to opt in to publication of personal data. Thought the group was defining new RDDS fields – while RDAP may be used, do not think RDAP is the appropriate word here. This should be changed to RDDS. Also, there was a great level of cooperation by the small team. * The fields may be published in RDDS, and RDAP is the only way to publish things in RDDS – if it’s not extended in RDAP, this won’t be possible. Must be created or extended in RDAP should remain. * There seems to be general agreement about replacing the RDAP with RDDS – the points made on this are valid – previous recommendations were technology agnostic. In terms of making the data element available in the public directory, that is already a given. Following this call, Support Staff will send a separate Google Doc to the small team to get to a conclusion on this. Will include the recordings in the meeting notes for anyone that is interested. * Day 1 * Please find below links to the audio recording, zoom recording (audio, visual and rough transcript) and chat for the Small team call (#1) held on Friday, 20 August 2021 at 15:00 UTC. * Audio Recording: https://icann.zoom.us/rec/play/DKoxGlXgGOhNjPM-K1TPZjvNhxm8L5R0mMJ6txRWqjnME... * Zoom Recording: https://icann.zoom.us/rec/play/eyPH7HFT9OegVw9p8ZEPEMjudmmakfqRYq_d8gZYNfoVg... * Zoom Chat: https://icann.zoom.us/rec/sdownload/LmRZGjRePv9Qgx8JuT1FzE3iUXrj6BLQQL75dHCU... * Please find below links to the audio recording, zoom recording (audio, visual and rough transcript) and chat for the Small team call #2 held on Monday, 23 August 2021 at 18:00 UTC. * Audio Recording: https://icann.zoom.us/rec/play/KVMnbTNAuHvB_6R4-6yEaKoWjg0ZY0ToUTvgcWU1v7CDH... * Zoom Recording: https://icann.zoom.us/rec/share/hVWBTT1t_E8KFZ-Y9CCJcAFD56IWJvfJ1bulrJe9Zo1g... * Zoom Chat: https://icann.zoom.us/rec/sdownload/iNlcWf4qluVkvGfn2JQeL09ce3Ww5Afi_9AydQJ8... · Confirm next steps * Review of Recommendation #4 (second reading) · Consider input provided * The Team received three versions of text – need clarification from the group regarding which version to use · EPDP Team discussion * Would prefer Chris L-E’s version because it clarified that you cannot just stop at identifying a legal person – you also have to ensure personal data is not in place * Perhaps provide Alan W’s comments in a footnote as these are important * Need a clear statement – the balance of Chris’ statement and putting Alan W’s comments in a footnote seem to be a good balance * Need to provide additional information and actual guidance that may be helpful for contracted parties who choose to make this differentiation. * There is general support for including a reference to the letter, either in the text or in a footnote. Could augment the text from Chris, augment it with suggestions from Alan W. * Support Staff to develop compromise language based on this discussion. * What is guidance in the team’s mind? What is provided is not guidance; it’s a reprint of the law. We should try to provide more information that could be useful to contracted parties. * Need to be realistic – the arbiter of if a CoC is not the community, but the EDPB – the community cannot guide what the EDPB agrees to or not. The community does not have a strong hand in legal liability. * Would be better if this were clear that requestors or groups that represent requestors are going to be a part of this * A CoC for requestors could happen – this could be a separate code of conduct, but these are two separate sets of purposes, and these should not be conflated. * Requestors purposes need to be figured in if this is an ICANN effort. * The key here is to ensure that if there is an ICANN org coordinated process to allow an opportunity for input. * This is not a one-shot process – cannot do this all at once – there is going to be an evolving set of requirements and an ongoing process * The language on the screen does reference future work by the relevant controllers and processors, and this is sufficiently broad at this point without being overly prescriptive · Confirm next steps * Support Staff to develop compromise language based on this discussion * Review of recommendation #5 (second reading) · Consider input provided * This is the recommendation regarding feasibility of unique contacts. The language provided by RySG was reviewed during the last meeting, and there were no objections. · EPDP Team discussion * Consider adding – both registrant-based and registration-based emails of natural persons are likely to be personal data * There needs to be a more effective means to communicate directly with the registrant. * Both registrant-based...email addresses of natural persons are likely personal. * Proposed edit: However, even if considered personal data, masking email addresses does provide benefits compared to publishing actual registrant email addresses, including: (i) demonstrating a privacy-enhancing technique/data protection by design measure (Article 25 GDPR); and (ii) some risk reduction relevant when conducting a legitimate interest balancing analysis for disclosure of data to third parties. "Moreover, use of a masked email promotes more effective communications to the registrant when necessary." · Confirm next steps * Review of recommendation #1 (third reading – if updated language is received) · Consider additional input provided * Leadership Team had proposed going back to a minimal response – there was no consensus achieved. There were concerns that that did not provide the complete picture. Amr provided updated text. * Comment in relation to what Amr put forward – Amr’s text suggests that the only thing the group had to do was to look at the study ICANN org had conducted. The only reason for going to Phase2A is the study was not available in time. This is not correct – we also reviewed language from B&B. If we are putting details in there, it is not just to evaluate the study. * In principle, prefer Support Staff’s streamlined version, but the streamlined version raised a lot of question and discussion on a previous call. Amr’s version lays out where the team is, and it’s important to draw a line under this discussion and note it is resolved. * The question to the group is – is the new version preferred over the previous version * There is a difference in the Phase 1 rec. between 17.1 and 17.3 – the important point to make is to resolve the legal v. natural issue, but not all are convinced that the legal v. natural issue was resolved. · Consider leadership path forward * Proposal to move forward with the simple text from leadership unless we hear Amr’s version is preferred · Confirm next steps * Review of recommendation #2 (third reading) · Consider additional input provided · Consider leadership path forward · Confirm next steps * Confirm next steps 4. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #39 Thursday 26 August at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any