September 2018 - Gnso-epdp-team

GAC Early Input
by Marika Konings Sept. 7, 2018

Sept. 7, 2018

Dear All, For your information, GAC Early Input has been received and has been posted here: https://community.icann.org/x/Ag9pBQ. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

1 0

RrSG edits -- Section 4.4
by James M. Bladel Sept. 7, 2018

Sept. 7, 2018

ePDP Team – In preparation for tomorrow’s call, please find attached a redline PDF of our edits to Section 4.4 of the Temp Spec, along with a slide/PDF with “clean” language for Kurt & Staff. Matt, Theo and I will walk through these edits, along with our rationale. Look forward to our discussion tomorrow. Thanks— J. ------------- James Bladel GoDaddy

11 14

Applications for ICANN63 Travel Support - deadline 13 September 2018
by Marika Konings Sept. 6, 2018

Sept. 6, 2018

Dear All, As discussed during the meeting, please find attached the requirements, criteria and process to apply for travel support for ICANN63. The deadline for applications is Thursday 13 September. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

2 1

Factual studies starting to shoot down the "going dark" panic
by Mueller, Milton L Sept. 6, 2018

Sept. 6, 2018

Relevant to the work of this group is the following study from Recorded Future. https://www.recordedfuture.com/gdpr-spam-impact/?utm_content=76363539&utm_m… Entitled "90 Days of GDPR: Minimal Impact on Spam and Domain Registration" Dr. Milton Mueller Professor, School of Public Policy Georgia Institute of Technology [IGP_logo_gold block_email sig]<http://www.internetgovernance.org/>

6 11

“Action item #4: Alex and Thomas to collaborate on redrafting §4.4 (introductory paragraph), Appendix A.4. and Appendix C2.”
by Thomas Rickert Sept. 6, 2018

Sept. 6, 2018

Hi all, While Alex (and Diane) and I have discussed this and exchanged e-mail on this, we have not come to a final text. Nonetheless, Alex and I agreed we should share what we have and talk you through the points we struggled with. Best, Thomas However, such Processing must be in a manner that complies with the GDPR. In particular, the principles laid down in Art. 5 GDPR must be abided by, e.g. there must be a specified, explicit and legitimate purposes. Additionally, a legal basis from the catalogue in Art. 6 I GDPR must be given. These are: a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes; b) processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; c) processing is necessary for compliance with a legal obligation to which the controller is subject; d) processing is necessary in order to protect the vital interests of the data subject or of another natural person; e) processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller; f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child. Purposes pursued by ICANN which correspond to its own organizational mission and mandate: [Bulletpoint list] Purposes pursued by other interested third parties [Bulletpoint list]

3 2

Discussion of Temporary Specification §§4.1-4.3
by Kurt Pritz Sept. 6, 2018

Sept. 6, 2018

Hello Amr (and everyone): I am writing in response to your proposal that the team considers Temporary Specification §§4.1-4.3 (with reference to the ICANN Bylaws and mission) prior to our discussion of data elements. I think understand the reasoning behind your request but still believe we should finish the “purposes” and “data elements” discussion before going into the reach of ICANN’s mission and Bylaws. Let me test out my reasons for this: With regard to the ICANN mission and Bylaws I believe there is a range of opinions among the stakeholder groups on our team as to the extent that the ICANN mission and Bylaws enable the collection, use and disclosure of personal data, In the best case, which I view as unlikely, we would develop a consensus opinion on this issue. Thus would be a helpful but not dispositive guide for identifying which data elements are collected and how they are used / disclosed. We’d still have to undertake that. More likely, I believe there would be a discussion without a consensus result. Even in that case, we would next take up the task of identifying data elements to be collected by registrars and their subsequent processing. Given that we have existing data collection and processing practices that were adequate pre-GDPR, it seems better to weigh those practices against GDPR and see what remains. Given the discussion at the end of the last meeting, it appears that the currently collected set of data is adequate for the currently identified needs of those seeking personal data disclosure. I can anticipate where there might be differences (we will see) but if an agreement is struck regarding the collection and disclosure od data elements, it seems accommodation on policy statements is more likely. Taking a slightly different approach to the same point: I think we should be discussing the section 4.4 elements, legitimate reasons for disclosure, and Appendix A against the GDPR and not against the ICANN Bylaws and mission. I understand that §§4.1 and 4.2 are elements in the Temporary Specification and must be discussed (I am not sticking my head in the ground here - I don’t think), but it is more efficient to discuss these paragraphs later — and especially if we don’t agree on data elements collected and processed. I think Alan G. was on to something in his earlier email where he said we should focus on what’s needed for our policy. Our goal is to identify (as a matter of policy): The legitimate purposes for processing registrant data the set of data to be collected by registrars and identifying the legitimate reasons (i.e., reasons with a legal basis) for disclosing that data to third parties. This, of course is an oversimplification but it is where we should focus. (I know others have made these comments before. I think Amr’s inquiry is a good time to restate what some others have said.) I hope this was clear and helpful to the discussion. Best regards, Kurt

5 4

Notes and action items from today's EPDP Team Meeting - 6 September 2018
by Caitlin Tubergen Sept. 6, 2018

Sept. 6, 2018

Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Tuesday, 11 September, 13:00UTC. Best regards, Marika, Berry, and Caitlin EPDP Team Meeting #11 6 September 2018 High-level Notes/Actions The Triage report will be sent to the GNSO Council tomorrow, absent any comments that would cause a group discussion. Feedback on the triage report, if any, is due today. Applications for travel support to ICANN63 in Barcelona are due Thursday, 13 September. Please note the document that was sent with the meeting slides today. A GDPR training vendor has been selected, which will provide a self-paced, online GDPR introduction course. All EPDP Team Members will be required to complete this course, and details on how to take the course will be distributed when available. Following the online training, there will be an additional in-depth presentation(s) by EPDP Leadership-selected GDPR experts. During today’s meeting, Registrar EPDP Team Members presented an edited version of Temporary Specification §4.4, which focused on registrar purposes for data processing. Following the explanation, EPDP Team Members provided constructive feedback, by group, on the proposed edits. Many Team Members indicated that the lack of time to comprehensively review the edits in advance of the meeting will cause them to adjust their initial feedback later. EPDP Team Members may continue providing feedback to the list. The Support Team will provide an organized description of the comments to indicate the progress toward consensus on each section and where commenters pointed the way toward additional discussion. To aid in the Team’s discussion at the next meeting, Thomas and Benedict will develop a sub-divided §4.4 into: (1) where ICANN acts as a sole controller; (2) where ICANN acts as a joint controller with registrars / registries; (3) where ICANN facilitates or enables a third-party framework. It will be delivered by Monday, September 10. The next meeting will cover the reformatted and edited §4.4 as described above, input describing edits to §§4.4.2, 4.4.8 and 4.4.9. Assuming acceptance (at some level) of the edited §4.4 introduction that was described at the end of the meeting, each “editor” will also include the GDPR basis listed in the introduction as the justification for inclusion as a legitimate purpose for processing data. EPDP Team Members provided the following two links for further reading: (1) an eight-year old Article 29 Working Party Opinion on the concepts of "controller" and "processor" https://iapp.org/media/pdf/resource_center/wp169_concepts-of-controller-and… and (2) The SIDN purposes for data processing under GDPR: https://www.sidn.nl/downloads/terms-and-conditions/About_SIDNs_Privacy_Poli… Notes & Action items These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ. 1. Roll Call & SOI Updates Attendance will be taken from Adobe Connect Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes. Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair Triage report will be sent to the GNSO Council tomorrow, so please provide additional feedback (if any) by COB today. Update on status of GDPR training Proposal to use IT Governance, self-paced online training Followed by sessions by additional experts with opportunities to ask questions Update on travel to ICANN63 Travel requests are generally duu 90 days before the meeting. EPDP Team will be funder of last resort, so if you are eligible for other funding (through your SO/AC/company, or partial funding, please use that. The application form notes 14 September as the deadline, but please send in the form by Thursday, 13 September, so decisions can be made by Friday, 14 September. The ICANN63 sessions will most likely be open sessions, but the group needs to consider if these will be real working sessions. (Observers will be allowed in the room, but may not be invited to speak/contribute.) If the group could receive closure on whether these sessions are open or closed as soon as possible so that SO/ACs can plan their schedules. Other issues or concerns re: ICANN63 can be raised via the list. Other updates, if applicable Are there any suggestions on how to move forward with Section 4.4.8? Suggestions that the current method for drafting of sections may be problematic Registrars were asked to draft sections that pertain to their use of the data, and others volunteered for other sections. These drafts are used for discussion purposes, so members that disagree may speak up in the meeting and/or on the list. 3. Proposed modifications to section 4.4 - Registrar / Registry / ICANN processing of data a. Review proposed modifications put forward by the Registrar Team The registrars will present their findings, and then we will "go around the room" and discuss. Registrar overview: This proposed text was developed by Registrar members and alternates, under the supervision of the RrSG Excom. In section 4.4, we took out the reference to GDPR since there are other applicable data protection laws. Section 4.4.1 has no proposed changes. Proposal to delete Section 4.4.2 entirely. 4.4.3 - removal of identification since identification may be a broader footprint of personal information. Proposal to remove section 4.4.4 since registrars do not use WHOIS for payment/invoice purposes Proposal to remove 4.4.6 because registrars use other facilities to communicate technical changes in a domain name. 4.4.7 - proposal to eliminate entirely as this is a redundant point of contact 4.4.8 - cybercrime is folded into law enforcement. This is an area where registrars had divergent opinions re: IP interests. 4.4.9 - proposal to remove as this may belong in an access discussion 4.4.10 - proposal to remove this as registrars are not aware of a registrar purpose for publication of zone files. 4.4.11 - proposal to remove as this is covered in registrar data escrow 4.4.12 - updated to specify URS and UDRP 4.4.13 - included a provision regarding linking between obligations and sanctions under data protection laws with how to invoke contractual provisions which may be in conflict with data protection laws. b. Consider input from EPDP Team members on proposed modifications ALAC The whole section was written only with the perspective of registrar purposes and did not include ICANN purposes. We are discussing this as if they are definitive changes when they are only drafted with the registrar point of view. The intro text needs to be more clear regarding the various events that occur over the domain name lifecycle. 4.4.2 - no problem with removing this if appropriate caveats are made in the intro text 4.4.3 - BC is correct that identification needs to be included here. 4.4.5 - this is generally OK, but there needs to be more clarity on "content" - why was that added? (question for ICANN org) 4.4.6 - reference to registry is still relevant 4.4.7 - technical and administrative contacts may be necessary in certain circumstances 4.4.8 - we cannot ignore addressing cybersecurity issues 4.4.9 - we do not provide a framework for law enforcement needs, but we need to support it. 4.4.12 - we cannot leave just these two DRPs 4.4.13 - we should not conflate the compliance use of the data NCSG These edits are real progress, and most are acceptable. These are ICANN purposes, these are not third party legitimate interests. The group appeared to agree to separate ICANN purposes from third party legitimate interests a few meetings ago. 4.4.2 - support removal as this does not belong because it is not a purpose 4.4.3 - support eliminating "identifying" a registered name holder 4.4.4 - support removal - WHOIS is not needed to contact the registrant 4.4.8 - what is a tailored mechanism? if based on the registrar description, this is a framework to address these issues and that is not an ICANN purpose - this is a door through which legitimate interests can enter the process, it indicates what they are and what they are not: consumer protection is correctly removed, law enforcement proposed change is correct - law enforcement needs to use WHOIS to investigate more crime than just cybercrime. Consumer protection is correctly removed as ICANN is not a consumer protection agency. Processing of gTLD registration data for the purposes of law enforcement investigation is not an ICANN purpose. It is not correct that ICANN requires registrars/registries to collect registration data for the purpose of law enforcement. 4.4.9 - this is an access issue, not an ICANN purpose. IPC We talked about whether these are registry/registrar purposes or ICANN purposes. There are several ICANN purposes missing from this list, so there may be additions required. This is a list of purposes for all definitions of processing, and when we decide that access mechanisms should be discussed at a later time, this is a mistake. 4.4.8: what does tailored access mean? If this is an access to 4.4.12, that is a narrow definition of IP interests/rights, and this will need to be addressed. The IPC needs more time to digest this. It is within ICANN's mission to include IP protection and to limit this within 4.4.8 is incorrect. It is unclear what tailored mechanism means. Consumer protection should be added back in as this is part of ICANN's mission. With respect to ICANN purposes that are missing, there are a lot of requirements and obligations there that define the need to collect, use, and process data above and beyond this list - cybersecurity, law enforcement, intellectual property, et.al. Purposes include as part of ICANN's mission - accountability - IP rights holders, etc. 4.4 - with respect to removing specific GDPR language, this is too vague. The purpose of this EPDP is to discuss the temp spec in the context of GDPR. While we may not need to cite GDPR sections repeatedly, we could add "or future applicable laws" 4.4.2 - this shouldn't be removed. This is an important purpose. 4.4.12 - this is too broad - dispute resolution can be used in other contexts. 4.4.13 - we need to keep adequate procedures in place. There is not enough information here re: non-binding and other procedures is too vague. BC The BC needs more time to review these changes. The redlines make the purposes far too narrow from what ICANN's purposes should be. The intro to 4.4 ignores consensus policies that fulfill the mission ICANN has. 4.4.3 - the removal of identifying is not correct. It is important to know who to sue for IP purposes. It is not just the URS and UDRP that we are concerned about. 4.4.8 - GDPR requires specificity on the purposes so taking out consumer protection goes against what the GDPR requires. 4.4.13 - this needs to be broader than monitoring contractual compliance requests. A specific purpose needs to be added here. ICANN uses the information in the security department, and that purpose is not mentioned here. We should look at things from a joint controller perspective. GAC Are we discussing registrar purposes or lawful purpose of processing gTLD data? This group has no mandate to interpret the ICANN mission. 4.4.8 - while not perfect, it could be a potential basis to build upon. Is there a problem putting law enforcement together with other issues - need to confer with other GAC colleagues on this. This section should not be talking about the interests of third parties and what they need for access. This will be discussed at a later date. However, what is appropriate is how it pertains to ICANN's mission. The edits for the intro text is too narrow. RySG The proposed 4.4 is an improvement, but the RySG needs more time to review in order to provide substantive feedback. ISPCP We should not see this as carving in stone a list of purposes. This is a living document and we need to get back to the list of purposes as we move on. ICANN received a letter from the EDPB about conflating ICANN’s purposes with other purposes. One processing activity – the collection of data, for example, may have different purposes pursued by different parties. These purposes need to be supported by a legal basis. One processing activity can have a one purpose for the registrar and a different purpose for ICANN. We should remove the opening clauses and those who think we need to cover additional items need to explicitly state what they shall be. As a starting point, let’s make explicit reference to which clauses in the GDPR we are referring to. We could ask staff to work on a more general version of the text. The overarching purpose of making available domain name registration, making domain names work will fall into the bucket of registrar purposes and ICANN purposes. SSAC Divide 4.4 into three sections: (1) where ICANN acting as a sole controller; (2) where ICANN acts as a joint controller; (3) where ICANN facilitates or enables a third-party framework. An example of an ICANN sole controller purpose is the UDRP c. Agree on next steps EPDP Team Members may continue to send feedback via the list. To aid in the Team’s discussion at the next meeting, Thomas and Benedict will work together on dividing §4.4 into three tranches: (1) where ICANN acting as a sole controller; (2) where ICANN acts as a joint controller; (3) where ICANN facilitates or enables a third-party framework by Monday, September 10. Closing Comments: There is apparent confusion regarding where we are going. With respect to registrar-related purposes in 4.4, the group made several concrete suggestions. Thomas and Benedict to work together on dividing 4.4 into three sections: (1) where ICANN acting as a sole controller; (2) where ICANN acts as a joint controller; (3) where ICANN facilitates or enables a third-party framework by Monday, September 10. 4. Proposed modifications to section 4.4 – introductory paragraph a. Review proposed modification put forward by Alex Deacon and Thomas Rickert b. Consider input from EPDP Team members on proposed modifications c. Agree on next steps 5. Status update on modifications to section 4 – Third Party Legitimate Interests a. revised language for §4.4.2 (Amr Elsadr) b. revised language for §4.4.8 (Alex Deacon & Amr Elsadr) c. revised language for §4.4.9 (Ashley Heineman) 6. Review data matrix formed from RDS work and Thomas’s chart a. High-level overview of chart b. Discuss proposed amendments to Chart c. Agree on next steps 7. Introduction to Appendix A 8. Confirm action items and questions for ICANN Org, if any Feedback on triage survey, if any, is due today. Applications for travel support to ICANN63 in Barcelona are due Thursday, 13 September. Thomas and Benedict to work together on dividing 4.4 into three sections: (1) where ICANN acts as a sole controller; (2) where ICANN acts as a joint controller; (3) where ICANN facilitates or enables a third-party framework by Monday, September 10. Question for ICANN org: 1.Why did ICANN include the term content in 4.4.5? 9. Wrap and confirm next meeting to be scheduled for Tuesday 11 September at 13.00 UTC.)

1 0

Recordings, Attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP held Thursday, 06 September 2018
by Andrea Glandon Sept. 6, 2018

Sept. 6, 2018

Dear all, Please find the attendance and AC chat attached to this email. The MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Thursday, 06 September 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/1AONBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-06sep18… AC Recording: https://participate.icann.org/p5518kreyof/<https://participate.icann.org/p5518kreyof/?OWASP_CSRFTOKEN=81a39a1ebb180a13…> ** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ [community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_…> Thank you. Kind Regards, Andrea Glandon

1 0

Meeting Invitation / Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 11 September 2018 at 13:00 UTC
by Andrea Glandon Sept. 6, 2018

Sept. 6, 2018

Dear all, Non-members can follow the EPDP call taking place on Tuesday’s and Thursday’s at 13:00 UTC via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/1gONBQ Kind Regards, Andrea Glandon

1 0

Re: [Gnso-epdp-team] 4.4.9 (and 4.4.2)
by Alan Greenberg Sept. 6, 2018

Sept. 6, 2018

Thanks Ashley, I strongly support your edits and explicitly support keeping a reference to these issues in 4.4. GDPR Article 6.1(f) explicitly allows reference to the needs of third parties and this certainly qualifies. To the extent necessary, I believe that we need to put language somewhere that explains why this is driven by our Bylaw requirement to provide a stable and resilient DNS which I believe has to map to a trusted DNS. Alan At 05/09/2018 04:46 PM, Heineman, Ashley wrote: >Dear all. Please find below proposed edits to 4.4.9, which should >be considered initial input as further discussion is welcomed. Also >included below are some recommended edits to 4.4.2, which I realize >is being reviewed/modified by someone else. > >Regarding 4.4.9, the proposed text is: > >Enabling the prevention and detection of cybercrime and illegal DNS >abuse to promote the resilience, security, stability and/or >reliability of the DNS and the Internet. Enabling the prevention of >unlawful conduct to meet the legitimate needs of law enforcement and >public authorities promoting consumer trust in the DNS and the >Internet and safeguarding registrant data. > >After a lot of deliberation and thought, we decided that this text >should remain under section 4.4 (not be moved) as this section is a >list of ICANN's and the Contracted Parties' legitimate purposes for >processing data and accordingly we want a reference to this purpose >as we believe it influences/touches upon at least two stages of >their processing (collection and disclosure). > >That being said, let it be clear that we are not seeking the >collection of additional WHOIS data elements. However, we do want >to ensure that the collection of existing WHOIS data fields continue >to be maintained. > >Further, it is our view that the collection and disclosure of >information, as it aligns with efforts to combat cybercrime and >other illegal DNS abuse, is fully consistent with ICANN bylaws and >therefore fits within ICANN's purposes. (see specific bylaw references below). > >Lastly, our initial text reflects a concerted effort not to conflate >ICANN's purposes with that of LEA/government authorities. It is our >view that the interests and lawful basis of third parties (such as >LEA/government authorities) should be articulated elsewhere as appropriate. > >ICANN Bylaws (excerpts) >Section 1.2. COMMITMENTS AND CORE VALUES >In performing its Mission, ICANN will act in a manner that complies >with and reflects ICANN's Commitments and respects ICANN's Core >Values, each as described below. > >(a) COMMITMENTS >*** >(i) Preserve and enhance the administration of the DNS and the >operational stability, reliability, security, global >interoperability, resilience, and openness of the DNS and the Internet. > >Section 4.6. SPECIFIC REVIEWS >*** > (e) Registration Directory Service Review > >(ii) The Board shall cause a periodic review to assess the >effectiveness of the then current gTLD registry directory service >and whether its implementation meets the legitimate needs of law enforcement, >promoting consumer trust and safeguarding registrant data. > > >Regarding 4.4.2, we offer the following edits for consideration. We >believe this provides the necessary specificity required under GDPR: > >Providing collection and disclosure of accurate, reliable, and >uniform Registration Data based on lawful basis, consistent with >GDPR, to ensure resilience, security, and/or stability of the >DNS. In the case of legitimate interest as a basis, collection and >disclosure must not outweigh the fundamental rights of relevant data subjects. > >_______________________________________________ >Gnso-epdp-team mailing list >Gnso-epdp-team(a)icann.org >https://mm.icann.org/mailman/listinfo/gnso-epdp-team

2 1