April 2021 - Gnso-epdp-team

Re: [Gnso-epdp-team] Proposed EPDP Team Phase 2A Meeting Agenda - Tuesday 27 April at 14.00 UTC
by Marika Konings 26 Apr '21

26 Apr '21

In preparation for tomorrow’s meeting, the staff support team has pulled out all the different comments and suggestions received by the deadline and organized them in the attached table to facilitate review and discussion during tomorrow’s meeting. Please have this document at hand for the meeting. 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: Monday, 26 April 2021 at 07:41 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed EPDP Team Phase 2A Meeting Agenda - Tuesday 27 April at 14.00 UTC Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team Phase 2A meeting which is scheduled for Tuesday 27 April at 14.00 UTC. Best regards, Caitlin, Berry and Marika EPDP Phase 2A - Meeting #17 Proposed Agenda Tuesday 27 April 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) * Next steps – reminder of proposed next steps as outlined here https://mm.icann.org/pipermail/gnso-epdp-team/2021-April/003861.html 3. Legal vs. natural (60 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 development a. Consider new issues flagged in latest version of the write up<https://docs.google.com/document/d/1a7MEle3_e-iXbaiZQV5wCD4Pv0414YjLtC2yxJE…>: * Any concern about moving “Distinguishing between legal and natural person data alone may not be dispositive, as the data provided by legal persons may include personal data that is protected under data protection law, such as GDPR” to the guidance section? * See 1d – what approach should be taken when a Registrant makes substantive changes to registration data? * Consider whether it would be helpful to add a timeline to scenario 2. * Consider whether scenario 3 should remain. * Definition of “publish” (note, the write up currently includes the following definition “EPDP-p1-IRT: “Publication”, “Publish”, and “Published” means to provide Registration Data in the publicly accessible Registration Data Directory Services.”) * Any other issues flagged by deadline (Monday 26 April at 18.00 UTC) b. Confirm next steps to finalize write up for inclusion in the Initial Report 4. Reminder of Homework assignments (5 minutes) · Thursday’s EPDP Team meeting will focus on the question of whether any changes are warranted to the EPDP Phase 1 recommendation (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so”). Please come prepared to present your groups responses to the questions in the google doc (see https://docs.google.com/document/d/1gMV29jRPQEFGv2psZ2py2_F8cr93OeeA/edit). Please try to focus your interventions on the specific questions that were asked and come prepared to put forward specific (ideally textual) suggestions for how the group can develop a response to the charter question. · By Friday 30 April<x-apple-data-detectors://5>, please put forward your group’s proposed response to the feasibility of unique contacts questions (i. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. ii. 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). Please note here that we have been given specific advice from B&B with a risk continuum, so we will work within that, and we will not entertain discussions seeking to obviate risk altogether. The staff support team has set up a google doc to provide your suggestions (see https://docs.google.com/document/d/1lqLOkF1jaA2NK1hmYtG4jiY4x7V432maFh1Xlv5…). Based on the input received, leadership with the support of the staff support team will aim to develop proposed draft language for inclusion in the Initial Report. 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #18 Thursday 29 April at 14.00 UTC 2. Confirm action items 1. Confirm questions for ICANN Org, if any

1 0

Proposed EPDP Team Phase 2A Meeting Agenda - Tuesday 27 April at 14.00 UTC
by Marika Konings 26 Apr '21

26 Apr '21

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team Phase 2A meeting which is scheduled for Tuesday 27 April at 14.00 UTC. Best regards, Caitlin, Berry and Marika EPDP Phase 2A - Meeting #17 Proposed Agenda Tuesday 27 April 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) * Next steps – reminder of proposed next steps as outlined here https://mm.icann.org/pipermail/gnso-epdp-team/2021-April/003861.html 3. Legal vs. natural (60 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 development a. Consider new issues flagged in latest version of the write up<https://docs.google.com/document/d/1a7MEle3_e-iXbaiZQV5wCD4Pv0414YjLtC2yxJE…>: * Any concern about moving “Distinguishing between legal and natural person data alone may not be dispositive, as the data provided by legal persons may include personal data that is protected under data protection law, such as GDPR” to the guidance section? * See 1d – what approach should be taken when a Registrant makes substantive changes to registration data? * Consider whether it would be helpful to add a timeline to scenario 2. * Consider whether scenario 3 should remain. * Definition of “publish” (note, the write up currently includes the following definition “EPDP-p1-IRT: “Publication”, “Publish”, and “Published” means to provide Registration Data in the publicly accessible Registration Data Directory Services.”) * Any other issues flagged by deadline (Monday 26 April at 18.00 UTC) b. Confirm next steps to finalize write up for inclusion in the Initial Report 4. Reminder of Homework assignments (5 minutes) · Thursday’s EPDP Team meeting will focus on the question of whether any changes are warranted to the EPDP Phase 1 recommendation (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so”). Please come prepared to present your groups responses to the questions in the google doc (see https://docs.google.com/document/d/1gMV29jRPQEFGv2psZ2py2_F8cr93OeeA/edit). Please try to focus your interventions on the specific questions that were asked and come prepared to put forward specific (ideally textual) suggestions for how the group can develop a response to the charter question. · By Friday 30 April<x-apple-data-detectors://5>, please put forward your group’s proposed response to the feasibility of unique contacts questions (i. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. ii. 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). Please note here that we have been given specific advice from B&B with a risk continuum, so we will work within that, and we will not entertain discussions seeking to obviate risk altogether. The staff support team has set up a google doc to provide your suggestions (see https://docs.google.com/document/d/1lqLOkF1jaA2NK1hmYtG4jiY4x7V432maFh1Xlv5…). Based on the input received, leadership with the support of the staff support team will aim to develop proposed draft language for inclusion in the Initial Report. 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #18 Thursday 29 April at 14.00 UTC 2. Confirm action items 1. Confirm questions for ICANN Org, if any

1 0

REMINDER -- Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2A call | Tuesday, 27 April 2021 at 14:00 UTC
by Julie Bisland 26 Apr '21

26 Apr '21

Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2A is scheduled on Tuesday, 27 April 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 Going forward, observers will now 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/1ASlCQ Check your time zone: https://tinyurl.com/2r937rs3 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2r937rs3__;!!PtGJab4!oRd5Cli…> 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

Re: [Gnso-epdp-team] SSAD as a means of publishing non-personal data
by Alan Greenberg 24 Apr '21

24 Apr '21

At 2021-04-22 09:10 AM, Volker Greimann wrote: >1. SSAD was approved by the PDPD consensus, by the GNSO council with >sufficient votes and by the board. It will exist. If it does not, we >will be forced back to the drawing board for another couple of years >and the status quo will persist. If you prefer that over SSAD, go >ahead and kill SSAD. This is not about my trying to kill the SSAD. At this point, the Board needs to make a decision, and presumably it will not just blindly rubber-stamp the GNSO recommendations. And iyou are not addressing proposing a solution that is at best several years out to >2. This would be questions for the implementation phase, but maybe >some guidance would be helpful to put people here at ease. I do not >think there needs to be authentication for basic SSAD access. The >terms currently in place for domain name registration are fully >sufficient for that access level: Validation of format of the data, >verification of email address, valid payment method. This would be >my personal view. > >3. As this access level would require significantly lower barriers >than full access, fees for this type of requests could be lower as >well. For comparison, requests for data from the German trade >register cost medium one-digit EUR amounts per request. The added >benefit is that this common type of request could carry a base cost >load for the system, allowing lower overall costs for all requests. >Only leaving SSAD for personal data would on the other hand drive up >costs. The more we include in SSAD, the better the price structure should be. OK, so you are proposing a fee-based system for such requests. >4. If we do need another PDP (not convinced that we do) this could >be pre-determined and targeted. If we all agree now that we want >this to happen, debate the specifics before the PDP is launched, the >time needed for the actual PDP could be minimal. Fine. Adding several more years... >5. To the contrary, there are a myrad of advantages: Use of existing >infrastructure, lower overall SSAD fees, better protection of >registrants, access controls, prevention of harvesting for illicit >purposes (SPAM, phishing, etc) , requestor ID, reduced risk for CPs, >no need to build out yet another system for a sub-category of domain >names, no data transfer liability issues, etc. The list goes on and on... > >-- >Volker A. Greimann >General Counsel and Policy Manager >KEY-SYSTEMS GMBH > >T: +49 6894 9396901 >M: +49 6894 9396851 >F: +49 6894 9396851 >W: <http://www.key-systems.net/>www.key-systems.net > >Key-Systems GmbH is a company registered at the local court of >Saarbruecken, Germany with the registration no. HR B 18835 >CEO: Oliver Fries and Robert Birkner > >Part of the CentralNic Group PLC (LON: CNIC) a company registered in >England and Wales with company number 8576358. > >This email and any files transmitted are confidential and intended >only for the person(s) directly addressed. If you are not the >intended recipient, any use, copying, transmission, distribution, or >other forms of dissemination is strictly prohibited. If you have >received this email in error, please notify the sender immediately >and permanently delete this email with any files that may be attached. > > >On Thu, Apr 22, 2021 at 8:02 AM Alan Greenberg via Gnso-epdp-team ><<mailto:gnso-epdp-team@icann.org>gnso-epdp-team(a)icann.org> wrote: >There continues to be discussion regarding using the SSAD as a means >of "publishing" non-personal data. > >I believe that this discussion is a distraction that takes focus from >what we should be working on. I say this for the following reason. > >1. The SSAD does not exist, it may never exist, and if the Board does >approve it, it will likely take several years to implement (remember >we are 2 years into the implementation of Phase 1, and there is no >centralized hardware/software to design and implement for that). > >2. Although we specified that anyone may be accredited, it is not at >all clear the amount of time it will take, nor what fee might be >charged. And unless the system allows accreditation without >authenticating the identity, this precludes anonymous queries. > >3. We specified that the SSAD must be self-funding and that the users >must pay for its operating costs. Are those in favour of using the >SSAD for public data publishing proposing fees for such requests, or >no fees, and if the latter, who will pay for this usage? > >4. There are multiple details of Phase 2 Recommendation 8 for >Contracted Party Authorization that simply make no sense in this >case, yet are part of the approved policy. And changing that policy >requires a PDP. > >5. There does not seem to be any benefit of routing public-data >requests through the SSAD with its myriad rules, regulations and >processes when a vanilla RDAP server will suffice. > >Alan > >_______________________________________________ >Gnso-epdp-team mailing list ><mailto:Gnso-epdp-team@icann.org>Gnso-epdp-team(a)icann.org >https://mm.icann.org/mailman/listinfo/gnso-epdp-team >_______________________________________________ >By submitting your personal data, you consent to the processing of >your personal data for purposes of subscribing to this mailing list >accordance with the ICANN Privacy Policy >(<https://www.icann.org/privacy/policy>https://www.icann.org/privacy/policy) >and the website Terms of Service >(<https://www.icann.org/privacy/tos>https://www.icann.org/privacy/tos). >You can visit the Mailman link above to change your membership >status or configuration, including unsubscribing, setting >digest-style delivery or disabling delivery altogether (e.g., for a >vacation), and so on.

4 10

EPDP Team: Next Steps
by Drazek, Keith 23 Apr '21

23 Apr '21

Dear EPDP Team, I want to thank you again for all your contributions on the mailing list and yesterday’s call. As several of you noted, it is important to remain constructive in these deliberations, to listen to each other, and to appreciate the different perspectives that exist on these topics. Having said this, it is important that the group starts shifting its focus to the expected deliverable, which is the publication of an Initial Report that addresses the questions that were posed by the GNSO Council. In light of this, I would like to put forward the following suggestions and observations: 1. When you send a response on the mailing list, please include how this is expected to be reflected in the response that will go into the Initial Report – with specific language suggestions if possible. As you know, for the legal/natural question there is a proposed guidance write-up that includes most of the aspects that have been mentioned during the call and on the mailing list – please look at that write-up and make clear in your interventions what your group thinks is missing and/or what specific (textual) suggestions your group has for changes. 2. Some have suggested that the focus should be on differentiating between personal and non-personal data instead of legal and natural person data. I would like to point out that the question the group has been asked is about differentiation between legal and natural person data, which is also reflected in the EPDP Phase 1 recommendation. Should a Contracted Party prefer to focus on differentiating between personal and non-personal data, as far as I am aware, nothing would prevent a Contracted Party from doing so but it is more granular than, and therefore not the specific question that we are expected to address. As a result, I would like to ask everyone to focus on the question of differentiation of legal and natural person data, which per the proposed guidance, would follow a two-step approach which could also then include consideration of whether legal person data includes personal data. 3. Substantial discussion has taken place in relation to what “publication” means. Please note that the write-up includes the definition that is used in the context of the EPDP Phase 1 implementation (“Publication”, “Publish”, and “Published” means to provide Registration Data in the publicly accessible Registration Data Directory Services”). A specific proposal was made to consider publication in the context of SSAD and although several have expressed support for such an approach, we also need to recognize that the SSAD has not been approved yet by the ICANN Board and as such it is not clear whether this will be a viable approach. At the same time, Contracted Parties are already permitted to differentiate so providing guidance on how this can be done in the current circumstances (i.e., without an SSAD) is important. This does not mean that the EPDP Team cannot provide guidance (or possibly a conditional requirement which would enter into force upon implementation of SSAD) for how differentiation could look in the future (which could even be tied to a triggering event, e.g., NIS2). 4. The EPDP Team is a representative group – you have all been appointed by your respective groups to represent them in this effort. As a result, any proposals and interventions you make are expected to be on behalf of your group. We understand that this requires significant coordination which is not always possible in real-time but it is important that we do not find ourselves in a situation where a specific proposal or suggestion is debated to then find that other members of the same group do not stand behind the proposal or suggestion. Having said this, and hoping that you can support my suggestions and observations, looking ahead at next week’s meetings I would like to propose the following: * Tuesday’s EPDP Team meeting will focus on the latest version<https://docs.google.com/document/d/1a7MEle3_e-iXbaiZQV5wCD4Pv0414YjLtC2yxJE…> of the write-up. Please review the latest version and identify any issues that require further discussion by Monday 26 April at 18.00 UTC<x-apple-data-detectors://2> at the latest, beyond those that were already identified: 1. Definition of “publish” (note, the write up currently includes the following definition “EPDP-p1-IRT: “Publication”, “Publish”, and “Published” means to provide Registration Data in the publicly accessible Registration Data Directory Services.”) 2. Any concern about moving “Distinguishing between legal and natural person data alone may not be dispositive, as the data provided by legal persons may include personal data that is protected under data protection law, such as GDPR” to the guidance section? 3. See 1d – what approach should be taken when a Registrant makes substantive changes to registration data? 4. Consider whether it would be helpful to add a timeline to scenario 2. 5. Consider whether scenario 3 should remain and/or be adjusted. Note that in addition to the issues that are flagged in the document, the Registrar Team has added a number of suggestions. If you are of the view that any of those require further discussion, please flag these so that these can be added to the list. * Thursday’s EPDP Team meeting will focus on the question of whether any changes are warranted to the EPDP Phase 1 recommendation (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so”). Please come prepared to present your groups responses to the questions in the google doc (see https://docs.google.com/document/d/1gMV29jRPQEFGv2psZ2py2_F8cr93OeeA/edit). Please try to focus your interventions on the specific questions that were asked and come prepared to put forward specific (ideally textual) suggestions for how the group can develop a response to the charter question. * By Friday 30 April<x-apple-data-detectors://5>, please put forward your group’s proposed response to the feasibility of unique contacts questions (i. Whether or not unique contacts to have a uniform anonymized email address is feasible, and if feasible, whether it should be a requirement. ii. 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). Please note here that we have been given specific advice from B&B with a risk continuum, so we will work within that, and we will not entertain discussions seeking to obviate risk altogether. The staff support team has set up a google doc to provide your suggestions (see https://docs.google.com/document/d/1lqLOkF1jaA2NK1hmYtG4jiY4x7V432maFh1Xlv5…). Based on the input received, leadership with the support of the staff support team will aim to develop proposed draft language for inclusion in the Initial Report. I appreciate that we are asking a lot, but we are hoping by focusing your energy on the end goal, we will be able to be more productive and effective in our deliberations, working towards the goal of publishing an Initial Report for public comment by the end of May. Best regards, Keith

1 0

Notes from EPDP Phase 2a Meeting #16 - 22 April 2021
by Caitlin Tubergen 22 Apr '21

22 Apr '21

Dear EPDP Team, Please find below the notes from today’s EPDP Team meeting. The Staff Support Team will circulate the action items separately. As a reminder, the next EPDP Team meeting will take place on Tuesday, 27 April at 14:00 UTC. Best regards, Berry, Marika, and Caitlin -- EPDP Phase 2A - Meeting #16 Proposed Agenda Thursday 22 April 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) * Thank you to all Team members who continue to contribute to the working documents. The engagement level is high, and that is helpful. * As we enter the last five weeks of our work to develop the Initial Report, please remember to be constructive. Differences of opinion may become more crystallized, but please remember to be respectful and constructive. * Update from the legal committee – outstanding question * Still awaiting an answer to Question 3, which is the question regarding the manner in which EURID, ARIN, and RIPE are implementing GDPR. 3. 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. a. EPDP Team to consider responses provided by Bird & Bird (see here<https://community.icann.org/download/attachments/155191493/ICANN%20-%20EPDP…>) as well as definitions<https://mm.icann.org/pipermail/gnso-epdp-team/2021-February/003693.html> developed by legal committee · Intro to memo and definitions developed by legal committee (Becky) * The memo from Bird & Bird confirms its previous guidance that a registrant-based contact and registrar-based contact involve the processing of personal data since the intent is to contact the individual. However, both of the uses provide privacy-enhancing technology. The memo provides a grid based on risk. In short, registrant-based email contact for web publication involves medium risk. The registration-based email contact with web publication is probably low risk. Automated disclosure for a registrant-based email is the lowest risk, but none of these approaches are without risk. · EPDP Team to consider what new insights, if any, are provided that will facilitate a response to the question whether or not unique contacts to have a uniform anonymized email address is feasible. * There are at least two different issues that are conflated with uniform email addresses and pseudonyms – one is the service to the registrant, and the other is correlation for third parties. These are separate issues and tend to get conflated. The short answer to the question is that it is not feasible. It is not feasible to do this against the wishes of the registrant. For the basic idea of how to contact a registrant without implicating the identity is to have a forwarding process through the registrar. * In terms of the utility of web forms, that is an ICANN compliance or Phase 1 IRT issue and should not be discussed in this forum. * Agree that this is not feasible. Uniform has issues that cannot be resolved in a way that is privacy-friendly. * Support automated disclosure of a registration-based contact, as the memo notes that this is the lowest risk and carries with it the highest amount of confidence that it cannot be abused. This would also improve the functionality of SSAD. * Understand the preference for the lowest risk; however, also need to consider how to bring the risk assessment in line with other long-existing policies based on the legitimate interest of Internet users. For example, with respect to the UDRP, there is a possibility to show a pattern of bad faith registrations. If we opt for the lowest risk, we may be, de facto, revising the UDRP, and this group is not chartered to do this. * The idea of trying to correlate is distinct and separate from whether you can contact the registrant. In order to facilitate correlation, you need to have access to non-public information. * In this group, we are tasked to ensure that the policy enables us to perform relevant use cases in the ICANN policy space. In short, looking to get a list of domain names registered by a particular registration in order to substantiate a claim of bad faith under the UDRP – a list of domain names, alone, is not personally-identifiable information and this should be allowed. * In terms of correlating bad faith for UDRP cases, this was never an issue before the Temp Spec. Reverse WHOIS search was never a function of WHOIS, this was a third-party service. Complainants can look at previous UDRP decisions for indicia of bad faith. * What we are discussing is purposes not functions of the system. What is the legitimate purpose for processing this data, and there are purposes other than contacting the registrant. * We are aware there was no reverse WHOIS previously. It is common that a trademark owner would identify multiple infringing domain names and prioritize action based on patterns of infringing domain names. We are currently seeking some sort of identifier that does not run afoul of data protection law. * Another relevant use case is abusive domain name registrations. If a domain name is using malware, it would be helpful to identify other domain names registered by the same registrant to enable the stop of abuse. * The problem with correlation is that the identifier may not be the person’s name but if it identifies every domain name registration the individual has made, this is personally-identifiable information. This is valuable for cyber-security research, but it can also be valuable for bad guys. * The key question for this group is feasibility in light of the GDPR. * For a trademark search, if domains are correlated, you will get the correlation anyway. For cyber security researches, this is different. Do not see how to publish this data for the few cases without publishing the email of every registrant in the domain name system. * There is value in the identifier even if it’s not published. If the cyber-security expert would make a request and receive the full list – this could still be helpful. * The same tools of correlation are available to bad actors – people are getting spammed and doxed. Ultimately, would rather have 100 domain names that are abusive than to have two customers that are harmed. Many registrars have an interest in doing this correlation themselves because it ultimately saves the registrar money by taking action proactively. Would rather turn off 100 domain names than receive 100 tickets over time. Maybe provide guidance to registrars to do this type of correlation themselves, and therefore, if this is handled by the registrars, a need for third parties to do this goes away. * Could be worth looking at the benefit of having a registrant-based email address that is not published. * There is some discussion about unique identifiers. There is a difference between a unique email address vs. a unique identifier. * Given the way that EPP works, in that before a domain name is registered, a set of contact data is sent to a gTLD registry – an anonymized identifier could be done at a registry level and have a domain name attached to it. This could also be done at the RSP level. * What we are recognizing in this discussion is that there is legal feasibility under GDPR and technical feasibility – technical feasibility seems like a secondary issue at this point. * Where we are landing on the chart on the screen is the bottom left quadrant – whatever anonymized identifier is tied to the registrant. * Believe the bottom right quadrant is the preferred option. * Prefer to be in the top left quadrant, while registrars would like to be in the bottom right. Proposal is to meet in the middle with the bottom left quadrant. * Is this guidance or a requirement? We will table this question for now and move on. · What are the next steps in developing a response for inclusion in the Initial Report? 4. 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. Consideration of question i. 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“); a. Each group to provide a high-level summary of responses to questions (see https://docs.google.com/document/d/1gMV29jRPQEFGv2psZ2py2_F8cr93OeeA/edit): · ALAC * Strongly support Milton’s proposal – principle #1. This, however, does not seem to have the support of contracted parties. Discussion regarding the SSAD is a red herring – do not understand why a simple vanilla RDAP server could not be used. This would go to the registrar via RDAP. This is a PDP looking at policy, not building a mechanism. Would recommend focusing on the questions from the Council and not engage in extraneous conversation that may or may not be implemented in the long term. · BC · GAC * As we approach the May deadline, it is good to remember the expected standards of behavior. Disappointed to see the response to a good faith intervention. While some members would prefer not to differentiate, this is OK to note but to claim DNS abuse is nonexistent is disrespectful. The RrSG position on this is very clear – only differentiate if required by law – seems that the registrar reps would prefer to be regulated rather than to self-regulate. Recall some helpful comments from contracted parties – why should we differentiate – it seems to benefit everyone but us. This is a valid and constructive point. Suggest focusing this meeting on what the benefits would be of making this a requirement. 1. By differentiating, you will have less access requests. (this will prevent having to do manual balancing tests and diminish the uncertainty). 2. Another advantage is reputation. There are implications that the current practices are lacking transparency. 3. Another benefit would be self-regulation – this is a great opportunity for registrars to influence things. You have the opportunity for your voice to be heard. From the messages we receive from the legislators, we should not presume that the requirements would be even more stringent. Could these aforementioned benefits make the contracted parties change their mind? We could wait for three years for the SSAD, but we risk legislation coming down in the meantime. With respect to the RrSG on the SSAD, we have taken this into account, but even if we use the SSAD for disclosure, you cannot remove the step of differentiating between legal and natural entities. * Response to previous comments – question is shouldn’t the issue of consent only come into play when we’re talking about personal data. When we are talking about legal entities and their non-personal data, consent is not applicable. Do not understand the inclination to protect data that is not protected under the law. * If the Team can separate out these two scenarios, might we agree on how to treat the non-personal data of legal entities? If we could move forward on this, it would be productive. · IPC · ISPCP * Thought there was a constructive conversation regarding the difference between personal and non-personal data. Part of the data of legal entities is still personal data, so we were talking about a two-step approach, which includes a distinction of personal and nonpersonal data. * No consent is required where the data of legal entities have no personal data present. There is a risk in seeking consent where it is not required. Under no circumstances should we ask for consent where none is needed. · NCSG * Not pleased with the implied threat that governments will supersede this policy; however, this is a concern the group should consider. The stakes of this are less than many people believe. There are many ways of getting information in the digital environment. Historic WHOIS data is being commercially marketed all over the place. There are other internet services that are points of abuse or crime that may be more helpful than loading this onto DNS. Tried to explore a space for agreement. 1. There should be differentiation b/w legal and natural. Think that Volker’s idea to put everything behind the SSAD with automated disclosure is a very good idea. The third party can get the data quickly and efficiently, and in the event of bad actors, the bad actors could be kicked out of the SSAD. * In the real world, the distinction between personal and non-personal data is becoming blurry. There is a gray area of quasi-legal persons who are small businesses or people working from home. The second articulated principle regarding the registrant being in control would help bridge this gap. · RrSG * Would prefer self-regulation. Have made a concrete proposal regarding disclosure in the SSAD – similar to a German trade registrar. Following this example would benefit us as we would not be reinventing the wheel. There are many benefits from this proposal – not sure why this is not receiving greater support. Also do not understand why these publishing requirements are not also going after hosting providers? Recommend focusing on what is reasonable and implementable, even if it takes are few years rather than a stop-gap solution. * The cited study was paid for by parties with a specific goal and do not find it persuasive. * Cannot look at a certain data set and see if it is personal or not – that is only for the registrant to determine. · RySG · SSAC b. EPDP Team to consider next steps to develop response to question i. c. Confirm next steps Guidance development d. Consider new issues flagged in the write up<https://docs.google.com/document/d/1whCpXHm3UPmJ-IDSbliveSkwxL679x2U/edit#h…>: · Definition of “publish” (note, the write up currently includes the following definition “EPDP-p1-IRT: “Publication”, “Publish”, and “Published” means to provide Registration Data in the publicly accessible Registration Data Directory Services.”) · Any concern about moving “Distinguishing between legal and natural person data alone may not be dispositive, as the data provided by legal persons may include personal data that is protected under data protection law, such as GDPR” to the guidance section? · See 1d – what approach should be taken when a Registrant makes substantive changes to registration data? · Consider whether it would be helpful to add a timeline to scenario 2. · Consider whether scenario 3 should remain. · Other? e. Homework assignment – new version of write up has been developed by Staff Support team based on deliberations on B & B advice during last meeting and input received by deadline. Groups to review latest version and flag any concerns / issues by Friday 23 April at the latest. In the course of next week, ‘final’ draft version is expected to be circulated with the request for groups to flag any cannot live with items. 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. EPDP Team Meeting #17 Tuesday 27 April at 14.00 UTC 2. Confirm action items 1. Confirm questions for ICANN Org, if any

1 0

Legal/Natural via SSAD
by King, Brian 22 Apr '21

22 Apr '21

Hi Volker, Hoping to clarify your proposal so we can consider it fully, are you proposing to automate SSAD disclosure for domains whose registrants have self-designated that the registrant is a legal entity and the RDS data does not include personal data (fulfilling Milton’s principle of self-designation)? Brian J. King Head of Policy and Advocacy, Intellectual Property Group T +1 443 761 3726 clarivate.com Confidentiality note: This e-mail may contain confidential information from Clarivate. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is strictly prohibited. If you have received this e-mail in error, please delete this e-mail and notify the sender immediately.

2 1

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2A | Thursday, 22 April 2021 at 14:00 UTC
by Terri Agnew 22 Apr '21

22 Apr '21

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

Re: [Gnso-epdp-team] [EXTERNAL] Re: On the proposed guidance
by Mark Svancarek (CELA) 22 Apr '21

22 Apr '21

Analogies of trade registries (or real property registries, a better example IMO) are flawed unless the data is available instantly and completely. So far the proposals seem to propose that only some unpredictable fraction of the data will be instantly available, with the rest subject to multi-day manual inspection. I doubt that will meet the standard of “publication”. From: Volker Greimann <vgreimann(a)key-systems.net> Sent: Thursday, April 22, 2021 7:31 AM To: Mark Svancarek (CELA) <marksv(a)microsoft.com> Cc: King, Brian <Brian.King(a)markmonitor.com> Subject: Re: [EXTERNAL] Re: [Gnso-epdp-team] On the proposed guidance My proposal includes the provision that data that is confirmed not to contain personal information would be automatically disclosed to requestors. I am essentially proposing to lowering the barriers of access and the costs associated with this specific (and potentially other) automatic disclosure category. Basically framing the "Lowest" category as a functionality of SSAD, broadening SSAD availability and conceding this data would be available for automated disclosure. How can you not love that? -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sy…> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Thu, Apr 22, 2021 at 4:07 PM Mark Svancarek (CELA) <marksv(a)microsoft.com<mailto:marksv@microsoft.com>> wrote: The trade register provides guaranteed instant access to all data. I haven’t seen a proposal so far which would ensure that all legal persona data would be available for automated access. From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Volker Greimann via Gnso-epdp-team Sent: Thursday, April 22, 2021 6:58 AM To: King, Brian <Brian.King(a)markmonitor.com<mailto:Brian.King@markmonitor.com>> Cc: gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: [EXTERNAL] Re: [Gnso-epdp-team] On the proposed guidance That is but one opinion, Brian. As I have already outlined previously, common practice all over Europe disagrees with her. Data can be public even if they are behind a wall. No sane person in Germany would argue that the trade register is not public. And what is the implementation of the online access functionality of the German trade register but a light version of SSAD - exactly what I am proposing. You have the opportunity for a win here. Let's not waste it. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-sy…> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Thu, Apr 22, 2021 at 3:48 PM King, Brian via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Hi Alan, Sure thing. Melina (who wrote the NIS 2 Directive) clarified that point in her email on Tuesday. I’ve attached it here in hopes that the email list server doesn’t eat it. Brian King He/Him/His Head of Policy and Advocacy T +1 443 761 3726 Time zone: US Eastern clarivate.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.clariv…> | Accelerating innovation Follow us on LinkedIn<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linke…>, Twitter<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.c…>, Facebook<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.faceb…> and Instagram<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.insta…> From: Alan Woods <alan(a)donuts.email<mailto:alan@donuts.email>> Sent: Thursday, April 22, 2021 9:29 AM To: King, Brian <Brian.King(a)markmonitor.com<mailto:Brian.King@markmonitor.com>> Cc: Thomas Rickert <epdp(a)gdpr.ninja<mailto:epdp@gdpr.ninja>>; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] On the proposed guidance Hi Brian, You have noted this European Commission advice twice now. both here and in the homework document comments. I need not say that our statements in this process have very large importance to the progression of this process, and I can but urge caution in categorical statements. If you can provide us with a copy of or a link to legal advice described, as formally issued by the Commission, regarding the implementation of the draft proposed directive (not to mention individual member state implementation) and how that applies to the SSAD, or more to the point why current proposed method does not meet 'publication requirements', then I think we would all be very interested in reviewing that. If not, I think we should continue to consider the path forward here that has been proposed. Thank you. [Donuts Inc.]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> Alan Woods Senior Manager, Compliance & Policy, Donuts Inc. ________________________________ Donuts Ground Floor Le Pole House Ship Street Great Dublin 8 [http://storage.googleapis.com/signaturesatori/icons/facebook.png]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> [http://storage.googleapis.com/signaturesatori/icons/twitter.png] <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> [http://storage.googleapis.com/signaturesatori/icons/linkedin.png] <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Thu, Apr 22, 2021 at 2:15 PM King, Brian via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> wrote: I like it too (which is why I proposed it in Phase 2). However, what we developed in Phase 2 is clearly not acceptable to most groups, plus, we may never have an SSAD. Historically we’ve been let down by ICANN’s inability or unwillingness to implement policies like PPSAI which actually have consensus (unlike SSAD) and which have progressed to implementation, so I don’t see the IPC agreeing to the dubious proposition of SSAD as the solution here. Furthermore, the European Commission has already advised that mere availability of legal entity data in SSAD will not meet the publication requirements in NIS2. So let’s stay focused. Brian J. King Head of Policy and Advocacy, Intellectual Property Group T +1 443 761 3726 clarivate.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fclarivate.…> On Apr 22, 2021, at 8:18 AM, Thomas Rickert via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Let me go on the record that I also like the idea. I addition to the points mentioned by others, making it a one-stop-shop for all data would make it more user friendly, add safeguards against undesirable correlation of data and allows for kicking-out bad actors even at that level. Best, Thomas Am 20.04.2021 um 23:49 schrieb Volker Greimann via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>>: Hi Milton, essentially, yes, although it would be non-personal data. And it takes care of a huge chunk of DNS abuse (the abuse originating from the RDS harvesters, that is). -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Tue, Apr 20, 2021 at 8:47 PM Mueller, Milton L via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> wrote: > Obviously I can’t speak for Volker, but I want to try and respond with why I find Volker’s > proposal intriguing. I too am intrigued by this suggestion. Volker as I understand it proposed that instead of publishing the data as we used to do with “ye olde Whois” (love that term), we would make the data of those who flag themselves as legal persons available automatically to any registered SSAD user who requests it. Other requests would be available based on the review for legitimate purpose as originally envisioned. As Marc suggests, going through SSAD eliminates a lot of abusers/bad actors or at least gives us some recourse against them, but still gives all the legitimate users easy access to data that does not need to be private. I would hope this option would be acceptable to the stakeholders who are arguing for a legal/natural distinction. Dr. Milton L Mueller Georgia Institute of Technology School of Public Policy _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_l…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. Confidentiality note: This e-mail may contain confidential information from Clarivate. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is strictly prohibited. If you have received this e-mail in error, please delete this e-mail and notify the sender immediately. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_l…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. Confidentiality note: This e-mail may contain confidential information from Clarivate. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is strictly prohibited. If you have received this e-mail in error, please delete this e-mail and notify the sender immediately. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.…> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann…>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann…>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

3 3

Re: [Gnso-epdp-team] Write up + RrSG-proposed Guidance
by Sarah Wyld 22 Apr '21

22 Apr '21

Hello all, Instead of the new doc you can find the same suggestions in this April 20 version of the staff writeup doc: https://docs.google.com/document/d/1a7MEle3_e-iXbaiZQV5wCD4Pv0414YjLtC2yxJE… -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/her swyld(a)tucows.com +1.416 535 0123 Ext. 1392 From: Sarah Wyld via Gnso-epdp-team Sent: April 22, 2021 8:04 AM To: gnso-epdp-team(a)icann.org Subject: [Gnso-epdp-team] Write up + RrSG-proposed Guidance Good morning team, As the RrSG-proposed Guidance was not fully incorporated into the writeup, we provide this updated version as a suggested method of combining the two: https://docs.google.com/document/d/1kEewYX2OyIi_lGdfnE-3HoUrqp1-etppRD17V_U… Please note that the RrSG-proposed Guidance is specifically the chart (GDPR Principles etc), not the three scenarios (which were included in our previous Guidance document as a summary of the group discussion, not something we created). I’ve also suggested some other changes to the writeup, and included notes in the comments where relevant. I look forward to discussing this at the appropriate time. Thank you. -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/her swyld(a)tucows.com +1.416 535 0123 Ext. 1392

1 0