May 2021 - Gnso-epdp-team - lists.icann.org

Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2A call | Thursday, 20 May 2021 at 14:00 UTC
by Terri Agnew May 18, 2021

May 18, 2021

Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2A is scheduled on Thursday, 20 May 2021 at 14:00 UTC for 90 minutes. Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 Passcode: Z@S07?t=v5 Observers are able to join via zoom webinar. 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. 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/6ISUCQ Check your time zone: https://tinyurl.com/2m7fun4f The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar/2021 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> 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!p…> Thank you. Kind regards, Terri

1 0

ICANN org Comments Re: Approach to Implementation of EPDP 2A Guidelines/Best Practices
by Brian Gutterman May 17, 2021

May 17, 2021

Dear WG Colleagues, As the EPDP Phase 2A Team finalizes its draft recommendations for public comment, we thought it might be helpful as ICANN org liaisons to the team to explain ICANN org’s thinking surrounding how the org would implement any best practices or guidelines recommended by the EPDP Team, provided these are accepted by the GNSO Council and adopted by the ICANN Board. ICANN org’s specific implementation process for any best practices or guidance developed by the EPDP team will, at least in part, depend on the specifics of the best practices or guidance. For example, if the EPDP recommendations result in a need for the implementation of a new RDDS flag or field, this may require technical implementation work and, as such, might be routed to the EPDP Phase I IRT. On the other hand, if the best practices or guidance are merely a list of practices that the contracted parties may, at their own discretion, opt to follow, ICANN org could likely simply announce these new best practices or guidance to the contracted parties and post these to the ICANN org website. ICANN Contractual Compliance enforces requirements placed on contracted parties via the RA, RAA, and ICANN Consensus Policies, in furtherance of ICANN’s mission, as recognized in the ICANN Bylaws. Guidance and best practices would exist outside these agreements and are not contractual requirements; thus, ICANN Contractual Compliance would not have contractual authority to take enforcement action against a contracted party related to its implementation of best practices or guidance, even if those best practices or guidance is developed through the EPDP Process. If the EPDP Team has specific recommendations concerning how its best practices or guidance should be implemented, ICANN org invites the EPDP Team to share its views concerning the approach to implementation of any best practices or guidance it recommends, keeping in mind the points raised above concerning the role of ICANN Contractual Compliance. Distribution of a legal notice or advisory would not appear to be needed in this situation, under the assumption that the best practices or guidance would not result in any new requirements for the contracted parties to follow. A legal notice to contracted parties would be needed if the Team’s recommendations would modify an existing Consensus Policy requirement or result in a new application of an existing policy requirement If the EPDP Team’s recommendations for best practices would require development of new technical capabilities (for example, to add a new flag or field for RDDS output), or would seek to modify existing RDDS output requirements (e.g., an update to the CL&D Policy), ICANN org recommends that the EPDP Team consider and document this in its Final Report, including Implementation Guidance where necessary. We look forward to answering any questions the WG might have on any of this and continuing this discussion as the work moves along. Regards, Brian and Amy

1 0

Proposed agenda - EPDP Phase 2A Meeting #23 - 18 May 2021
by Caitlin Tubergen May 17, 2021

May 17, 2021

Dear EPDP Team, Please find below the proposed agenda for tomorrow’s meeting. Best regards, Berry, Marika, and Caitlin -- EPDP Phase 2A - Meeting #23 Proposed Agenda Tuesday 18 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Legal vs. natural (45 minutes) 1. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); 2. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. Consensus policy question write up * Questions to be considered by the EPDP Team: 1. Some have suggested that recommendation #1 (“GNSO Council to monitor developments…”) does not seem to rise to the level of a recommendation as it is already something that the Council is expected to do. If the intent is to signal that there should be a formal process to trigger reopening deliberation on this topic, the recommendation should state so explicitly. o Should the EPDP Team consider adding a more explicit trigger that would require the Council to reopen consideration of this topic? If yes, what should this trigger be and who/how would it be determined that this trigger is met? 2. Some have indicated disagreement with the inclusion of recommendation #2 (“ICANN org must implement the capability for Contracted Parties to use a standardized data element in the registration data……”) as it is not ‘in any way necessary for the delivery of the service” nor does it “seem to serve any useful purpose to the data subject and may be doing harm by exposing additional information about the data subject”. However, as other comments noted, the EPDP Team has not considered yet if/how this additional data element would be treated (redacted / non-redacted) nor is it clear who/how such a data element could be standardized. o If the EPDP Team would agree that a standardized data element must be added, how would this work in practice? Is this an ICANN org responsibility, would it require changes to existing policy recommendations (e.g. CL&D), would this require work by other bodies, e.g. IETF? o If the EPDP Team would agree that a standardized data element must be added, what would the data element table look like for this data element (required to be transferred from Rr to Ry, redacted / non-redacted) – see phase 1 recommendations #7, 8, 9 and 10? 3. Some have expressed concern about the use of “unknown” (“that indicates whether the registration contains 1) a legal person, 2) a natural person, 3) unknown…”). Some have suggested it should be replaced by “empty” or “not-specified”, others have suggested there should only be two options, namely legal or natural person. The Staff support team had understood from previous discussions that the use of “unknown” is fairly standard and in this particular case would be helpful, for example, in the case of existing registrations for which no determination may have been made yet. o What would be the appropriate term to use for those registrations for which differentiation has not been done or for which the status is not known (e.g. in cases where differentiation is requested but has not been completed yet)? Or should the field remain blank if unfilled rather than specified as “unknown”? 4. Some have suggested that the use of “standardized data element” is vague and have suggested using “standardized mechanism” instead. However, from the discussions to date it seems that a standardized data element has been clearly understood as meaning adding a data element to RDDS (or the Registrar’s internal system) that would allow a registrar to indicate whether the registration concerns a legal / natural person and/or personal / non personal data. o Should the EPDP Team refer to “mechanism” instead? If so, how can mechanism be further described to make clear what is intended to mean and who would be responsible for developing / implementing it. * Confirm next steps - EPDP Team to review updated version of write up and flag any comments or suggested edits in the form of comments to the document by Friday 21 May. 4. Feasibility of unique contacts (30 minutes) 1. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. 2. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses. * Questions to be considered by the EPDP Team Note, in a number of instances suggestions were made by some members of the team, which others objected to. Those items have been flagged as changes not applied in the redline version – EPDP Team members are encouraged to reach out to each other to see if a compromise can be reached and communicate these back to the full team for consideration. 1. At the moment, the write up refers Contracted Parties who would like to provide a registrant-based or registration-based email address to the Bird & Bird memo. Some have suggested that more specific guidance should be included or called out. o Should more specific guidance be included, or is it sufficient to refer to the B & B memo (which will be included in full in the annex to the Initial Report)? If more specific guidance is to be included, what should this include? 1. No specific proposals have been put forward in relation to the topic of web-forms. Various approaches have been suggested during previous calls such as providing guidance to phase 1 IRT, referring this issue back to the GNSO Council for further consideration, not making any reference here but direct those that have expressed concern about web-forms to the phase 1 IRT and/or ICANN compliance from which the issue can be escalated, if necessary. o Which approach should the EPDP Team follow for the purpose of the Initial Report? o Are there any volunteers that would be willing to write up a proposal on the agreed approach on this topic for the EPDP Team to consider? * Confirm next steps – EPDP Team to review updated version of write up and flag any comments or suggested edits in the form of comments to the document by Friday 21 May. 5. Homework assignments reminder · By Friday 21 May, EPDP Team to review the updated LvN consensus question i write up for the Initial Report (https://docs.google.com/document/d/1_k0hVA6c2SvQPLiaZAlUllTKdplssofYlRHDkeR…) Please provide comments, suggestions and proposed edits in the form of comments. · By Friday 21 May, EPDP Team to review updated version of feasibility of unique contacts write up for the Initial Report (https://docs.google.com/document/d/1wpZWZzCNcDsAYuy3FqxV67POgDV2hrOvrwGa3kj…) Please provide comments, suggestions and proposed edits in the form of comments. 6. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #24 Thursday 20 May at 14.00 UTC 2. Confirm action items 3. Confirm questions for ICANN Org, if any

1 0

**REMINDER** Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2A call | Tuesday, 18 May 2021 at 14:00 UTC
by Julie Bisland May 17, 2021

May 17, 2021

Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2A is scheduled on Tuesday, 18 May 2021 at 14:00 UTC for 90 minutes. 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 Observers are able to join via zoom webinar. 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. 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/3gSlCQ Check your time zone: https://tinyurl.com/5anm6vn5 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5anm6vn5__;!!PtGJab4!vWNZJZm…> The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar/2021 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> 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!p…> Thank you. Kind regards, Terri

1 0

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

May 13, 2021

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2A call held on Thursday, 13 May 2021 at 14:00 UTC can be found on the agenda wiki page <file:///https:/community.icann.org/x/5ISUCQ> (attendance included) 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

Notes and action items - EPDP Phase 2A Meeting #22 - 13 May 2021
by Caitlin Tubergen May 13, 2021

May 13, 2021

Dear EPDP Team, Please find below the notes and action items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…> from today’s meeting. The next EPDP Phase 2A meeting will be Tuesday, 18 March at 14:00 UTC. Best regards, Berry, Marika, and Caitlin 🚨🚨🚨 Action Items 🚨🚨🚨 Please refer to the project spreadsheet<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…> for action items. EPDP Phase 2A - Meeting #22 Proposed Agenda Thursday 13 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Legal vs. natural (30 minutes) 1. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); 2. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. Guidance write up * Remaining outstanding question: From the latest version of the write up<https://docs.google.com/document/d/103kazmQlFxRmecNosslsZhg6u0MwxoZ5DiZj86j…>: “For example, differentiation at the time of registration may not be possible or practical in all circumstances, including for certain registrar business models”. And “Registrars should convey this option for Registrants to self-identify as natural or legal persons at the time of registration, or at the first opportunity after registration that the Registrar interacts with the Registrant”. * Are there any scenarios in which there is zero contact between the registrar and the registrant which would mean it would not be possible to differentiate if any of the scenarios are followed (as differentiation would happen either at the moment of registration or at the first contact opportunity between registrar and registrant)? * Not sure if this is an edge case. In some cases, it is unclear who the registrar of record is since all of the interaction took place with the registrar. Trying to avoid a situation where an obligation can be avoided by subcontracting. * One question – what are the obligations or is there a way for the obligations of a registrar to flow down to a reseller, and what is the ability to rely on the data provided to it from its reseller? * The RAA makes it very clear that obligations must be passed down, and this concept shouldn’t be lost just because we are talking about guidance here. * According to Article 16 of the GDPR, Contracted Parties will need to have a process in place to ensure data subjects can correct their information. Registrars or resellers need to be able to interact with their registrants. It doesn’t make sense for new registrations to have this happen later. Going forward, there needs to be an obligation for CPs to have contactability with their registrants, and this is in line with GDPR. * This section is guidance, but the comments from ALAC reps seem to suggest obligations and new requirements. The language is designed to offer flexibility to different business models. * If there is a reseller scenario, the ability to correct information would occur through the reseller. Not sure why this is being discussed further – the italicized text seems to cover this. * Registrars are obligated to follow the RAA and Consensus Policies – they cannot get out of this just because they work with resellers – the 2009 and 2013 RAA make this explicit. * Registrars could require their resellers to offer this option. Registrars should communicate their desire to make a distinction to their resellers. * When providing guidance to CPs, it is important to provide text on the best way to do this. Information should be given to registrants as early as possible informing them of the consequences of this designation. It’s important to include this in the guidance for the benefit of the resellers. * Suggestion to add “or at the first opportunity after registration” * The whole point of this – obligations are passed down to resellers, such as the WDRP. Many members came into this exercise with the hope of having policy recommendations come out of this. Because this is not happening, need guidance to be as clear as possible. * Registrars (or their resellers) should convey – this would guarantee an opportunity to interact with the registrant * Registrars must ensure this option to self-identify as natural or legal persons is conveyed to Registrants at the time of registration or without undue delay after registration. * Instead of Registrars or their resellers – Registrars should convey this option directly or through their resellers, - in order to take account of the business relationship and that the obligations flow downward. Strong preference for this to be at the time of registration – since the reseller does have an opportunity to convey this at the time of registration. Instead of “undue delay”, suggest putting in a particular timeframe. * Propose “Registrars must ensure this option to self-identify as natural or legal persons is conveyed to Registrants at the time of registration or without undue delay after registration.” – This would allow the registrar to convey or to have the reseller convey – this is important – it may be preferable to convey this option with the option to consent. We should allow this option. Open to requiring this within 15 days – informing the domain name registrant within 15 days. * At the time of registration, or in cases where this is not feasible, within 15 days after registration * Express concern about allowing this to happen later and to not allow registrants to convey this information at the time of registration. It’s difficult to get registrants to engage after registration – would not rely on that to meet this legal obligation to allow self-designation. * Important to listen to registrars here * If the distinction is important, this needs to be made right at the time of registration. * Do not understand the reticence to having this done at time of registration * Check boxes do not denote understanding. The purchase path within a registrar – the effect that additional steps have must be looked at from a commercially reasonable point of view. * Confirm next steps. * Support Staff to take the discussion into account and proposed edited text in the guidance document. 4. Feasibility of unique contacts (30 minutes) 1. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. 2. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses. * Review and consideration of input provided on write up – outstanding questions: · A number of comments / questions were raised in relation to the legal committee team developed definitions which were reviewed and considered by the EPDP Team. Are updates necessary in the context of the Initial Report write up? * Could consider adding across registries * Support Staff could provide explanatory text in a footnote. · A placeholder was added to consider possible guidance in relation to EPDP Phase 1 recommendation concerning expectations for web-forms. RrSG has indicated that this is not within scope for the EPDP Team while others have suggested that the recommendation #13 cannot be implemented as intended (note, Staff Support team is not aware of this being brought as an issue to the GNSO Council by the IRT). EPDP Team to consider further what, if anything, should be added to the Initial Report on this topic. * Recommendation 13 somewhat innocently says anonymized contact or webform. This text was written over 2 years ago. Web forms today do not work, and when this was written, this was not envisioned. Need to specify which IRT. If we are going to allow web form, they need to be used. Recommend updating Recommendation 13. * Have been referring to the Phase 1 IRT, which is in place to implement existing consensus policy language. There is a reference to a web form and contactability. If there is more work that needs to be done on the functionality of a web form, this is a topic for the Phase 1 IRT. This issue has not been raised within the IRT. * Does the IRT have the authority to specify rules for web forms – this seems like a real far push. * This issue will be raised in the Phase 1 IRT. If we do not have a unique email address that enables contact to a registrant, then what we should come to consensus on are some minimum requirements for web forms. * Web forms are creating an avenue for abuse. It’s important that registrars have the flexibility with implementing this web form to prevent abuse. * The Team does not have enough time to discuss the unique contacts since 80% of time has been taken up by legal v. natural. This should be captured at the beginning of the report. * Thus far, there were no specific proposals put forward by the group on this topic. * If CPs are willing to follow rules from an IRT, it is not sufficient to toss it back to Phase 1 that cannot make any rules. Concrete suggestions: there are two relevant recs in Phase 1 – recs. 6 and 13. Therefore it is within our scope. * IRT Phase 1 keeps coming back – this is a slippery slope that an IRT is creating policy. IRTs and policy development have different functions. * Contacting a registrant is useful – useful to resolve issues without having to go to outside council. In terms of the scope of Phase 2A, we are talking about contactability – if it is not working as is in the current environment, looking for meaningful requirements in terms of contactability. * If there are challenges within ongoing implementation, this is an issue for ICANN compliance and the Phase 1 IRT. * The group’s charter is to look at anonymized and pseudonymized is feasible. We cannot ignore that the webforms are not working; we should not be limited. * A simple email forwarder would do the job – there is no need for a scrambled email address. Having trouble understanding why there is a web form/anonymized email address when there could be an email forwarder. * Thought the group agreed that anonymized email was feasible and we were looking at different levels or risk for the types of emails. * Confirm next steps – EPDP Team to review updated version of write up and flag any comments or suggested edits in the form of comments to the document by Friday 14 May. 5. Homework assignments reminder (5 minutes) · By Friday 14 May, EPDP Team to review proposed LvN question i write up for the Initial Report (https://docs.google.com/document/d/1CBKYrgEOwxpLtZJbck4XMAnJcqEdOS6ObiSHio6…) Please provide comments, suggestions and proposed edits in the form of comments. · By Friday 14 May, EPDP Team to review updated version of feasibility of unique contacts write up for the Initial Report (https://docs.google.com/document/d/1Dl-71SsX_OqDNpvN-rQ9K_wJnevEVW0V0oH32xY…) Please provide comments, suggestions and proposed edits in the form of comments. 6. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #23 Tuesday 18 May at 14.00 UTC 2. Confirm action items 3. Confirm questions for ICANN Org, if any

1 0

Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2A call | Tuesday, 18 May 2021 at 14:00 UTC
by Terri Agnew May 13, 2021

May 13, 2021

Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2A is scheduled on Tuesday, 18 May 2021 at 14:00 UTC for 90 minutes. Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 Passcode: Z@S07?t=v5 Observers are able to join via zoom webinar. 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. 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/3gSlCQ Check your time zone: https://tinyurl.com/5anm6vn5 The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar/2021 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> 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!p…> Thank you. Kind regards, Terri

1 0

**REMINDER** Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2A call | Thursday, 13 May 2021 at 14:00 UTC
by Julie Bisland May 12, 2021

May 12, 2021

Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2A is scheduled on Thursday, 13 May 2021 at 14:00 UTC for 90 minutes. 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 Observers are able to join via zoom webinar. 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. 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/5ISUCQ Check your time zone: https://tinyurl.com/3e556997 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/3e556997__;!!PtGJab4!o9eURkq…> The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar/2021 [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…> 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!p…> Thank you. Kind regards, Terri

1 0

Proposed Agenda - EPDP Phase 2A - Meeting #22 - Thursday 13 May 2021 at 14.00 UTC
by Caitlin Tubergen May 11, 2021

May 11, 2021

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Phase 2A meeting on Thursday, 13 May at 14:00 UTC. Best regards, Berry, Marika, and Caitlin -- EPDP Phase 2A - Meeting #22 Proposed Agenda Thursday 13 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Legal vs. natural (30 minutes) 1. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); 2. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. Guidance write up * Remaining outstanding question: From the latest version of the write up<https://docs.google.com/document/d/103kazmQlFxRmecNosslsZhg6u0MwxoZ5DiZj86j…>: “For example, differentiation at the time of registration may not be possible or practical in all circumstances, including for certain registrar business models”. And “Registrars should convey this option for Registrants to self-identify as natural or legal persons at the time of registration, or at the first opportunity after registration that the Registrar interacts with the Registrant”. * Are there any scenarios in which there is zero contact between the registrar and the registrant which would mean it would not be possible to differentiate if any of the scenarios are followed (as differentiation would happen either at the moment of registration or at the first contact opportunity between registrar and registrant)? * Confirm next steps. 4. Feasibility of unique contacts (30 minutes) 1. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. 2. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses. * Review and consideration of input provided on write up – outstanding questions: · A number of comments / questions were raised in relation to the legal committee team developed definitions which were reviewed and considered by the EPDP Team. Are updates necessary in the context of the Initial Report write up? · A placeholder was added to consider possible guidance in relation to EPDP Phase 1 recommendation concerning expectations for web-forms. RrSG has indicated that this is not within scope for the EPDP Team while others have suggested that the recommendation #13 cannot be implemented as intended (note, Staff Support team is not aware of this being brought as an issue to the GNSO Council by the IRT). EPDP Team to consider further what, if anything, should be added to the Initial Report on this topic. * Confirm next steps – EPDP Team to review updated version of write up and flag any comments or suggested edits in the form of comments to the document by Friday 14 May. 5. Homework assignments reminder (5 minutes) · By Friday 14 May, EPDP Team to review proposed LvN question i write up for the Initial Report (https://docs.google.com/document/d/1CBKYrgEOwxpLtZJbck4XMAnJcqEdOS6ObiSHio6…) Please provide comments, suggestions and proposed edits in the form of comments. · By Friday 14 May, EPDP Team to review updated version of feasibility of unique contacts write up for the Initial Report (https://docs.google.com/document/d/1Dl-71SsX_OqDNpvN-rQ9K_wJnevEVW0V0oH32xY…) Please provide comments, suggestions and proposed edits in the form of comments. 6. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #23 Tuesday 18 May at 14.00 UTC 2. Confirm action items 3. Confirm questions for ICANN Org, if any

1 0

Notes and action items - EPDP Phase 2A Meeting #21 - 11 May 2021
by Caitlin Tubergen May 11, 2021

May 11, 2021

Dear EPDP Team, Please find below the notes and action items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…> from today’s meeting. Best regards, Berry, Marika, and Caitlin -- 🚨 Action Items 🚨 Please refer to the project spreadsheet<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…> for action items. EPDP Phase 2A - Meeting #21 Proposed Agenda Tuesday 11 May 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Legal vs. natural (30 minutes) 1. Whether any updates are required to the EPDP Phase 1 recommendation on this topic (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so“); 2. What guidance, if any, can be provided to Registrars and/or Registries who differentiate between registrations of legal and natural persons. Question i – Whether any updates are required to the EPDP Phase 1 recommendation on this topic * Walk through of staff proposed write up of Initial Report text * Want to make sure there is clarity about internal registrar flagging function OR whether the expectation is the flag should be displayed in the output * Maybe the hang up is whether it is a global flag. For every query, the registrar could say “the flag is not set”. With respect to the wording about where SSAD appears, would like to lay a path where we separate the concepts we are talking about from the SSAD implementation. SSAD is just one way to implement differentiated access. The recommendation would be stronger if SSAD is not referenced. * EPDP Phase 2A is a follow on from Phase 1 and 2, so there is an expectation that the group is basing its work on the SSAD, so do not think the reference to SSAD as an element that retrigger the group’s work should be removed. Perhaps consider adding text like “or alternative differentiated access model”. * Registrars implement all sorts of flags – autorenewal, privacy/proxy service – ICANN has nothing to do with what registrars do internally. The language on the screen implies we are talking about new fields in the RDDS, which is what is needed for differentiation of legal/natural. We should use the same language for Phase 1 – Phase 1 had five recommendations (5-10) that detail specific things about registration data. If we are specifying a new RDDS field here, we need to specify all of the details that were specified for Phase 1. * As many members know, the NIS2 proposals seem to be getting stricter and require more of the CPs if the proposals are adopted. The community should think hard about what will happen when the NIS2 is adopted – another EPDP or pause of Phase 2? Team may need to update these requirements. * The language references some EPDP members are of the view that EPDP Phase 1 should be maintained for controller flexibility – in the face of privacy legislation that is changing and evolving across many jurisdictions, it is difficult to write future-proof policy that can take all situations into account. The current language (allowed but not required) provides necessary flexibility. * With respect to the flag language, this is confusing. In Phase 1, there is a recommendation regarding registrars providing registrants the ability to provide consent to publish – this may be a flag of some sort, but there is not detailed language around a flag. It is up to the registrar how this is captured, but per the requirements, they would need to offer and capture that choice. In terms of publishing this, it doesn’t make sense that the flag would be indicated in the RDDS output. How would this flag apply on the legal natural differentiation, and how would this be published? This may not be a best practice. * The recommendation doesn’t appear different than what the GNSO Council should be doing anyway. It may be worth considering previous points of what would happen – Phase 2B? New EPDP? There is additional work that is required for this recommendation. * The EPDP came about because the policy was at odds with the law. NIS2 is its current state does not require a policy change. Strongly disagree with phrasing in recommendation 1 – it can be answered without the additional language. * There is more convergence at an international level – the GDPR and developments in Europe are being looked at by everyone and are guiding other jurisdictions. Important to note that the place where the privacy laws were developed make a clear distinction between legal and natural data. It is important for this group to not lose sight of where we are coming from – maintaining Whois to the greatest extent possible while complying with the GDPR. * The scope of the GDPR is clear – it applies to natural persons, but what is unclear is a definition of legal persons. Recommendation 2 is confusing – CPs have a duty to ensure their documentation of the consent of a natural person is clearly recorded. Telling people that they have to have a flag solely for the benefit of third parties is ridiculous. Suggest removing the language regarding a flag. * Somewhere in this document it explains the contents of this flag could be “unknown” – don’t agree with this; it should be empty instead of unknown. Flexibility is good, and while the wording needs to be updated, nothing changes since this is an optional field. NIS2, even in the current versions, will not likely require policy, but that is why this field in the RDDS is necessary. * The guidance should be as flexible as possible. * Remind the group that as we started this process the goal was to stay as close to the old Whois system as much as possible so long as it’s compliant with GDPR. There is a recognized benefit in having the information publicly accessible and widely shared so long as it’s compliant with law. * The group seems to repeat the same arguments over and over again. There has not been a single valid reason why redacted information that is not protected under any law is redacted. From a technical feasibility perspective, having the capacity for flags involves no risk and is line with the guidance from contracted parties that wish to differentiate. With respect to Point 2, suggest deleting “unknown” because it may create more problems than it solves. This could lead to bad faith registrants abusing the system. * There are two different interpretations over what the GDPR protects – this discussion has been had many times. Distinctions can be made without flags – why should a flag be chosen over all others? * Contracted parties do not need a policy to tell them to follow the law. When a new law comes out, do not need to wait for a policy to explain or require CPs to follow the law. * Having no policy at all – what is the purpose of having a multi-stakeholder policy development process – why can’t we be forward looking, anticipate new laws, etc. * The text will be circulated via a link and get feedback by Friday, 14 May. Please provide suggested edits (in comment form) with an eye toward reaching consensus. The capability to differentiate is a worthwhile goal; the flag may be a bit of a distraction, and the group may not be able to agree to the specifics. Focus on the high-level policy goal rather than focusing on being overly prescriptive. * Confirm next steps – proposed deadline for comments / suggestions / proposed edits Friday 14 May 2021 Guidance write up * Brief overview of main changes applied. * The Staff Support Team reviewed all input received on the LvN guidance. In addition to identifying cannot live with items, there were many additional comments and suggestions made by EPDP Team members. In the second version that you can find in the google doc<https://docs.google.com/document/d/103kazmQlFxRmecNosslsZhg6u0MwxoZ5DiZj86j…>, you can see all the updates that we made and responses to the comments. * A number of comments were received in relation to the concept of the flag or a defined data element – these have not been applied here as this approach is expected to be further considered in the context of the write up in response to the consensus policy question. * The Registrar Team provided feedback that a number of GDPR principles from the table were not sufficiently highlighted in the write up. The Staff Support Team called these out in the background information section to make clear that in addition to the guidance there may be other principles that Registrars need to factor in when dealing with personal information. * A number of comments / questions were made in relation to instances where differentiation may not be possible at the time of registration. This has been discussed previously, but we have called it out as a separate question for discussion so that we can attempt to resolve this topic to everyone’s satisfaction. * We’ve moved the disclaimer language to the beginning of the guidance section instead of the end as there were suggestions to add new disclaimer language. In order to avoid duplication, we’ve suggested moving the language that was already in the document up to the top of the guidance section. * There were a number of clarifying edits that have been suggested. The staff support team has applied those that did not seem to change the intent of the language and where no objections were noted. In some cases where there were opposing views, we may have suggested an alternative approach. * A number of respondents pointed out that the registrant may not be the data subject in all circumstances – reminder that a footnote had already been added to the previous version to make this clear. * We also applied the updates that were agreed to during the last meeting (i.e. adding a reference to a possible timeframe for scenario 2 and removing the reference to third party verification). * There were a number of comments that did not come with any suggested changes or proposed language – for future input, please make sure that you are specific about the changes you are proposing. There were also some comments that did not seem to belong in the guidance write up or were not in line with what has been discussed to date – in our responses we have noted as such. * The idea would be to leave the write up as is for now to allow the group to focus on the consensus policy write up. The hope is that in the next review cycle, the team can consider clarifications, consistency, and “cannot live with” items, and that all other comments have been exhausted by now. * There also seemed to be a suggestion that the guidance write up was trying to restrict differentiation to SSAD but that is not our understanding – it is indeed a suggestion that some have made, but the guidance write up indicates various avenues through which this may happen, including SSAD. * Please go to the google doc<https://docs.google.com/document/d/103kazmQlFxRmecNosslsZhg6u0MwxoZ5DiZj86j…> where you can first find a clean version with all changes applied and secondly a staff support team edited version with the redline changes and our response to the different comments that explain which changes have been applied and why some suggestions were not applied. * Remaining outstanding questions: * Should this be labelled guidance, best practices or something else? Note that the GNSO Operating Procedures refer to “Best Practices” as an illustrative type of outcome but do not specifically mention guidance. At the same time, maybe the EPDP Team should focus on what its expectations are once the GNSO Council / ICANN Board adopt this guidance or best practice? What is expected from ICANN org? Is anything expected from other parties such as the GNSO Council and/or RrSG in relation to promotion and communication of this guidance? * In terms of expectations – the expectation would be that ICANN org communicates this and makes sure this is publicized in a way that affected contracted parties know that this guidance/best practices exist, otherwise – what is the purpose? This should be communicated and enshrined it in a place that is easily accessible. “Best practices” is a term that carries more heft and weight, and the fact that it is consistent with the term the Council uses is another mark in its favor. * The term best practices carries more weight so that should be used, and is far more likely to have something to come out of this. * On both of these topics, CPs have been discussing this and have not come to agreement yet on the preference. The guidance we developed is possible guidance, but are they are the best? Who decides this? * If not us to determine best practices, then who? * This should be useful – should be something that CPs can use if they want to differentiate that gives them some instruction of how to achieve this. This should be a living document – it is not policy but could be provided in the broader term of guidance for contracted parties. * Best practices is the right term to use in terms of the by-laws – stay away from term guidance, which has a different meaning under the bylaws. * In response to who determines best practices – it is the EPDB under Article 36. * Perhaps should be thinking of this in terms of what we would like to achieve in terms of communication, dissemination, uptake, etc. rather than terminology. Guidance seems more like a policy threshold; best practices sounds more like an implementation. * DNS abuse institute mission is to develop best practices – the term is not as radioactive as the group seems to feel. * Are there any scenarios in which there is zero contact between the registrar and the registrant which would mean it would not be possible to differentiate if any of the scenarios are followed (as differentiation would happen either at the moment of registration or at the first contact opportunity between registrar and registrant)? * Proposed next steps – consider latest version of write up (apart from updates in response to previous two questions) as near final state and focus attention now on write up in response to question i. Once that review has been completed, EPDP Team to undertake final review and identification of “cannot live with” items. 4. Feasibility of unique contacts (30 minutes) 1. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. 2. If feasible, but not a requirement, what guidance, if any, can be provided to Contracted Parties who may want to implement uniform anonymized email addresses. * Review and consideration of input provided on write up – outstanding questions: · A number of comments / questions were raised in relation to the legal committee team developed definitions which were reviewed and considered by the EPDP Team. Are updates necessary in the context of the Initial Report write up? · A placeholder was added to consider possible guidance in relation to EPDP Phase 1 recommendation concerning expectations for web-forms. RrSG has indicated that this is not within scope for the EPDP Team while others have suggested that the recommendation #13 cannot be implemented as intended (note, Staff Support team is not aware of this being brought as an issue to the GNSO Council by the IRT). EPDP Team to consider further what, if anything, should be added to the Initial Report on this topic. * Confirm next steps – EPDP Team to review updated version of write up and flag any comments or suggested edits in the form of comments to the document by Friday 14 May. 5. Homework assignments reminder (5 minutes) · By Friday 14 May, EPDP Team to review proposed LvN question i write up for the Initial Report (https://docs.google.com/document/d/1CBKYrgEOwxpLtZJbck4XMAnJcqEdOS6ObiSHio6…) Please provide comments, suggestions and proposed edits in the form of comments. · By Friday 14 May, EPDP Team to review updated version of feasibility of unique contacts write up for the Initial Report (https://docs.google.com/document/d/1Dl-71SsX_OqDNpvN-rQ9K_wJnevEVW0V0oH32xY…) Please provide comments, suggestions and proposed edits in the form of comments. 6. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #22 Thursday 13 May at 14.00 UTC 2. Confirm action items 1. Confirm questions for ICANN Org, if any

1 0