April 2021 - Gnso-epdp-team

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

April 22, 2021

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 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 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] [EXTERNAL] Re: SSAD as a means of publishing non-personal data
by Mark Svancarek (CELA) April 22, 2021

April 22, 2021

I possibly won't care who provides the non-contact data so long as it is always instantly and freely available. I'd like to know what Rys have to say about all traffic moving from Rrs to them. From: Volker Greimann <vgreimann(a)key-systems.net> Sent: Thursday, April 22, 2021 7:22 AM To: Mark Svancarek (CELA) <marksv(a)microsoft.com> Cc: Alan Greenberg <alan.greenberg(a)mcgill.ca> Subject: Re: [EXTERNAL] Re: [Gnso-epdp-team] SSAD as a means of publishing non-personal data Hi Mark, quite honestly, that is TBD and depends where we end up. If RDAP turns out the way I proposed, data transfer is possible, so it does not matter who provides the data. The question is where we as a community want the data to be published. I think we can agree that duplication is not likely to be needed so it would be either Rr or Ry. Which one does not matter that much to me. -- 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:11 PM Mark Svancarek (CELA) <marksv(a)microsoft.com<mailto:marksv@microsoft.com>> wrote: Volker, earlier in this discussion you seemed to be suggesting that register-provided RDAP would go away, with all data (including non-contact data such as the registrar field) moving behind the SSAD paywall. Or perhaps you were suggesting that such RDAP access be available only from a registry. Did I understand correctly? From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Alan Greenberg via Gnso-epdp-team Sent: Thursday, April 22, 2021 7:03 AM To: Volker Greimann <vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net>> Cc: EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Subject: [EXTERNAL] Re: [Gnso-epdp-team] SSAD as a means of publishing non-personal data 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: 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 8:02 AM Alan Greenberg via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@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 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.

1 0

FW: On the proposed guidance
by Mueller, Milton L April 22, 2021

April 22, 2021

> 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

5 7

**Meeting begins in 15 min** Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2A call | Thursday, 22 April 2021 at 14:00 UTC
by Andrea Glandon April 22, 2021

April 22, 2021

Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2A is scheduled on Thursday, 22 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/4ISUCQ Check your time zone: https://tinyurl.com/ady6y2hj [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/ady6y2hj__;!!PtGJab4!o1oT6KU…> 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

SSAD as a means of publishing non-personal data
by Alan Greenberg April 22, 2021

April 22, 2021

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

3 2

A perspective on the relative importance of legal vs natural
by Steve Crocker April 22, 2021

April 22, 2021

Folks, Attached is a short note for your consideration in reference to the three questions under consideration. The last paragraph of this two page note says: The emphasis on determining whether a registrant is a natural person or a legal person is just one part of the overall data access model. It makes a qualitative difference whether or not there is shared confidence in the forthcoming existence of an effective, efficient and timely differentiated access system. No matter where this WG sets the bar regarding distinguishing between legal and natural persons, it is vital to move forward with differentiated access. Further, this WG should say so and its decisions should be in the context of confidence that differentiated access will be part of the overall system. This approach will not obviate the need for distinguishing legal vs natural persons, but it will relieve us of seeing this distinction as the only policy issue related to who will have access to which data. Thanks, Steve

2 1

Write up + RrSG-proposed Guidance
by Sarah Wyld April 22, 2021

April 22, 2021

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

**Reminder** Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2A call | Thursday, 22 April 2021 at 14:00 UTC
by Andrea Glandon April 21, 2021

April 21, 2021

Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2A is scheduled on Thursday, 22 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/4ISUCQ Check your time zone: https://tinyurl.com/ady6y2hj [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/ady6y2hj__;!!PtGJab4!o1oT6KU…> 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 #16 - 22 April 2021
by Caitlin Tubergen April 20, 2021

April 20, 2021

Dear EPDP Team, Below, please find the agenda for the next EPDP Phase 2A plenary meeting. Please review the feasibility memo<https://community.icann.org/display/EOTSFGRD/EPDP+-P2A+Legal+subteam?previe…> in advance of the meeting. Additionally, please take note of the outstanding action item: EPDP Team to respond to questions outlined in the google doc in relation to the question of whether or not changes should be made to existing requirements by Wednesday 21 April and come prepared to the meeting on 22 April to provide a high level summary of the responses provided. <https://docs.google.com/document/d/1gMV29jRPQEFGv2psZ2py2_F8cr93OeeA/edit>https://docs.google.com/document/d/1gMV29jRPQEFGv2psZ2py2_F8cr93OeeA/edit. 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) * Update from the legal committee – outstanding question 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) · 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. · 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 · BC · GAC · IPC · ISPCP · NCSG · RrSG · 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<https://docs.google.com/document/d/1a7MEle3_e-iXbaiZQV5wCD4Pv0414YjLtC2yxJE…> 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. (https://docs.google.com/document/d/1a7MEle3_e-iXbaiZQV5wCD4Pv0414YjLtC2yxJE…) 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

2 1

FW: On the proposed guidance
by Mueller, Milton L April 20, 2021

April 20, 2021

>" Everyone who is named in a role in a registration must have already been informed > and consented to all of the conditions involved in the role. " This is the ideal. Sadly, this ideal > is very often not the case. Whoa. Of course, Volker, it is possible that a person making a registration for a legal person won’t do it properly. But it is absurd to expect a registrar to be legally responsible for that. How can the registrar be liable for privacy breaches made by the registrant? Indeed, I can’t understand why gaining the consent of the administrative assistant of the xyz department to have their name listed in the whois is a matter for DNS/ICANN policy at all. ICANN policy simply needs to inform registrants that under certain conditions the data will be published. Let’s take an extreme case – suppose a nasty IT manager in a major corporation puts the name, email address and (what the heck) a revenge porn photo of her ex-husband in her company’s registration record. Are you telling me the registrar would be considered responsible for that breach of privacy? Not the nasty IT manager? Show me a legal case in which that kind of liability has been assigned. I doubt you can, but I await the data from CP lawyers who have been involved in these cases. I do know of several cases in which agents for a corporation wrongly listed themselves as the technical and administrative contact, making it possible for them to hijack the name. The registrar was NEVER held liable for that. Reminder: We had to reform Whois/RDS policy because ICANN, as a matter of contractual obligation, required registrars to publish sensitive PII of any and every Registrant. Once we have removed that obligation, and once we have given registrants knowledge of the conditions under which the data in the record should be published, I don’t see why registrars need to worry about some corporation listing the personal email address of someone in their IT department. So if this alleged risk is being cited to scare us away from allowing registrants to self-designate as legal or natural, it is a pretty weak case, imho. --MM 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 15, 2021 10:10 AM To: Steve Crocker <steve(a)shinkuro.com<mailto:steve@shinkuro.com>> Cc: gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] On the proposed guidance Employees are named by other employees without their knowledge, or remain named long after they leave. From the experience as a registrar dealing with registrants every day, this ideal is an assumption that does not survive contact with reality. -- 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<http://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 15, 2021 at 3:36 PM Steve Crocker via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Laureen, Thanks for your note. With respect to the details under legal person, we believe the issue of consent should be moot. Everyone who is named in a role in a registration must have already been informed and consented to all of the conditions involved in the role. This is a prerequisite for having a working system and is not specific to meeting a privacy regulation. The fact that this requirement is not specified in the existing contractual documentation is an error and needs to be rectified. Steve On Thu, Apr 15, 2021 at 6:28 AM Kapin, Laureen via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> wrote: I think we share common ground on many key issues and I would like to build on the many helpful inputs received as to what would be advisable. Goal: publish non-personal, non-protected data to the greatest extent permissible under the GDPR and within low legal risks to data controllers and processors. Note, the description below does not fully detail the advised safeguards which B&B has documented and which we’ve adopted in our prior input because my impression is that we generally agree that the safeguards are prudent. This description merely seeks to identify the key steps that must be taken to ensure that personal data is identified and protected and non-personal data is published. I also highlight the addition of a potential additional safeguard – Confirmation. I think this process incorporates what we’ve discussed and inputs received and could form a useful framework for discussion. Note: • New Registrations: This process applies to new registrations (Steve C. has some useful thoughts on how to deal with existing Registrations) • Publish: When I use the word “publish,” I mean made public directly; not via the SSAD. • Flexibility: Based on input from our Registrar colleagues, we should permit flexibility for how these steps are implemented to account for the varied business models in place. • Timing: All identifications need to take place at the time of registration or shortly thereafter (w/in the 13-day accuracy verification window) and no registration data should be published until the identification, consent, and confirmation process concludes Process: 1. A threshold identification of the registrant as a natural or legal person; a. If natural, registration info redacted b. If legal, further inquiries and advisories (safeguards): i. if the legal person identifies that it has a protected status under the GDPR 1. registration info redacted ii. If the legal person registration contains personal data, advise of consequences (publication) 1. Obtain necessary consents 2. Possible additional safeguard: Ask Registrant to Confirm any identification that will result in publication of contact data (akin to confirming a flight reservation or stock trade) a. Publish 3. If no consent a. Redact 2. Provide quick and easy opportunity to correct any mistakes I hope this is useful. Kind regards, Laureen Kapin Counsel for International Consumer Protection Federal Trade Commission (202) 326-3237 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 15, 2021 8:35 AM To: Hadia Abdelsalam Mokhtar EL miniawi <Hadia(a)tra.gov.eg<mailto:Hadia@tra.gov.eg>> Cc: gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] On the proposed guidance I think we need to be cognisant of the current status quo and use that as the basis for our thoughts on the matter: 1) There is no differentiation between legal or natural contacts. 2) The redaction of all contacts is permitted and has become the de-facto standard. 3) We allow consent-based disclosure. 4) NIS 2 may at some point in the future require publication of non-personal information. This leads to two very simple follow-on questions: a) How do we identify such non-personal information? What is really necessary for this end? b) What would publication entail? For a) we and Twobirds identified voluntary self-declaration of the data submitted. As all data is redacted by default, the differentiation of the data subject category is irrelevant as it ultimately only boils down to the declaration of the data subject thatthe data contains no personal information. For b), the term "publish" is undefined. For all we know, it could mean publication in a physical print edition (it doesn't mean that though). But publication within SSAD can very well be sufficient for that definition. There is no reason whatsoever to assume differently. -- 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<http://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. [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> On Thu, Apr 15, 2021 at 1:52 PM Hadia Abdelsalam Mokhtar EL miniawi via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Dear Milton, Thank you for your constructive thoughts. I believe we have a lot to build on. In relation to principle one, I think we all agree that some legal data subjects would want to publish their data in the RDDS, but without your first principle they can only do this through consent. The legal memo received lately from Bird & Bird explains that if CPs publish the data of legal persons based on consent they are at a higher risk than if they publish the data of legal persons based on self-designation. In the latter case CPs might only be liable if they fail to address a complaint. So the question always was: what is the benefit of labeling the data as belonging to a natural or legal person? Of course we all know that GDPR protects the data of natural persons and not legal persons, but the important answer now is that the distinction significantly reduces the liability of CPs. In addition, the distinction is helpful in performing the balancing test in case the data is not published and I am sure if we look into individual use cases we can find much more benefits. Moreover, it could prove to be useful regarding possible upcoming regulations. I would also add that the level of protection assigned to the data elements suggested by Steve provides additional safe guards and flexibility in the implementation. Finally, I join you in being optimistic about our ability to finish this. Kind regards Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>] On Behalf Of Mueller, Milton L via Gnso-epdp-team Sent: Wednesday, April 14, 2021 10:12 PM To: gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] On the proposed guidance Colleagues: I have only gotten time to review the latest Guidance document and the surrounding debate today. Apologies, but there is a lot going on in my day job. I am disappointed to see that we seem to be going backwards. I see divergence rather than convergence on the way we are approaching the problem. I see no point in adding more noise to the current document via the Comments function. What I would like to try to do is articulate some broad principles about how to deal with the legal/natural distinction. If we can agree on those principles, it will be relatively easy to complete the document. If we cannot/do not agree on those principles, additional wordsmithing and debates over terms will not get us anywhere. So here are the broad principles that I would offer up for debate: 1. The legal/natural distinction is relevant and we need to find a way make it in RDDS without compromising privacy rights. 2. Registrants should be able to self-designate as legal or natural, with no burden of authentication placed on registrars or registries 3. To protect small home offices or NGOs who are technically Legal persons but whose registration data may include Personal data, we need an additional check in the process. 4. As long as they conform with the above 3 principles, registrars/ries (CPs) should be given maximum flexibility to choose the way to differentiate. Principle 1 discussion: If we cannot agree on this (or agree to abandon this principle), _nothing else will fall into place_. Ever. So let’s settle that. Steve and Volker I suspect will disagree with this principle. Steve has argued that the L/N distinction is “not a central concern” and all that matters is whether the registrant’s data is to be made available to anyone. If he is right, we can discard the guidance altogether, because we already have a recommendation to allow the RNH to consent to the publication of their data. Volker has also suggested that it is personal data we need to differentiate, not L/N . I disagree with Steve and Volker on this and so do most of the rest of the group. L/N distinction is a central concern to certain stakeholder groups in the EPDP, because a) GDPR and other data protection laws do not protect it and this process is all about bringing RDS into compliance with privacy law; b) Legal person data could be published and it would provide easier access to their registration data. As a NCSG member I can find no basis for objecting to the publication of WalMart’s, Kroger’s or the local hardware store’s registration data. Any concerns about PII are addressed by principles 2 and 3. Steve is approaching this as an engineer, but this is a policy process, and we will not obtain agreement on a solution unless certain stakeholders are satisfied. If they think it is a central concern, it’s a central concern, that’s how policy/politics work. Principle 2 discussion This is the key principle that keeps NCSG and CPH satisfied. Registrants are in control of how they are designated. Yes, this means that some people will lie. That is just something we will have to accept. One cannot erase that possibility without creating a system that is too burdensome and costly as to outweigh any benefits. Principle 3 discussion This is something everyone seems to agree on already. But it is good to make it explicit, then we can work out how specific our guidance can get, so as to conform to … Principle 4 Avoid being overly prescriptive, but ensure that the other 3 principles are honored. So yes, Volker, we give you maximum flexibility to implement in accordance with different business models, but you can NOT make a designation for a RNH, because it violates principle 2. I truly believe that if we can come to agreement on these 4 principles and use them as the basis for drafting guidance, we can actually finish this. _______________________________________________ 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 _______________________________________________ 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) and the website Terms of Service (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. [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> _______________________________________________ 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 _______________________________________________ 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) and the website Terms of Service (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. _______________________________________________ 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 _______________________________________________ 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) and the website Terms of Service (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.

7 13