August 2021 - Gnso-epdp-team

Notes and action items - EPDP Team Phase 2A Meeting #39 - 26 August 2021
by Caitlin Tubergen Aug. 26, 2021

Aug. 26, 2021

Dear EPDP Team, Please find below the notes and action items from today’s meeting. The next EPDP Phase 2A meeting will be Tuesday, 31 August at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- 🚨🚨 Action Items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…>🚨🚨 1. Support Staff to create a clean "cannot live with" table<https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit> and an updated redline Section 3 that incorporates (i) the non-substantive grammatical changes (which were highlighted in green) and (ii) the EPDP Team agreements from today's meeting. (complete) 2. Support Staff to propose compromise language based on the outstanding items from today's discussion. (complete) 3. EPDP Team to review the updated Section 3 document and populate any further "cannot live with" items based on the four highlighted questions (on p. 3, 7, and 9 of the redline Section 3 doc) into the new "cannot live with" table<https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit> by 17:00 UTC on Monday, 30 August. EPDP Phase 2A - Meeting #39 Proposed Agenda Thursday 26 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Consider and resolve “cannot live with” items for section 3 of Final Report - Responses to Council Questions & Recommendations (75 minutes) – see https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit As a reminder: timeline to get to Final Report 26 August – consider “cannot live with” items identified & agree on updates to report 27 August – publish draft Final Report for EPDP Team review, consensus call. 30 August – deadline for minority statements 31 August – finalize report and address any outstanding items, if any. 2 September – submission of Final Report to GNSO Council 10 September – final deadline for minority statements (any minority statements submitted after 30 August will be added to the Final Report, with the updated version to be submitted to the Council in time for the September meeting document deadline) * Review “cannot live with” items identified * Goal is to publish the integrated draft Final Report, following agreed upon next steps, including statement on consensus * 31 August – address remaining issues * May need to pencil in 2 September as a tentative meeting to resolve final issues, if any * Support Staff grouped the items that were flagged to better organize today’s discussion. * The first issue is the proposal to the GNSO Council – there are two specific proposals here. The first is to delete reference to implementation plans. Also, some noted that language in second part should be more specific. * Ultimately, it is still the Council’s decision when it would take on more scoping work. * Question for the Team to consider: would any of these changes being proposed result in “cannot live with” items for other groups? * The default should be does everyone agree not the other way around. Future changes should be defaulted to everyone cannot live with unless they say that they can. * Some note the reference to 9.4.4 in this recommendation should be deleted, as this is already referenced later in the report. * Question to the group – would the cannot live with item be resolved by deleting “which indicates that a Contracted Party needs to have a mechanism to identify that a registration record does not contain any personal data.” * Groups can live with the proposed compromise here * 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. * Would the group be OK with removing lines 87-91 and move these opinions to the minority statements, or if not, group should consider the proposed edits. * Not everyone will read the minority statements, so this text should be included in the text of the report. * Do not agree to remove this text, this constitutes whitewashing the report, as most readers will not read the minority statements * The report should accurately reflect the context in which the recommendation is given – that is why this preamble is important. Agree to be concise, but should not be whitewashed. * This does seem to be a significant change to be making at this stage. * This text detracts from the report and do not agree that this is whitewashing. If the Team lands on retaining this section, it needs to be clear that the paragraph does not belong in the previous section to GNSO Council. * If these are kept, they should be moved to footnotes so as to be clear that these are not part of the recommendation or policy. Whether or not someone reads the minority reports should not be this team’s concern – what matters most is how the recommendations are implemented, and the text needs to be clear for that reason. * The next edits apply to recommendation #1 and the footnote added. * It is important to maintain the option to create this field within their own platform – not just RDDS or SSAD. * Not concerned with what CPs are doing individually – the change from a must to a may is changing the entire concept of what was being discussed. The purpose is that when the fields are created is for all to use them. * It is coming back to haunt the Team that the Team is using different language to create these fields than we are using to create all other fields for Phase 1. * See value in having the field displayed somewhere, but do not think there is consensus on this. * Most important that the field is created. * The proposed changes from Staff Support reflect what the group agreed to. * Believe the group agreed to creation of an optional field that is similar to other RDDS fields – perhaps a footnote that makes this crystal clear is necessary. If we are talking about something that is just part of the registrar system, that is akin to a credit card field. * Suggest update to the specific contact provisions – the RDDS Spec of the CL&D policy * No members of the CPH team are supportive of using the field in RDDS at all * In the small team, there was agreement that there should be no prohibition in using this field in RDDS, but do see value in a standardized system, in particular for use and integration with SSAD * The terminology of RDDS was included originally so that there was a clear trigger for ICANN org to initiate the process outside of ICANN in the standards bodies in developing the RDAP extension – this field must be created. The language regarding RDAP and RDDS is now causing challenges – perhaps we could change this to a field must be created and include a footnote to enable or initiate this process to create a new extension. * Can the group not have a must and have a few mays in the same sentence – a field MUST be created and then tie to this language: The EPDP expects that the technical community, for example the Registration Data 119 Access Protocol (RDAP) Working Group, will develop any necessary standards associated with such fields. Having one long sentence is a bit confusing. * Fundamentally, the group has agreement that the new field must be created and must be used by those who differentiate. The specificity is the problem. RDDS may be one option for the use of such a field, but there may be other uses as well. Please provide suggested text either during the call today or shortly thereafter to move this forward. * Suggest that breaking the paragraph apart could help so that there is clear delineation between the must and the mays. Impression about the may be used in RDDS and the connection to the footnote – in RDAP, if there is no value in that field, it never gets transferred. Impression about the may – is that if a registrar chose to display this field, if they chose to publish it, it would mimic the Phase 1 recommendation the additional data element – for example, if .medical TLD requires additional registration requirements and they wanted it to be published, it would fall in as an additional data element that CPs could choose to publish as part of minimum public data set, but it would fall in with CL&D – in that it would be published at the bottom. * The original proposed language from the small team – field must be created that may be used by the contracted parties – that was the first draft and what was originally discussed. That was later amended to created or extended in RDAP. Finally, that was changed to “created for the RDDS” – these successive edits change the meaning. CPs agreed to a standard data element and agreed that it could be used in RDDS. * Action: Staff and Leadership team will come forward with proposed text for the group to consider. * Regarding ALAC’s comment about default values, registries did not have adequate time to discuss if this a cannot live with value. However, not clear why not having default values is a cannot live with item. * In terms of default value, the possible values are legal, natural, unspecified (which means registrant said will not say), or the question has never been asked. The default value should be no data has been provided. * Defining a field with four distinct values and would like clarity on what would be the default. * If advising a registrar would advise to ignore what a registrant says if not sure about geographic whereabouts – it is entirely possible for the field to be blank, vacant, or deleted. * May want to ignore the value, but do not agree that therefore you must not record the value. The default value is that you don’t anything and don’t know. How that translates into subsequent action is a separate matter. * The first value is the most innocuous and should be the default – looking for clarity for the implementation team. * RySG comment to change SHOULD to MAY – disagree with this change as it undermines the effort of many members * Could “are encouraged to” be in replace of should? * This guidance may be applicable in all jurisdictions and all cases – therefore this suggestion is not applicable in all cases. This is not an attempt to water down the language – just heard some pushback around the word should. * The point is you should follow the guidance – one of the reasons some would like the guidance is it helps to establish a normative direction. Could live with are encouraged to. * “Such flagging would facilitate” – RySG recommend changing would to could, as this is speculative. * No objections, so change applied. * Staff to update Section 3 in a redlined format and flag outstanding items from Support Staff’s side re: Rec. 1 and use it for further exercise of cannot live with. * Question from Staff – what does “within ICANN” mean in the context in the Code of Conduct? Noting that a code of conduct was not part of phase 1 or 2. * RrSG note that point ii under Rec. 5 is confusing – is this a cannot live with? * Is the yellow-highlighted change from strongly encourage to suggest considered a minor change to the Team? * What is the preferred way for the EPDP team to provide feedback? * Support Staff to create a clean table for the team to provide further input. Support Staff will also produce an updated redline so that everyone can see the what the changes will look like. * Agree on next steps 4. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #40 Tuesday 31 August at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any

1 0

Homework assignment - addressing remaining issues in Section 3 of Final Report
by Marika Konings Aug. 26, 2021

Aug. 26, 2021

Dear EPDP Team, Following the EPDP Team’s call today, please find attached a redline version of section 3 of the Final Report that incorporates those changes that were agreed to as a result of the review of the “cannot live with” items as well as minor edits flagged. Please note that highlighted in yellow comments we have identified four specific asks that are focused on the remaining outstanding issues. Please use the google doc (a new table has been added at the top) to provide your group’s response to these four asks: https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit. Please provide this input as soon as possible, but no later than Monday 30 August at 17.00 UTC. Minor edits / clarifications can still be added to the table at the bottom of the google doc. Best regards, Caitlin, Berry and Marika

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2A | Thursday, 26 August 2021 at 14:00 UTC
by Terri Agnew Aug. 26, 2021

Aug. 26, 2021

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2A call held on Thursday, 26 August 2021 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/54MZCg> and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a panelist, observers can join as an attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Terri

1 0

Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Tuesday, 31 August 2021 at 14:00 UTC
by Terri Agnew Aug. 26, 2021

Aug. 26, 2021

Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Tuesday, 31 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/KAMuCg * Check your time zone: https://tinyurl.com/9md9d9ts ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees, or Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz) before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

**starting in 15 minutes | Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Thursday, 26 August 2021 at 14:00 UTC
by Terri Agnew Aug. 26, 2021

Aug. 26, 2021

**Starting in 15 minutes Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Thursday, 26 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/54MZCg * Check your time zone: https://tinyurl.com/32r8stx7 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/32r8stx7__;!!PtGJab4!qiAF_b0…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees, or Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz) before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

3 2

Re: [Gnso-epdp-team] Proposed Agenda - EPDP Team meeting #39 on Thursday 26 August at 14.00 UTC
by Marika Konings Aug. 26, 2021

Aug. 26, 2021

Dear EPDP Team, To facilitate the review of the input received by the deadline, please find attached a compilation document that has been prepared by the staff support team. We hope this will be helpful in working through the different items that have been flagged as “cannot live with” in a constructive and efficient manner. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings via Gnso-epdp-team <gnso-epdp-team(a)icann.org> Reply to: Marika Konings <marika.konings(a)icann.org> Date: Wednesday, 25 August 2021 at 22:42 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed Agenda - EPDP Team meeting #39 on Thursday 26 August at 14.00 UTC Dear EPDP Team, Apologies for the delay, but hopefully the agenda for Thursday’s EPDP Team meeting shouldn’t come as a surprise. As a reminder, please submit any “cannot live with” items by COB today, Wednesday 25 August (see https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit) Best regards, Caitlin, Berry and Marika EPDP Phase 2A - Meeting #39 Proposed Agenda Thursday 26 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Consider and resolve “cannot live with” items for section 3 of Final Report - Responses to Council Questions & Recommendations (75 minutes) – see https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit As a reminder: timeline to get to Final Report 26 August – consider “cannot live with” items identified & agree on updates to report 27 August – publish draft Final Report for EPDP Team review, consensus call. 30 August – deadline for minority statements 31 August – finalize report and address any outstanding items, if any. 2 September – submission of Final Report to GNSO Council 10 September – final deadline for minority statements (any minority statements submitted after 30 August will be added to the Final Report, with the updated version to be submitted to the Council in time for the September meeting document deadline, similar to how this was done for phase 2) * Review “cannot live with” items identified * Agree on next steps 4. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #40 Tuesday 31 August at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any

1 0

Proposed Agenda - EPDP Team meeting #39 on Thursday 26 August at 14.00 UTC
by Marika Konings Aug. 25, 2021

Aug. 25, 2021

Dear EPDP Team, Apologies for the delay, but hopefully the agenda for Thursday’s EPDP Team meeting shouldn’t come as a surprise. As a reminder, please submit any “cannot live with” items by COB today, Wednesday 25 August (see https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit) Best regards, Caitlin, Berry and Marika EPDP Phase 2A - Meeting #39 Proposed Agenda Thursday 26 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Consider and resolve “cannot live with” items for section 3 of Final Report - Responses to Council Questions & Recommendations (75 minutes) – see https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit As a reminder: timeline to get to Final Report 26 August – consider “cannot live with” items identified & agree on updates to report 27 August – publish draft Final Report for EPDP Team review, consensus call. 30 August – deadline for minority statements 31 August – finalize report and address any outstanding items, if any. 2 September – submission of Final Report to GNSO Council 10 September – final deadline for minority statements (any minority statements submitted after 30 August will be added to the Final Report, with the updated version to be submitted to the Council in time for the September meeting document deadline, similar to how this was done for phase 2) * Review “cannot live with” items identified * Agree on next steps 4. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #40 Tuesday 31 August at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any

1 0

**REMINDER** Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Thursday, 26 August 2021 at 14:00 UTC
by Julie Bisland Aug. 25, 2021

Aug. 25, 2021

Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Thursday, 26 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/54MZCg * Check your time zone: https://tinyurl.com/32r8stx7 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/32r8stx7__;!!PtGJab4!qiAF_b0…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees, or Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz) before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

Notes and action items - EPDP Phase 2A Meeting #38 - 24 August 2021
by Caitlin Tubergen Aug. 24, 2021

Aug. 24, 2021

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/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…> 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-K1TPZjvNhxm8L5R0mMJ6txRWqjnM… * Zoom Recording: https://icann.zoom.us/rec/play/eyPH7HFT9OegVw9p8ZEPEMjudmmakfqRYq_d8gZYNfoV… * Zoom Chat: https://icann.zoom.us/rec/sdownload/LmRZGjRePv9Qgx8JuT1FzE3iUXrj6BLQQL75dHC… * 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-6yEaKoWjg0ZY0ToUTvgcWU1v7CD… * Zoom Recording: https://icann.zoom.us/rec/share/hVWBTT1t_E8KFZ-Y9CCJcAFD56IWJvfJ1bulrJe9Zo1… * Zoom Chat: https://icann.zoom.us/rec/sdownload/iNlcWf4qluVkvGfn2JQeL09ce3Ww5Afi_9AydQJ… · 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

1 0

For your review - final version of section 3 of the Final Report
by Marika Konings Aug. 24, 2021

Aug. 24, 2021

Dear EPDP Team, Please find attached for your review a clean and line-numbered version of section 3 of the Final Report. Please review this document and flag any “cannot live with” items of your group by Wednesday 24 August COB here: https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit. Any minor edits (or those not rising to the level of “cannot live with” items) should be added to the second table. As discussed during the call, this version includes at lines 232-241 proposed compromise language that aims to bring together the three different proposals that were put forward in relation to the guidance recommendation. If the proponents of these different proposals have concerns about this compromise language, they are encouraged to work together to put forward proposed edits that can be reviewed by the group. Similarly, some minor edits have been made to recommendation #1 (which was previously known as recommendation #3) that were shared with the small team for its consideration. In addition, other minor updates have been made for consistency and clean up (to reflect the transition to a Final Report). For those interested in seeing the redline version, please let us know off-list and we can send you a copy of the redline version. Best regards, Caitlin, Berry and Marika

2 2