Diploma Thesis

to be awarded the degree of Magister Juris at the University of Graz, Austria

An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG

submitted by Ing. Matthias Markus Hudobnik

Name of the supervisor: Univ.-Prof. i.R. Mag. Dr. Wolfgang Benedek Department: Institute of International Law and International Relations

Graz, June 2019

Authors Declaration Unless otherwise indicated in the text or references, or acknowledged above, this diploma thesis is entirely the product of my own scholarly work. Any inaccuracies of fact or faults in reasoning are my own and accordingly I take full responsibility. This thesis has not been submitted either in whole or part, for a degree at this or any other university or institution. This is to certify that the printed version is equivalent to the submitted electronic one.

______Ing. Matthias Markus Hudobnik Graz, June 2019 Preface and Acknowledgements

The idea to write about WHOIS1 and the GDPR started in March 2017 during my participation in the NextGen@ICANN program at the ICANN58 meeting in Copenhagen, where I was first confronted with this topic. I have remained interested ever since. Subsequently I participated in further meetings: as a Fellow in the European Dialogue on Internet Governance (EuroDIG) 2017 in Tallinn and the 11th European Summer School on Internet Governance (EuroSSIG) in Meissen; as an Ambassador in the NextGen@ICANN60 program in Abu Dhabi; as a Fellow in the EuroDIG 2018 in Tbilisi, as well as the ICANN63 meeting in Barcelona, and the RIPE77 meeting in Amsterdam. Furthermore, I have joined all the relevant working groups and mailing lists, and also participated in ICANN’s GDPR webinars, as well as ICANN’s online courses to get a wealth of insight into this complex policy process within the Internet ecosystem. In June 2019, I will present a paper relating to my diploma thesis about the future of WHOIS, at the 34th International Conference on ICT Systems Security and Privacy Protection in Lisbon.

First of all, I would like to express my sincere gratitude to Univ.-Prof. i.R. Mag. Dr. Wolfgang Benedek for being my supervisor and supporter for many years. His professional guidance, passion, patience, and immense knowledge have been a tremendous support through my personal journey.

Besides my supervisor, I would like to thank Matthias C. Kettemann for questioning my ideas, providing constructive feedback, and pushing me forward. It has been a great honor and pleasure discussing Internet Governance issues with him!

I also would like to thank Clément Genty, not only for the strong connection, but also for his useful feedback, the numerous talks, and discussions about Internet Governance and important topics beyond as well as my dudes from the GFW & Könige – I love you guys!

A special thank you goes to Jess including M & D for always enduring my moods, nagging and providing me with both feedback and moral support over the course of drafting this diploma thesis. Talking with her about matters related to the topic of this diploma thesis helped me immensely to keep on track, and she always found time to proof-read my thesis and gave me valuable feedback. Thank you so much for everything!

Last but certainly not least, I would like to thank my family. Your endless love and support have made me who I am today!

1 Is pronounced as ‘who is’ e. g., the domain holder or in charge of it and is not seen as an ‘acronym.’ Table of contents 1 Introduction ...... 1

1.1 Outline of the diploma thesis ...... 3

1.2 Methodology of the diploma thesis ...... 3

2 Definitions and background ...... 5

2.1 What is ICANN? ...... 5

2.2 What is the WHOIS system? ...... 6

2.2.1 History ...... 8

2.2.2 Technical overview ...... 12

2.2.3 Policy agreements ...... 13

2.3 Definitions of the parties involved ...... 16

2.3.1 Generic Top-Level Domain registry operator ...... 17

2.3.2 Registrar ...... 18

2.3.3 Registrant...... 18

2.3.4 Reseller ...... 18

2.3.5 Internet Corporation for Assigned Names and Numbers ...... 18

2.3.6 Registry/Registrar Data Escrow Agent ...... 18

2.3.7 Emergency Back-End Registry Operator ...... 19

3 Description and application of the General Data Protection Regulation ...... 19

3.1 General provisions and principles ...... 19

3.1.1 Territorial scope ...... 19

3.1.2 Definitions of various terms ...... 20

3.1.3 Data processing principles ...... 21

3.1.4 Legal grounds and lawfulness of processing ...... 22

3.2 European Data Protection Board/Article 29 Data Protection Working Party ...... 24

4 Compliance Models ...... 25

4.1 GDPR Compliance Models and community input ...... 25

4.1.1 Data collection, processing, and retention ...... 26

4.1.2 Scope of applicability ...... 32

4.1.3 Layered/tiered access to public WHOIS data ...... 34

______i 4.1.4 Layered/tiered access to non-public WHOIS data ...... 40

4.1.5 Conclusion ...... 44

4.2 Temporary Specification for gTLD Registration Data ...... 49

4.2.1 Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data ...... 52

4.2.2 Conclusion ...... 61

5 Case, ICANN v. EPAG Domainservices GmbH ...... 64

5.1 ICANN’s Motion for the Issuance of a Preliminary Injunction ...... 64

5.1.1 EPAG’s protective letter ...... 68

5.2 Court Order from the Regional Court of Bonn on Application for Preliminary Injunction 70

5.3 ICANN’s Immediate Appeal ...... 72

5.3.1 Lawfully collection of Admin-C and Tech-C data as well as lack of obligation to collect personal data ...... 72

5.3.2 Lawfully collection of Admin-C and Tech-C data even if it is personal data ...... 73

5.3.3 EPAG’s Comments on ICANN’s Immediate Appeal ...... 77

5.4 Court Order from the Regional Court of Bonn in the Preliminary Injunction Proceedings ...... 83

5.5 ICANN’s Supplemental Submission to the Higher Regional Court of Cologne ...... 84

5.5.1 EPAG’s Comments on ICANN’s Supplemental Submission ...... 87

5.6 Order from the Higher Regional Court of Cologne Regarding ICANN’s Immediate Appeal 88

5.7 ICANN’s Plea of Remonstrance ...... 89

5.7.1 EPAG’s Comments on ICANN’s Plea of Remonstrance ...... 90

5.8 Order from the Higher Regional Court of Cologne Regarding ICANN’s Plea of Remonstrance ...... 92

5.9 Conclusion ...... 93

5.9.1 Is the further collection and storage of personal data - of the administrative and technical contact so-called Admin-C and Tech-C - besides the data of the registrant as stipulated via the 2013 RAA, lawful under the GDPR? ...... 94

5.9.2 Are the processing purposes in the Temp Spec for the data of the Admin-C and Tech-C sufficiently specified? ...... 95

______ii 6 General conclusion and outlook ...... 96

Bibliography ...... i

Primary Sources ...... i

Table of legal frameworks, agreements, resolutions, and recommendations ...... i

Table of cases ...... ii

Secondary Sources ...... iii

Books ...... iii

Background papers, research papers, and working papers ...... iv

Other sources and documents ...... ix

______iii Table of figures Figure 1: A DNS-tree example of www.hudobnik.at...... 5 Figure 2: The four nodes and the ARPANET in December 1969 ...... 8 Figure 3: The ARPANET in June 1970 ...... 9 Figure 4: The ARPANET in March 1972 ...... 9 Figure 5: The ARPANET in July 1977 ...... 9 Figure 6: Logical map of the ARPANET in March 1977 ...... 10 Figure 7: A simple WHOIS query structured in four stages...... 13 Figure 8: The principal journey of data and the involved parties...... 17 Figure 9: registration process and the involved parties...... 17 Figure 10: Overview of the different GDPR Compliance Models ...... 26

______iv Table of tables Table 1: Data collection, processing, and retention ...... 27 Table 2: Scope of applicability ...... 32 Table 3: Public WHOIS...... 35 Table 4: Non-Public WHOIS ...... 41 Table 5: Calzone Model v. Temp Spec ...... 50 Table 6: Recommendation 5, the registrars collected data elements ...... 54 Table 7: Recommendation 7, transfer of data elements from registrar to registry ...... 55 Table 8: Recommendation 8, transfer registrars to the data escrow agent ...... 56 Table 9: Recommendation 8, transfer registries to the data escrow agent ...... 56 Table 10: Recommendation 10, requirements for processing personal data in public RDDS .. 57 Table 11: Recommendation 20, purposes, processing activities, parties, and lawful basis ..... 58

______v List of Abbreviations AFRINIC African Network Information Centre ALAC At-Large Advisory Committee APNIC Asia Pacific Network Information Centre APWG Anti-Phishing Working Group ARIN American Registry for Internet Numbers ARPANET Advanced Research Projects Agency Network ASN Autonomous System Numbers BC Business Constituency ccTLDs country code Top-Level Domains CNNIC China Internet Network Information Center DEA Data Escrow Agent DNS Domain Name System DNSSEC Domain Name System Security Extensions DPA Data Protection Authority EBERO Emergency Back-end Registry Operator EC European Commission EDPB European Data Protection Board EDPS European Data Protection Supervisor EEA European Economic Area EPDP Expedited Policy Development Process EuroDIG European Dialogue on Internet Governance EuroSSIG European Summer School on Internet Governance gTLDs generic Top-Level Domains GAC Governmental Advisory Committee GDPR General Data Protection Regulation GNSO Generic Names Supporting Organization HTTP(S) Hypertext Transfer Protocol (Secure) IANA Internet Assigned Numbers Authority ICANN Internet Corporation for Assigned Names and Numbers IETF Internet Engineering Task Force IP Internet Protocol IPC Intellectual Property Constituency IRT Implementation Review Team IWGDPT International Working Group on Data Protection in Telecommunications LACNIC Latin American and Caribbean Network Information Centre NTIA National Telecommunications and Information Administration, United States Department of Commerce

______vi NSI Inc. RA Registry Agreement 2013 RAA 2013 Registrar Accreditation Agreement RDDS Registration Data Directory Services RFC Request For Comments RIPE NCC Réseaux IP Européens Network Coordination Centre RIR Regional Internet Registry RDAP Registration Data Access Protocol RNAP Restored Name Accuracy Policy SRI-NIC Stanford Research Institute - Network Information Center TDRP Transfer Dispute Resolution Policy Temp Spec Temporary Specification for gTLD Registration Data TLDs Top-Level Domains TTCI Translation and Transliteration of Contact Information TWPD Thick WHOIS Policy Development UDRP Uniform Domain Name Dispute Resolution Policy WDRP WHOIS Data Reminder Policy WMRP WHOIS Marketing Restriction Policy WP29 Article 29 Data Protection Working Party WWW World Wide Web

______vii An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

1 Introduction 2019 marks the 30th anniversary of the Internet, and without doubt, the Internet has become an impactful and influential medium in the context of social and economic changes worldwide, with a user increase of nearly 900 percent, from 400 million in 2000 to more than 4 billion today.2 The reason that a user reaches a website on the Internet is the globally-unique address, and the standardized technical communication between the Internet devices via the Internet protocol suite (e. g., application, transport, Internet and link layer).3 In short, the Internet Protocol (IP) is in the Internet layer; the Transmission Control Protocol (TCP) is in the transport layer; and the Domain Name System (DNS) is in the application protocol layer. In a nutshell, the DNS is crucial in order to translate domain names into IP addresses and vice versa. Thus, IP addresses identify an Internet device e. g., a computer on the Internet and are necessary to find websites, but these IP addresses are inconvenient to remember and are not personalized. The result was the establishment of the DNS as a name structure.4 The WHOIS protocol is a “TCP-based transaction-oriented query/response protocol that is widely used to provide information services to Internet users,”5 including inter alia, personal information of registered domain names. Previously, the public WHOIS databases were a primary instrument for personal information gathering across different professions (e. g., journalists, law enforcement agencies, IP rights holders, and cyber security researchers/investigators) and for various reasons. Currently, data protection laws have become more public and influential in the debate over the regulation of the Internet, not least because of the increased effort at a European level, through the General Data Protection Regulation (GDPR). Previously, the general publication of the personal information of registered domain names in the public WHOIS databases was common practice, but since the GDPR came into force on 25 May 2018, this practice has become unlawful. The main aim of this diploma thesis is to assess the legal challenges under the GDPR concerning the registration directory services for generic top-level domains (gTLDs), the so- called WHOIS databases and the present WHOIS database Policy Development Process. The Internet Corporation for Assigned Names and Numbers (ICANN), gTLD registry operators, and registrars offer services through , WHOIS lookup services, and domain- name dispute settlement mechanisms to subjects in the European Union and are either individual or joint data controllers or processors. However, the GDPR also applies to controllers and processors who are not established in the European Union when their data processing activities are related to “(a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or (b) the

2 Cf Internet Society, ‘Global Internet Report 2019’, pp. 13-14, available at accessed 30 April 2019. 3 Cf Wikipedia, ‘Internet Protocol Suite’, available at accessed 30 April 2019. 4 Cf Nic.at, ‘DNS & DNSSEC’, available at accessed 30 April 2019. 5 See Leslie Daigle, ‘RFC 3912 - WHOIS Protocol Specification’, September 2004, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 1 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______monitoring of their behavior as far as their behavior takes place within the Union.”6 Thus, ICANN, gTLD registry operators, and registrars are required to follow the rules established by the EU. These circumstances raise difficult questions about compliance. In this context, it is important to note that very little research has actually been conducted on this topic, because of how recent the GDPR is. The following research questions will be analyzed: Generally, how can access to crucial information and protected data in the WHOIS system be ensured? Specifically, which of the Compliance Models fulfill essential criteria such as: ‘data collection, processing, and retention’, ‘applicability’, and ‘tiered/layered access to WHOIS data?’ These follow-up questions will answer the several criteria classifications:  How can the purpose and lawfulness of processing activities be determined?  What specific data of the registrant is collected?  What data can be transferred from the registrar to the registry and the data escrow agent?  How long should the period of data retention for the registrar, registry, and the escrow agent be?  What is the scope of applicability for the different possible Compliance Models?  How is the access to public/non-public WHOIS data to be organized, for example via accreditation program or a tiered/layered access model? Explicitly, in the context of the litigation ICANN v. EPAG, the previously stated theoretical approaches were judged through the practical case law and the following legal questions will be analyzed:  Is the further collection and storage of personal data - of the administrative and technical contact so-called Admin-C and Tech-C - as well as the data of the registrant as stipulated via the 2013 RAA, lawful under the GDPR?  Are the processing purposes in the Temp Spec for the data of the Admin-C and Tech-C sufficiently specified? The author hypothesizes that firstly, the GDPR was the catalyst for the adoption of the Compliance Models and subsequently, the modification process of the previous WHOIS database publication practices. Secondly, the litigation ICANN v. EPAG has potentially influenced the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec), especially, in the context of Admin-C and Tech-C data. Thirdly, there is a necessity for a system of standardized access to non-public registration data, adjusted with the technical implementation process, which is also lawful under specific data protection laws.

6 See Art.3 (2) lit. a) and b) of the Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), 33, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 2 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

1.1 Outline of the diploma thesis In addition to the introduction, this diploma thesis is divided into five major parts. The chapter- structure is bottom-up and content-based. The starting point is the theoretical part e. g., the relevant definitions, and background to the more complex practical issues of the Compliance Models in conjunction with the related legal questions of the policy documents and the lawsuit. Chapter 2 will explain essential backgrounds e. g., ICANN’s mission and purpose, “to ensure a stable, secure, and unified global Internet.”7 Furthermore, it will clarify the WHOIS system, its history, technical overview, usage, and policies. Moreover, it will describe the essential parties in the Internet ecosystem e. g., what a registry operator and registrar is, as well as registrant, reseller, ICANN, data escrow agent, and EBERO. Chapter 3 will cover the application of the GDPR, the general provisions, and principles and the role of the Article 29 Data Protection Working Party, which is the present European Data Protection Board. Chapter 4 will address the different legal analyses and Compliance Models of the various community stakeholders in the multistakeholder ecosystem of ICANN, and will highlight their advantages and disadvantages. Also, it will explore the following policy documents: the Temporary Specification for gTLD Registration and the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data. Chapter 5 will comment on the current legal litigation between ICANN and the German registrar EPAG Domainservices GmbH, where ICANN asked the court for assistance in interpreting the GDPR concerning ICANN’s agreements with the registrar. ICANN filed legal action to preserve the WHOIS data collection, so that such data is still available to parties that demonstrate legitimate reasons to access it. Finally, the diploma thesis will draw a line between the Compliance Models, the EPDP on the Temp Spec and the litigation, and will give an outlook based on the current EPDP on the Temp Spec. Finally, the author will refer to the three hypotheses and demonstrate whether they are fulfilled or not, and will debate future issues related to this topic.

1.2 Methodology of the diploma thesis This diploma thesis analyzes the current WHOIS directory Policy Development Process under the GDPR and presents the key arguments and parties involved. The primary resources are the policy documents of various stakeholder groups in the context of the WHOIS system, that were involved in the Policy Development Process, available on ICANN’s website. Thus, the Policy Development Process of the WHOIS directory services is still ongoing. Therefore, the present diploma thesis does not claim to be exhaustive in terms of the content and structure of the

7 See ICANN, ‘Welcome to ICANN!’, available at accessed 30 April 2019.

______Matthias Markus Hudobnik 3 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______topic. Primarily, the diploma thesis focuses on the Compliance Models as well as the litigation ICANN v. EPAG. The author aims to address the most significant issues arising from this case in light of the WHOIS system. The existing legal/policy framework including the case law, guidelines, principles, and the actual policies in respect of the WHOIS data, are examined. The scientific methods that are used meet the requirements and aims of the work. Beginning with chapter ‘Definitions and background,’ the author primarily uses a descriptive method to define the relevant terms and insights e. g., ‘What does ICANN do?’ ‘What is the WHOIS system,’ ‘Definitions of the parties involved.’ In the third chapter, the author utilizes a comparative as well as an analytical methodology to scrutinize, for example, the ‘Description and application of the GDPR,’ ‘General provisions and principles,’ and the tasks of the ‘European Data Protection Board/Article 29 Data Protection Working Party.’ The fourth chapter, ‘Compliance Models,’ and its subchapters apply a comparative as well as an analytical methodology to oppose the various models on three essential criteria such as: ‘data collection, processing and retention,’ ‘applicability’ and ‘layered/tiered access to WHOIS data.’ Subsequently, the different characteristics of the models are matched, analytically assessed, and potential solutions are already mentioned in this chapter. Additionally, the author analyzes the Temporary Specification for gTLD Registration Data and the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data. The chapter ‘Case, ICANN v. EPAG Domainservices GmbH’ draws on the outcomes of the court proceedings of the Regional Court of Bonn and the Higher Regional Court of Cologne by using an analytical methodology. Appropriately, the author applies the concepts of general legal interpretation e. g., analogy, functionality, and teleology, if necessary, to present the existing case law. Moreover, the author examines ICANN’s preliminary injunction, EPAG’s protective letter, the court order of the injunction from the Regional Court of Bonn, and the relevant appeal documents of the parties including the court order of the Regional Court of Bonn. Furthermore, ICANN’s supplemental submission to the court, EPAG’s comments on it, the order from the Higher Regional Court of Cologne, and ICANN’s plea of remonstrance are also analyzed in depth. Finally, the author concludes the diploma thesis by giving a scientific analysis of this topic, an outlook on Phase 2 of the EPDP on the Temp Spec and offers solutions to crucial issues (e. g., access to non-public registration data, Registration Data Access Protocol) for the future. The general conclusion summarizes the final results of the conclusions to each respective chapter, and explores the effects of the GDPR and the litigation on the EPDP on the Temp Spec, as well as examining the commonalities and differences of the compared Compliance Models. The diploma thesis is based on existing policy documents, guidelines from several stakeholder groups, the law, and contains pertinent policy developments and documents in terms of the WHOIS directory services until 30 April 2019.

______Matthias Markus Hudobnik 4 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

2 Definitions and background In order to recognize the WHOIS system as a whole, it is essential to know some of the background and the definitions beforehand. Firstly, this chapter explains ICANN’s mission and purposes as well as some historical milestones of the organization itself. Secondly, it declares the WHOIS system as a whole, including the history, technical overview, and the crucial policy agreements related to it. Thirdly, it defines the essential involved parties in the Internet ecosystem, namely registry operator, registrar, registrant, reseller, ICANN, data escrow agent, and EBERO.

2.1 What is ICANN? Nowadays, the Internet Corporation for Assigned Names and Numbers (ICANN) has become fundamental in the Internet ecosystem for the Internet’s stability, security, as well as the coordination and support of the Internet’s unique identifiers e. g., names and numbers to find anyone on the Internet.8 ICANN’s mission plays a vital role in supporting and promoting the consensus-based bottom-up policy process overall Internet communities in the various stakeholder groups.9 ICANN, a worldwide multistakeholder organization, was established in 1998 by the Department of Commerce National Telecommunications and Information Administration (NTIA).10 The internationally structured and not-for-profit corporation has various tasks e. g., the management of generic (dot com, dot info, dot org, dot net) and country code (dot at, dot de, dot fr, dot nl) Top-Level Domains including the management of the Domain Name System (DNS) Root Server functions, address space allocation for the Internet Protocol, and protocol identifier assignment. The nature of the DNS is to convert the typed-in domain name into an Internet Protocol (IP) address.11

Figure 1: A DNS-tree example of www.hudobnik.at.

8 Cf ICANN, ‘Welcome to ICANN!’ (n 7). 9 Cf ICANN Archive, ‘ICANN | Archives’, available at accessed 30 April 2019. 10 Cf ICANN Wiki, ‘ICANN’, available at accessed 30 April 2019. 11 Cf ICANN, ‘ICANN | Archives’ (n 9). ______Matthias Markus Hudobnik 5 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Until March 2014, the NTIA was contractually bound by Internet Assigned Numbers Authority (IANA) and their related bodies to maintain these critical technical capabilities.12 The essential IANA functions are the DNS root zone management, the protocol registries, the allocation of IP addresses and the Autonomous System Numbers (ASN) in the form of blocks to the Regional Internet Registries (RIRs). They are e. g., American Registry for Internet Numbers (ARIN), Réseaux IP Européens Network Coordination Centre (RIPE NCC), Asia Pacific Network Information Centre (APNIC), Latin America and Caribbean Network Information Centre (LACNIC), and African Network Information Centre (AFRINIC).13 In the history of ICANN, the IANA functions transitions to the global Internet community by not renewing the contract obligations with NTIA on 30 September 2016 have been thought of as a significant factor and strong statement for improving the multistakeholder model.14 Central to the transitions is the fact that ICANN is globally, and solely, coordinating the DNS as well as being the only contractor of the IANA functions and organization to foster the multistakeholder model of the various global stakeholders.15 Even so, the reformation of the WHOIS system under the GDPR has received considerable attention and critical discussions within the community. This consideration could be seen as another milestone in the history of ICANN when the ongoing Policy Development Process will be accomplished in the future. ICANN organization has assessed the potential impacts of the GDPR based on their bylaws with the global stakeholder community and their contracted parties, including registries and registrars. The main aspects reviewed are: the purposes of the processing, displaying, and retention of the registrant’s data in the WHOIS directory services and different Compliance Models.16

2.2 What is the WHOIS system? The term WHOIS (means also Who is?) is widely associated with various services e. g., the WHOIS protocol for network-exchange via client and server or the common WHOIS databases of registries or registrars or the collection and processing of WHOIS data of registrants by registries and registrars under ICANN’s agreements.17 This subchapter focuses on the WHOIS registration directory services as a whole, which are utilized to query databases in order to gain information about the registration of a domain name and other information regarding the domain holder.18 In short, the registrant of the

12 Cf NTIA Office of Public Affairs, ‘NTIA Announces Intent to Transition Key Internet Domain Name Functions’, available at accessed 30 April 2019. 13 Cf ICANN Wiki, ‘Internet Assigned Numbers Authority’, available at accessed 30 April 2019. Cf also ICANN Wiki, ‘Regional Internet Registry’, available at accessed 30 April 2019. 14 Cf ICANN, ‘Stewardship of IANA Functions Transitions to Global Internet Community as Contract with U.S. Government Ends’, available at accessed 30 April 2019. Cf also Sally Shipman Wentworth, ‘Can We Expand the Multistakeholder Model for Internet Governance? A Feasibility Report’, 27 October 2017, available at accessed 30 April 2019. Cf also DiploFoundation, ‘Multistakeholderism in IGF Language’, available at accessed 30 April 2019. 15 Cf NTIA, ‘Announces Intent to Transition Key Internet Domain Name Functions’ (n 11). 16 Cf ICANN organization, ‘Interim Model for Compliance with ICANN Agreements and Policies in Relation to the European Union’s General Data Protection Regulation –WORKING DRAFT FOR CONTINUED DISCUSSION’, The ‘Cookbook’, 8 March 2018, 6, available at accessed 30 April 2019. 17 Cf Steve Sheng, Dave Piscitello, Liz Gasster, ‘Inventory of WHOIS Service Requirements - Final Report’, 29 July 2010, 5, available at accessed 30 April 2019. 18 Cf ICANN WHOIS, ‘WHOIS Search’, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 6 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______domain name has to provide his or her personal information which is recognized as ‘WHOIS data’ in order to buy a domain name.19 WHOIS is an Internet protocol, initially stated in (Request For Comments) RFC 812 and was established for a wide range of (formerly) free public available lookup services via port 43 or the WWW port 80 for HTTP or 443 for HTTPS. In short, to query the registrant’s personal information (e. g., name, address, e-mail, phone number, dates), name-servers, and the contact details of the administrative and technical contact so-called Admin-C and Tech-C.20 This Internet protocol has played a significant role since the 1980s - RFC 3912 is the present specification developed by the Internet Engineering Task Force (IETF).21 In recent years, there has been an increasing interest in identifying Internet user behind a registered domain name for various reasons (e. g., transformation of the concrete domain name, intellectual property and trademark protection, law enforcement issues) and across different stakeholders and disciplines (e. g., individuals, businesses, public sector, organizations).22 A WHOIS request is possible to be submitted by any Internet user who wishes to gain more information about the registrant behind a website.23 One of the main obstacles that have been present ever since the GDPR came into force is the collection and processing of personal data of registrants by registries and registrars under ICANN’s Registry Agreements (RA) and 2013 Registrar Accreditation Agreements (2013 RAA). Thus, an ICANN accreditation is compulsory to become a registrar - the equivalent applies to registry operators of gTLDs.24 There is an urgent need to address the purpose and lawfulness of the processing activities caused by registries and registrars, who are contractually obliged to collect and process the WHOIS data and make it publically available under ICANN’s current existing agreements. When investigating the processing activities, there is an ongoing concern within the prevailing transfer of personal data for numerous causes (e. g., administration purposes, to prevent and protect against errors of registries or registrars) in between registries and registrars as well as data escrow agents. The lack of an effective WHOIS service can cause problems to fulfill the previously mentioned services of registries or registrars in the same extent and quality due to implementation of several strict GDPR provisions.25 Therefore, on 17 May 2018, the ICANN Board adopted a “single, unified interim model that ensures a common framework for handling registration data, including registration directory services” named Temporary Specification for gTLD Registration Data to ensure “the continued availability of WHOIS to the greatest extent possible” although “maintaining the security and stability of the Internet’s system of unique identifiers.”26 On 27 January 2019, the ICANN

19 Cf ibid. 20 Cf ICANN WHOIS, ‘Technical Overview’, available at accessed 30 April 2019. 21 Cf Daigle, ‘RFC 3912 - WHOIS Protocol Specification’ (n 5). 22 Cf ICANN WHOIS, ‘About WHOIS’, available at accessed 30 April 2019. 23 Cf ICANN WHOIS, ‘WHOIS Primer’, available at accessed 30 April 2019. 24 Cf ICANN, ‘About WHOIS’ (n 22). 25 Cf ICANN, ‘The Cookbook’ (n 16) pp. 5-6. Cf also Clément Genty, ‘Gouvernance de l’Internet et Économie Mondiale : Proposition d’un Modèle d’Évaluation de la Valeur d’un Nom de Domaine en tant qu’Actif Immatériel’, 23 April 2019, 81, available at accessed 30 April 2019. 26 See ICANN, ‘Data Protection/Privacy Issues’, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 7 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Board reaffirmed the Temporary Specification for a fourth time, which is required every 90 days, stated in the RA and 2013 RAA until the process of adopting final policies is finished.27 However, these rapid changes based on the GDPR are having a severe effect on ICANN’s contractual compliance with registries and registrars under their existing consensus policies and agreements.28

2.2.1 History

In December 1969, the US Department of Defense’s Advanced Research Projects Agency (ARPA) connected four computer network nodes, the so-called ‘ARPANET’ at the University of California, the Stanford Research Institute, the UC Santa Barbara, and the University of Utah.29

Figure 2: The four nodes30 and the ARPANET in December 196931

27 Cf ICANN, ‘ICANN Board Reaffirms Temporary Specification for gTLD Registration Data’, available at accessed 30 April 2019. 28 Cf ICANN, ‘The Cookbook’ (n 16) 6. 29 Cf Scientific American, ‘Early sketch of ARPANET's first four nodes’, available at accessed 30 April 2019. 30 See Scientific American, ‘Early sketch of ARPANET's first four nodes’ (n 29). 31 See Fibel, ‘ARPANET’, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 8 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Figure 3: The ARPANET in June 197032

Figure 4: The ARPANET in March 197233

Figure 5: The ARPANET in July 197734

32 See ibid. 33 See Fibel, ‘ARPANET’, available at accessed 30 April 2019. 34 See ibid. ______Matthias Markus Hudobnik 9 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Figure 6: Logical map of the ARPANET in March 197735

At this time, the ‘Internet’ (ARPANET) consisted merely of multi-user mainframes or mini- computers operated by the universities or research institutions interconnected with dedicated telecom lines to each other. Therefore, all users in this minor network knew each other, and there was no necessity for a database to preserve contact information e. g., names, telephone numbers, and postal addresses. The researchers themselves wrote these details more or less on a paper or spreadsheet. One of the main obstacles of this early stage was the frequent loss of connectivity as outages, which were easily solvable by looking up in the list of network users and initiating a telephone call to solve the connectivity problems. As the graphic above shows, the network grew rapidly in 1977, but academia and research institutions still dominated it; furthermore, connectivity problems were still prominent. As a result, there was a mitigation process of the devices in the network from IP addresses to hostnames, where each specific device related to a hostname.36 This circumstance led to challenges in preserving the contact information of all users with the previous contact information system.37 The result of this was the development of a reverse telephone book maintained by the Stanford Research Institute - Network Information Center (SRI-NIC) which translated the received IP address - which contained of the source and

35 See Computerhope, ‘ARPANET LOGICAL MAP, March 1977’, available at accesses 30 April 2019. 36 Cf David Conrad, ‘What is Whois’, GAC: Technical Seminar on WHOIS and Data Protection/Privacy Issues, ICANN63 meeting, 21 October 2018, pp. 5-6, available at accessed 30 April 2019. 37 Cf ICANN, ‘WHOIS High-Level Technical Brief’, 20 April 2018, 1, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 10 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______destination address - and hostname into the peoples contact information to identify the responsible person for the particular IP address of that device. In other words, this new invented reverse telephone book became the so-called WHOIS protocol.38 It was initially developed in 1982 and is a simple client-server query-response protocol that “provides online directory look-up equivalent to the ARPANET Directory.”39 In 1991, there was an increase in interest in using the Internet, which became a source of information via the enormous growth of the content generated by users. Subsequently, the SRI-NIC system was not designed for this large number of users and contact information, but this was instrumental for establishing a further centralized NIC system so-called ‘Inter-NIC’ with all the contact information for the allocation of names and addresses. As a result, between 1993 and 1994, multiple address registries and multiple name registries across multiple independent organizations were created.40 It is necessary to mention here that, historically, there were no registration costs for registrants of dot com, dot net, and dot org domains because of the strict contractual policy of the US National Science Foundation and the ‘InterNIC’ which was initially the SRI-NIC and afterward the Network Solutions Inc. (NSI). Nowadays, it is the other way round, and almost all registrants are obliged by contractual agreements with the registries or registrars to pay a fee for the registration of the domain name and the associated services.41 Retrospectively, between 1993 and 1994, RIPE NCC and APNIC as two of the five Regional Internet Registries (ARIN, AFRINIC, and LACNIC) arose as the distributors of the IP address databases, extracted from the InterNIC system, and operate them independently. Similarly, the development of the domain name system and their databases, which can be divided into the creation of ccTLDs and gTLDs.42 Concerning ccTLDs, the databases are maintained by ccTLD- operators. In terms of the gTLDs, the registries and registrars are contractually bound by ICANN to make a specific set of registration data available in the WHOIS databases.43 Lastly, all named databases have one thing in common, which is the IANA function; however, IANA only contains referral information.44 Compared to the current situation, ’s Domain Name Industry Report from the first quarter of 2019 shows that there are approximately 351.8 million domain name registrations across all TLDs and there was a rise of approximately 3.1 million domain name registrations, compared to the fourth quarter of 2018. Throughout this report, Verisign also mentions that, at the end of the first quarter of 2019, there were approximately 156.8 million ccTLD domain name registrations which are a rise of

38 Cf Conrad, ‘What is Whois’ (n 36) 6. 39 See Ken Harrenstien and Vic White, ‘RFC 812 - NICNAME/WHOIS’, 1 March 1982, available at accessed 30 April 2019. 40 Cf Conrad, ‘What is Whois’ (n 36) 7. 41 Cf ICANN, ‘WHOIS High-Level Technical Brief’ (n 37) 2. 42 Cf Conrad, ‘What is Whois’ (n 36) pp.7-8. 43 Cf ICANN, ‘Technical Overview’ (n 20). 44 Cf Conrad, ‘What is Whois’ (n 36) 8. ______Matthias Markus Hudobnik 11 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______approximately 2.5 million domain name registrations compared to the fourth quarter of 2018.45

2.2.2 Technical overview

Chapter 2.2 illustrates the general explanation of the WHOIS system itself. As previously described in Chapter 2.2.1 the WHOIS protocol is a client-server query-response protocol initially established in RFC 812 as “NCP/TCP transaction based query/response server, running on the SRI-NIC machine, that provides netwide directory service to ARPANET users”46 in 1982 and updated in RFC 954 in 1985.47 A key aspect in the context of the WHOIS service is that it is commonly classified into four categories: clients, servers, databases, and registration data.48 It is noteworthy that the WHOIS service is often spuriously seen as a single central maintained database, which is wrong.49 In fact, the domain name system includes approximately 2,500 different WHOIS databases in various locations stored with WHOIS registration data administered via multiple autonomous parties (e. g., registries and registrars) linked to the WHOIS protocol finally updated in RFC 3912 as “TCP-based transaction-oriented query/response protocol that is widely used to provide information services to Internet users”50 in 2004.51 These WHOIS databases are divided into several groups of databases: a) WHOIS databases for the root zone, b) WHOIS databases related to TLDs and, c) WHOIS databases related to second-level domains where their distribution is done by the DNS namespace via a hierarchical order.52 For the sake of completeness, it should be mentioned here that the category of distributed databases of IP addresses and autonomous system numbers are principally operated by the RIRs, not directly related to the WHOIS databases of the domain name system and out of the scope of this subchapter. There are several significant distinctions in the WHOIS databases to make: Firstly, there are a) the WHOIS databases for the root zone and, b) the WHOIS databases related to the TLDs.53 The WHOIS databases for the root zone contains the referral contact information of the Top-Level Domain names. The WHOIS databases related to the TLDs can be divided into the category of ccTLDs, where ccTLD-operators maintain the databases under the national policies without any impact of ICANN and gTLDs.54 In terms of the gTLDs, the registries and registrars are contractually bound by ICANN to make a specific set of registration data available in the WHOIS databases. Secondly, the WHOIS databases provide two types of WHOIS registration data information: a) technical information

45 Cf Verisign, ‘The Verisign Domain Name Industry Brief’, Q1 2019, available at accessed 30 April 2019. 46 See Harrenstien and White, ‘RFC-812 - NICNAME/WHOIS’ (n 39). 47 Cf Ken Harrenstien, Elizabeth Jocelyn Feinler and Mary Stahl, ‘RFC 954 - NICNAME/WHOIS’, October 1985, available at accessed 30 April 2019. 48 Cf Sheng, Piscitello, Gasster ‘Inventory of WHOIS Service Requirements’ (n 17) pp. 4-5. 49 Cf ICANN, ‘About WHOIS’ (n 22). 50 See Daigle, ‘RFC 3912 - WHOIS Protocol Specification’ (n 5). 51 Cf Göran Marby, ‘What is Whois’, GAC: Technical Seminar on WHOIS and Data Protection/Privacy Issues, ICANN63 meeting, 21 October 2018, 4, available at accessed 30 April 2019. 52 Cf ICANN, ‘WHOIS High-Level Technical Brief’ (n 37) pp. 2-3. 53 Cf ICANN WHOIS, ‘DNS and WHOIS - How it Works’, available at accessed 30 April 2019. 54 Cf Conrad, ‘What is Whois’ (n 36) 9. ______Matthias Markus Hudobnik 12 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

(e. g., name of the name servers, IP addresses, necessary information for Domain Name System Security Extensions (DNSSEC), the general domain name information as the date of creation, modification and expiry, and the name of the registrar which retains the domain name from the registry), b) registrants contact information (e. g., commonly the administrative and technical contact information related to the supporting registrar and the registration status information).55 This system of classification provides a basis for ‘thin’ and ‘thick’ WHOIS registries.56 In the world of gTLDs, thin registry data only consist of the technical information and only refer to the registrar who operates the (registrants) contact information data, (e. g., dot com and dot net) while thick registry includes the technical and the (registrants) contact information data. Examples of this classification are dot info and dot biz. Since the GDPR came into force, the model of the thick WHOIS registries is undergoing a redacting process.57

Figure 7: A simple WHOIS query structured in four stages.58

2.2.3 Policy agreements

Nowadays, the amount of policy documents related to the WHOIS service is tremendously high. The most significant documents are: WHOIS Data Reminder Policy (WDRP), The Restored Name Accuracy Policy (RNAP), WHOIS Marketing Restriction Policy (WMRP), Thick WHOIS Policy Development (TWPD), Translation and Transliteration of Contact Information (TTCI), ICANN Procedure for Handling WHOIS Conflicts with Privacy Law, Registry Agreements, Registrar Agreements, Registrar Advisories, 2013 RAA - Registrant Benefits and Responsibilities. The author will very briefly discuss the essential WHOIS policy agreements and will go into depth when essential to the topic of this diploma thesis and the litigation ICANN v. EPAG.59 Nevertheless, the ICANN Board adopted Temporary Specification for gTLD Registration Data and the Expedited Policy Development Process (EPDP) Team on the

55 Cf ICANN, ‘Technical Overview’ (n 20). Cf also ICANN WHOIS, ‘What are thick and thin entries?’, available at accessed 30 April 2019. 56 Cf ICANN WHOIS, ‘What are thick and thin entries?’, available at accessed 30 April 2019. 57 Cf ICANN, ‘WHOIS High-Level Technical Brief’ (n 37) 2. 58 Cf ICANN ‘DNS and WHOIS’ (n 53). 59 Cf ibid. ______Matthias Markus Hudobnik 13 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Temporary Specification for gTLD Registration Data (Temp Spec) started their first meeting in August 2018 to finalize a particular policy document for the existing WHOIS service to be compliant with the GDPR.60

2.2.3.1 Registry Agreement The term Registry Agreement (RA) refers to any agreement between registry operators of gTLDs over their rights and obligations and ICANN. In July 2017, the RA was updated due to some changes to the 2017 Global Amendment to the Base New gTLD Registry Agreement.61 Under the RA, registries are obliged to store registration data of the registrants and make this domain name registration data openly available in the WHOIS databases. These contracted parties, mostly registrars under the 2013 RAA but also registries under the RA that are processing and collecting personal data of registrants, need to be compliant with the consent requirements of the GDPR.62 The requirement for consent is the obligation of the gTLD registry operator to the registrar to receive the particular publication-consent of the registrant to make the registration data publicly available in the WHOIS database. For the sake of completeness, the EDPB’s/WP29’s list of general concerns in terms of the unlimited publication of the domain name registration data in the WHOIS databases will be discussed in Chapter 2.2.3.2 and the litigation related issues of the case ICANN v. EPAG in Chapter 5.63 For the aim of GDPR conformity, the ICANN Board adopted Temporary Specification for gTLD Registration Data, which apply to all gTLD registry operators, to modify and in some particular circumstances to replace the existing requirements of the RA which are not in line with the GDPR. Without this modification process of the RA, gTLD registry operators would neither be compliant with ICANN’s contractual obligations nor the GDPR. As a result, this would lead to instability and insecurity of the operation of the Internet as a whole and will be a risk of the DNS as well as will lead to a fragmentation of the worldwide WHOIS databases because of the specific in-house rules of each registry operator. In short, the following sections are essential for gTLD registry operator’s e. g., lawfulness and purposes of processing gTLD registration data, requirements applicable to registry operators and registrars and requirements applicable to registry operators only. Chapter 4.2 comprehensively analyzes the Temporary Specification for gTLD Registration Data requirements.64

60 Cf ICANN, ‘Keep Up with EPDP on the Temporary Specification for gTLD Registration Data’, available at accessed 30 April 2019. 61 Cf ICANN Wiki, ‘Registry Agreement’, available at accessed 30 April 2019. 62 Cf Thomas Nygren and Pontus Stenbeck, ‘gTLD Registration Directory Services and the GDPR - Part 1’, Memorandum of Hamilton Advokatbyrå, 16 October 2017, 3, available at accessed 30 April 2019. 63 Cf Article 29 Data Protection Working Party, ‘Letter from Isabelle Falque-Pierrotin to Cherine Chalaby and Göran Marby regarding GDPR’, 6 December 2017, pp. 1-3, available at accessed 30 April 2019. 64 Cf ICANN Board of Directors, ‘Temporary Specification for gTLD Registration Data’, 17 May 2018, 1, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 14 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

2.2.3.2 2013 Registrar Accreditation Agreement The term 2013 Registrar Accreditation Agreement (2013 RAA) refers to an agreement between accredited registrars over their rights and obligations and ICANN.65 Comparatively, under the 2013 RAA, the registrars are obliged to store registration data of the registrants. Furthermore, registrars make this domain name registration data - with the exception of anonymous WHOIS - openly available in the WHOIS databases and therefore need to be compliant with the consent requirements of the GDPR same as for the gTLD registry operators. Similarly, the consent requirement process, as above stated for gTLD registry operators under the RA.66 The author will briefly illuminate on the following two aspects of registrars under the 2013 RAA of a) the collection of domain name registration data, b) the unlimited publication of the domain name registration data in the WHOIS databases. Chapter 4 comprehensively analyzes further issues in this context. Before the litigation ICANN v. EPAG and the Temporary Specification for gTLD Registration Data came into force registrars were obligated under the 2013 RAA to collect as follows: 1. “The name of the registered name 2. The names of the primary name server and secondary name server(s) for the registered name 3. The identity of registrar (which may be provided through registrar’s website) 4. The original creation date of the registration 5. The expiration date of the registration 6. The name and postal address of the registered name holder 7. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the registered name; and 8. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the registered name”67 which is not GDPR-compliant to any further extent. This condition is also confirmed by German courts e. g., the Regional Court of Bonn and the Higher Regional Court of Cologne in the litigation named above.68 Furthermore, this result is also in line with the recommendations of the WP29/EDPB regarding the purpose specification

65 Cf ICANN, ‘Registry Agreement’ (n 61). 66 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 3-4. 67 See ICANN Board of Directors, ‘Section 3.3.1.1-8 of the 2013 Registrar Accreditation Agreement’, 27 June 2013, 7, available at accessed 30 April 2019. 68 Cf Germany: Regional Court of Bonn (Landesgericht LG) 10 O 171/18, 29 May 2018, available at accessed 30 April 2019. Cf also Germany: Regional Court of Bonn (Landesgericht LG) 10 O 171/18, 16 July 2018, available at accessed 30 April 2019. Cf also Germany: Higher Regional Court of Cologne (Oberlandesgericht OLG) 19 W 32/18, 01 August 2018, available at accessed 30 April 2019. Cf also Germany: Higher Regional Court of Cologne (Oberlandesgericht OLG) 19 W 32/18, 03 September 2018, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 15 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______and lawfulness of processing, and the collection of ‘full WHOIS-data,’ additional concerns will be comprehensively discussed in Chapter 3 and 4.69 In December 2017, the WP29 argued that “the unlimited publication of WHOIS-data did not appear to meet the criteria of Article 6 (1) lit. c) of the GDPR (personal data must be adequate, relevant, and not excessive in relation to the purposes of the WHOIS directories).”70 The WP29 further highlighted the importance of a layered WHOIS database-access to gain the domain name registration data of the registrants. Rather than the availability of unlimited and consent- less domain name registration data in the WHOIS databases to the general public. Firstly, the WP29 assessed that there is no valid legal basis for making the domain name registration data unlimited and publicly available in the WHOIS database because there is only freely given consent of the registrant for the registration of the domain name, but not for the publication of the data itself. Secondly, the WP29 pointed out that the legal basis ‘necessary for the performance of a contract’ is not applicable for ICANN and registry operators because the registrant is not a party of the RA agreement between this two contracted parties even if the RA forces the registry operators to disclose domain name registration data of the registrant. Thirdly, the WP29 claimed that there is no legitimate interest for a general and unlimited publication of all domain name registration data in the WHOIS databases.71 For the cause of GDPR-conformity, the Temporary Specification for gTLD Registration Data is implemented to legally bind all registrars, to modify and in some specific conditions to replace the existing requirements of the 2013 RAA, which are not in line with the GDPR. Without this modification process of the 2013 RAA, registrars would neither be compliant with ICANN’s contractual obligations nor the GDPR legislation.72

2.3 Definitions of the parties involved The main aim of this subchapter is to define the parties involved in a domain name registration process and their relevant stakeholders in the Internet ecosystem related to the topic of this diploma thesis.

69 Cf European Data Protection Board, ‘Letter from Andrea Jelinek to Göran Marby in reply to his 10 May 2018 letter’, 5 July 2018, pp. 2-3, available at accessed 30 April 2019. 70 See WP29, ‘Letter from Isabelle Falque-Pierrotin to Cherine Chalaby and Göran Marby regarding GDPR’ (n 63) pp. 2-3. 71 Cf WP29, ‘Letter from Isabelle Falque-Pierrotin to Cherine Chalaby and Göran Marby regarding GDPR’ (n 63) pp. 2-3. 72 Cf ICANN, ‘Temporary Specification for gTLD Registration Data’ (n 64) 10. ______Matthias Markus Hudobnik 16 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Figure 8: The principal journey of data and the involved parties.73

Figure 9: Domain name registration process and the involved parties.74

2.3.1 Generic Top-Level Domain registry operator

As ICANN defines the designation, a generic Top-Level domain (gTLD) registry operator is responsible for maintaining the Top-Level Domain (TLD)-database, supplying name servers to create the root zone file for the localization of the domain name, to facilitate the Internet routing process through the TLDs and handling registrant’s domain name services.75 There are also country code Top-Level Domain (ccTLD) registry operators (e. g., nic dot at, dot de) which are responsible for country code Top-Level Domains and are not under ICANN’s contractual obligations. Chapter 2.2.3.1 further explains the responsibilities of the (gTLD) registry operator under the Registry Agreement (RA).76

73 See Thomas Rickert and others, ‘GDPR Domain Industry Playbook’, V. 1.0, Eco Internet Industry Association, 11 January 2018, available at accessed 30 April 2019. 74 Cf ICANN WHOIS, ‘Domain Name Registration Process’, available at accessed 30 April 2019. 75 Cf ibid. 76 Cf ICANN, ‘Welcome Registry Operators’, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 17 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

2.3.2 Registrar

A (domain name) registrar is an under the 2013 Registrar Accreditation Agreement (2013 RAA) with ICANN, accredited (mostly) legal entity or individual person who is selling generic domain names and their registration service to registrants.77 The contractual obligation between the registrant and the registrar is determined in the registration contract between them. Chapter 2.2.3.2 further analyzes responsibilities of the registrars under the 2013 RAA.78

2.3.3 Registrant

ICANN’s definition of a (domain name) registrant is “a person or entity that holds the rights to a domain name”79 via the registration of this domain name. The registration procedure is feasible through the service of an accredited registrar or a reseller under their separate registration procedure policies so-called ‘Registration Agreement’ which is compulsory for the registrant and the accredited registrar.80 In exceptional cases, a registrant can also register a domain name through a registry operator (e. g., dot gl). This ‘Registration Agreement’ comprises rights and obligations for both parties e. g., all information rights for the domain holder related to the (registration of the) domain name itself, but also all information rights for the registrar of the domain holder information in a manner of integrity, actuality, and accuracy.81

2.3.4 Reseller

The term (domain name) reseller is a third party (mostly) a legal entity or individual person with no accreditation by ICANN, who is reselling domain name registration services via a contract with an (ICANN-accredited) registrar, but also other services e. g., web hosting, e-mail to an Internet user.82 The (ICANN-accredited) registrar is liable for the domain name sale of the reseller, but then again the reseller is contractually tied by the agreement with the registrar.83

2.3.5 Internet Corporation for Assigned Names and Numbers Chapter 2.1 provides details about ICANN.

2.3.6 Registry/Registrar Data Escrow Agent

The Data Escrow Agent (DEA) as a third party tied via an obligatory contractual agreement with ICANN (e. g., RA84 or 2013 RAA85) and a gTLD registry operator (e. g., registry data escrow) or a registrar (e. g., registrar data escrow) stores data for the eventuality of a gTLD registry operator

77 Cf ICANN, ‘Information for Registrars’, available at accessed 30 April 2019. Cf also ICANN, ‘Domain Name Registration Process’ (n 74). 78 Cf ICANN, ‘Information for Registrars’ (n 77). 79 See ICANN, ‘Information for Domain Name Registrants’, available at accessed 30 April 2019. 80 Cf ICANN, ‘Information for Domain Name Registrants’ (n 79). Cf also ICANN, ‘Domain Name Registration Process’ (n 74). 81 Cf ICANN, ‘Information for Domain Name Registrants’ (n 79). 82 Cf ICANN, ‘About Resellers’, available at accessed 30 April 2019. 83 Cf ICANN, ‘Information for Domain Name Registrants’ (n 79). 84 Cf ICANN New gTLDs, ‘Registry Data Escrow’, available at accessed 30 April 2019. 85 Cf ICANN, ‘Registrar Data Escrow Program’, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 18 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______or registrar break down.86 The data escrow storage process consists of a backup of all new data every day until the date of the last full one and a full backup is completed once a week.87

2.3.7 Emergency Back-End Registry Operator

Since April 2016, there are three Emergency Back-End Registry Operator (EBERO) providers in contractual obligations with ICANN (e. g., CNNIC, CORE Internet Council of Registrars, and Nominet). They are established from the EBERO program within the new gTLD program because of the growing number of new gTLD registry operators. EBEROs are responsible for securing critical gTLD registry operator functions e. g., domain name registration services, in case of a gTLD registry operator breakdown to guarantee ICANN’s core mission of a secure and stable Internet.88

3 Description and application of the General Data Protection Regulation The main aim of this chapter is to assess the relevant Articles of the General Data Protection Regulation (GDPR) related to the involved parties of a domain name registration process and the topic of this thesis in general. Firstly, it explains the general provisions and principles of the GDPR, and secondly, it defines what the European Data Protection Board/Article 29 Data Protection Working Party is.

3.1 General provisions and principles

3.1.1 Territorial scope

The complete title is “Regulation (EU) 2016/679 of the EU Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation),”89 which is in effect in all EU member states regardless of any domestic legislation implementation - except for some member state level implementations - and entered into force on 25 May 2018. Both, the GDPR and the previous Directive 95/46/EC share several crucial aspects with the exemption of a stronger focus on protecting individual rights in general, as well as a more comprehensively sanction regime with severe penalties, and more specific roles in the context of rights and obligations for controllers, but also processors in the GDPR legislation.90 In contrast to the Directive 95/46/EC, the GDPR has no territorial limitation, since the applicability of the GDPR is based on the processing of personal data of EU residents independently of the location of the data controller or processor. Therefore any organization (e. g., registries or registrars offering services to natural persons

86 Cf ICANN Wiki, ‘Data Escrow’, available at accessed 30 April 2019. 87 Cf ICANN, ‘Registrar Data Escrow Program’ (n 85). Cf also ICANN, ‘Data Escrow’ (n 86). 88 Cf ICANN, ‘FAQ About Emergency Back-end Registry Operators’, available at accessed 30 April 2019. 89 See Regulation (EU) 2016/679 (n 6). 90 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 4-5. ______Matthias Markus Hudobnik 19 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______within the EU) worldwide may be liable if it fulfills this criterion.91 Pursuant to Article 3 (2) GDPR, a data controller or processor, who is not located in the EU but processing personal data of EU residents through their activities e. g., a) leg cit. “the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or b) leg cit. the monitoring of their behavior as far as their behavior takes place within the Union”92 is held to account under this regulation. The guidance and determination for (2) leg cit. is stipulated in (23) GDPR as following: “the mere accessibility of the controller’s, processor’s or an intermediary’s website in the Union, of an e-mail address or of other contact details, or the use of a language generally used in the third country where the controller is established, is insufficient to ascertain such intention, factors such as the use of a language or a currency generally used in one or more Member States with the possibility of ordering goods and services in that other language, or the mentioning of customers or users who are in the Union, may make it apparent that the controller envisages offering goods or services to data subjects in the Union.”93

3.1.2 Definitions of various terms

Article 4 of the GDPR defines various necessary terms for the whole regulation and refers to the following articles: Personal data94 as defined in (1) leg cit. “means any information relating to an identified or identifiable natural person ‘data subject’; an identifiable natural person is one who can be identified, directly or indirectly, in particular, by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”95 e. g., the name and address of the natural person as registrant (previously) publicly available in the WHOIS database.96 Processing97 as defined in Article 4 (2) GDPR “means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise

91 Cf Ivan Klekovic, ‘EU GDPR vs. European data protection directive’, Advisera, EU GDPR Academy, 30 October 2017, available at accessed 30 April 2019. Cf also Gerrit Hornung, ‘Räumlicher Anwendungsbereich’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 265-266. Cf also Thomas Zerdick, ‘Räumlicher Anwendungsbereich’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz- Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 159-167. Cf also Pascal Schumacher, ‘Scope of application of the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 37-41. Cf also Paul Voigt and Alexander von dem Bussche, EU-Datenschutz-Grundverordnung (Springer Berlin Heidelberg 2018) pp. 25-34. 92 See Article 3 of the Regulation (EU) 2016/679 (n 6) pp. 32-33. 93 See (23) of the Regulation (EU) 2016/679 (n 6) 8. 94 Cf Moritz Karg, ‘Begriffsbestimmung „Personenbezogenes Datum“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 282-293. Cf also Achim Klabunde, ‘Begriffsbestimmungen’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 172-175. Cf also Daniel Rücker, ‘Scope of application of the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 12-21. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 13-15. 95 See Article 4 (1) of the Regulation (EU) 2016/679 (n 6) 33. 96 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 7-8. 97 Cf Alexander Roßnagel, ‘Begriffsbestimmung „Verarbeitung“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 298-304. Cf also Klabunde, ‘Begriffsbestimmungen’ (n 94) pp. 175-176. Cf also Rücker, ‘Scope of application of the GDPR’ (n 94) pp. 9-12. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 11-13. ______Matthias Markus Hudobnik 20 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______making available, alignment or combination, restriction, erasure or destruction”98 e. g., the collection and publication of personal data of the registrant in the WHOIS database.99 A controller100 is pursuant to Article 4 (7) GDPR “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law”101 and Article 26 GDPR stipulates that “where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers.”102 This might be in practice the general consideration in the context of WHOIS services because of the involvement of various parties (e. g., ICANN, registries, and registrars) and the different impact over different parts of processing the personal data. A further issue is the impossibility of a precise and exact determination of the concrete responsibility of the particular party between the role of a controller and/or processor. Additionally, the involved parties might set up an arrangement to clarify the respective roles and obligations in the context of processing personal data.103 A processor104 is, according to Article 4 (8) GDPR, “a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”105 and Article 28 GDPR further clarifies that “where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organizational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.”106

3.1.3 Data processing principles

Article 5 (1) lit. a) GDPR states that the processing of personal data must be107 “lawfully, fairly and in a transparent manner in relation to the data subject.”108 In accordance with b) leg cit.109 the collection of personal data shall be “for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes,”110 c) leg cit.111

98 See Article 4 (2) GDPR of the Regulation (EU) 2016/679 (n 6) 33. 99 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) 8. 100 Cf Thomas Petri, ‘Begriffsbestimmung „Verantwortlicher“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 325-330. Cf also Klabunde, (n 94) pp. 177-178. Cf also Rücker, ‘Scope of application of the GDPR’ (n 94) pp. 24-30. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 21-24. 101 See Article 4 (7) of the Regulation (EU) 2016/679 (n 6) 33. 102 See Article 26 (1) of the Regulation (EU) 2016/679 (n 6) 48. 103 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 9-10. 104 Cf Thomas Petri, ‘Begriffsbestimmung „Auftragsverarbeiter“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 330-331. Cf also Klabunde, ‘Begriffsbestimmungen’ (n 94) 178. Cf also Rücker, ‘Scope of application of the GDPR’ (n 94) pp. 30-36. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) 24. 105 See Article 4 (7) of the Regulation (EU) 2016/679 (n 6) 33. 106 See Article 28 (1) of the Regulation (EU) 2016/679 (n 6) 49. 107 Cf Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 369-375. Cf Horst Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 192-193. Cf also Sebastian Dienst, ‘Lawful processing of personal data in companies under the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 50-53. Cf also Voigt and Bussche, EU- Datenschutz-Grundverordnung (n 91) pp. 113-114. 108 See Article 5 of the Regulation (EU) 2016/679 (n 6) 35. 109 Cf Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 376-385. Cf also Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 107) pp. 193-197. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 53- 65. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 115-116. 110 See Article 5 of the Regulation (EU) 2016/679 (n 6) 35. ______Matthias Markus Hudobnik 21 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

“adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed,”112 d) leg cit.113 “accurate and, where necessary, kept up to date,”114 e) leg cit.115 “kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed”116 and f) leg cit. the processing shall be ensured in an integrity and confidentiality manner.117 Under Article 5 (1) lit. c) GDPR and in the context of the WHOIS system, the question arises if the general publication of all registration data in the WHOIS databases is specified, explicit and necessary to the legitimate purpose. Furthermore, this processing needs to fulfill the principle of data minimization to be compliant with the GDPR, but this question in connection with the litigation ICANN v. EPAG is further discussed in Chapter 5.118

3.1.4 Legal grounds and lawfulness of processing

As stated above in Article 5 (1) lit. a) GDPR processing of personal data must be lawful, fair, and transparent; this might be the case and also permitted if at least one of the legal grounds stipulated in Article 6 (1) GDPR is applicable. In the context of the WHOIS system, the following conditions of Article 6 (1) GDPR are to be considered: a) consent, b) necessity for the performance of a contract, and f) legitimate interest.119 According to Article 6 (1) lit. a) GDPR, the data subject needs to give “consent to the processing of his or her personal data for one or more specific purposes”120 e. g., registrars are contractually obliged by ICANN to currently obtaining the consent from registrants of the domain name.121 The data processing based on the legal ground of consent is grounded on rigorous conditions defined in Article 7 GDPR.122 In accordance with (1) leg cit. “the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data,”123 and if the consent is given for e. g., as written arrangement “the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible

111 Cf Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 386-389. Cf also Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 107) pp. 197-198. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 65- 67. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 117-118. 112 See Article 5 of the Regulation (EU) 2016/679 (n 6) 35. 113 Cf Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 389-391. Cf also Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 107) pp. 198-199. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 67- 69. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) 118. 114 See Article 5 of the Regulation (EU) 2016/679 (n 6) 35. 115 Cf Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 392-394. Cf also Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 107) pp. 199-200. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 70- 72. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 118-119. 116 See Article 5 of the Regulation (EU) 2016/679 (n 6) 35. 117 Cf Article 5 of the Regulation (EU) 2016/679 (n 6) 35. Cf also Roßnagel, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 97) pp. 394-395. Cf also Heberlein, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ (n 107) 200. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) 72. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) 119. 118 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 8-9. 119 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 8-10. 120 See Article 6 (1) lit. a) of the Regulation (EU) 2016/679 (n 6) 36. 121 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) 10. Cf also Peter Schanz, ‘Rechtmäßigkeit der Verarbeitung’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 404-407. Cf also Heberlein, ‘Rechtmäßigkeit der Verarbeitung’ (n 107) pp. 209-211. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 90-94. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) 126. 122 Cf Jan Hendrik Klement, ‘Bedingungen für die Einwilligung’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 555-563. Cf also Dirk Heckmann and Anne Paschke, ‘Bedingungen für die Einwilligung’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 250-251. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) 99. Cf also Voigt and Bussche, EU-Datenschutz-Grundverordnung (n 91) pp. 120-122. 123 See Article 7 (1) of the Regulation (EU) 2016/679 (n 6) 37. ______Matthias Markus Hudobnik 22 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______and easily accessible form, using clear and plain language.”124 A data subject’s withdrawal of the consent for processing shall be possible at any time, “shall not affect the lawfulness of processing based on consent before its withdrawal,”125 the withdrawal of the consent should be equally treated as the disclosure,126 and the coupling of consent is not allowed.127 There might be a potential risk in practice that involved parties unlawfully coupling the consent of the processing with the consent of the domain name registration.128 Pursuant to Article 6 (1) lit. b) GDPR “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”129 which could include processing the personal data of the domain name registrant in the context of invoicing or domain name support of the registrar rather than the general publication of all personal registration data in the WHOIS databases.130 A comprehensive analysis of these issues is further discussed in Chapter 5.131 Pursuant to Article 6 (1) lit. f) GDPR132 “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.”133 Recital (47) of the GDPR points out that “the legitimate interests of a controller, including those of a controller to which the personal data may be disclosed, or of a third party, may provide a legal basis for processing, provided that the interests or the fundamental rights and freedoms of the data subject are not overridden, taking into consideration the reasonable expectations of data subjects based on their relationship with the controller.”134 Thereof, in the context of the WHOIS system, there might be a significant amount of possible qualified categories for legitimate interests e. g., preventing fraud, combatting file sharing, intellectual property violations, and consumer deception.135 According to Article 21 (1) of the GDPR, the data subject has the right to object due to a particular personal situation, to the processing of personal data based on point f) of Article 6 (1) GDPR as a legitimate interest.136

124 See Article 7 (2) of the Regulation (EU) 2016/679 (n 6) 37. 125 See Article 7 (3) of the Regulation (EU) 2016/679 (n 6) 37. 126 Cf Article 7 (3) of the Regulation (EU) 2016/679 (n 6) 37. 127 Cf Article 7 (4) of the Regulation (EU) 2016/679 (n 6) 37. 128 Cf Rickert and others, ‘GDPR Domain Industry Playbook’ (n 73) 11. 129 See Article 6 (1) of the Regulation (EU) 2016/679 (n 6) 36. 130 Cf Schanz, ‘Rechtmäßigkeit der Verarbeitung’ (n 121) pp. 407-415. Cf also Heberlein, ‘Rechtmäßigkeit der Verarbeitung’ (n 107) 212. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 77-78. Cf also Voigt and Bussche, EU-Datenschutz- Grundverordnung (n 91) pp. 130-131. 131 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) 11. 132 Cf Schanz, ‘Rechtmäßigkeit der Verarbeitung’ (n 121) pp. 421-428, 430, 431, 434. Cf also Heberlein, ‘Rechtmäßigkeit der Verarbeitung’ (n 107) pp. 215-220. Cf also Dienst, ‘Lawful processing of personal data in companies under the GDPR’ (n 107) pp. 82-90. Cf also Voigt and Bussche, EU- Datenschutz-Grundverordnung (n 91) pp. 132-137. 133 See Article 6 (1) of the Regulation (EU) 2016/679 (n 6) 36. 134 See (47) of the Regulation (EU) 2016/679 (n 6) 33. 135 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) 13. 136 Cf Article 21 (1) of the Regulation (EU) 2016/679 (n 6) 45. Cf also Johannes Caspar, ‘Allgemeines Widerspruchsrecht’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 696-699. Cf also Hans-Georg Kamann and Martin Braun, ‘Widerspruchsrecht’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 446-453. Cf also Joachim Schrey, ‘General conditions for data processing in companies under the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 147-149. Cf also Voigt and Bussche, EU- Datenschutz-Grundverordnung (n 91) pp. 236-237. ______Matthias Markus Hudobnik 23 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

3.2 European Data Protection Board/Article 29 Data Protection Working Party As articulated in the EDPB-endorsement, the European Data Protection Board (EDPB) “is an independent body with legal personality, responsible for ensuring the consistent application of the GDPR”137 consisting of the European Data Protection Supervisor (EDPS) and the European Union member state data protection authority-officials, generally the head of the national Data Protection Authority (DPA). The national DPA in the respective member state itself undertakes the control of the compliance and the enforcement of the GDPR. The EDPB is regulated in Section 3 of the GDPR, and when the GDPR enters into force on 25 May 2018, the EDPB replaces the Article 29 Data Protection Working Party (WP29) and its areas of responsibility entirely. Over the last few years, the WP29 has played a significant advisory role for various parties in assisting them to be compliant with the GDPR and has composed guidelines on numerous GDPR-related issues (e. g., Opinion 03/2013 on purpose limitation (WP 203), Guidelines on the application and setting of administrative fines for the purposes of the Regulation 2016/679 (WP 253), Guidelines on Consent under Regulation 2016/679 (WP 259)).138 The same applies for the WHOIS system and ICANN’s policy process; the EDPB/WP29 plays a crucial advisory role in the consultation of the applicability of the GDPR in general, but also in terms of the interpretation of the legal principals in the framework of the WHOIS regime. However, EDPB’s guidelines leave no room for appeal and are not legally binding to the involved advising parties. Therefore, there is a factor of uncertainty with regards to these assumptions as a whole. Moreover, it is the decision of the domestic DPAs in the individual EU member states to interpret and enforce their GDPR compliant implemented domestic privacy laws in their respective countries, but they are usually in line with the WP29/EDPB’s opinions.139 The same applies to ICANN and its correspondence with the WP29/EDPB regarding the adaptation of the WHOIS system, where a layered access model was already advised by the WP29 in 2003. Chapter 3 provides details about the description and application of the GDPR.140

137 See European Data Protection Board, ‘THE EUROPEAN DATA PROTECTION BOARD’, Endorsement 1/2018, available at accessed 30 April 2019. 138 Cf Stephanie Schiedermair, ‘Europäischer Datenschutzausschuss’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 1157-1161. Cf also Jan Philipp Albrecht, ‘Europäischer Datenschutzausschuss’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 867-877. Cf also Schrey, ‘General conditions for data processing in companies under the GDPR’ (n 136) pp. 155-156, 161-162. Cf also Voigt and Bussche, EU-Datenschutz- Grundverordnung (n 91) 261. 139 Cf Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) 5. 140 Cf WP29, ‘Letter from Isabelle Falque-Pierrotin to Cherine Chalaby and Göran Marby regarding GDPR’ (n 63) 3. ______Matthias Markus Hudobnik 24 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

4 Compliance Models In this chapter, the author compares the Compliance Models and points out their advantages and disadvantages. Subsequently, the different characteristics of the models are matched, analytically assessed, and partially potential solutions are already delivered in this chapter. Additionally, the author descriptively reflects on the Temporary Specification for gTLD Registration Data and the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec). The author proves the hypothesis in the several conclusions of the subchapters, but also in the general conclusion. Firstly, the GDPR was the catalyst for the adoption of the Compliance Models and subsequently, the modification process of the previous WHOIS database publication practices. Secondly, the litigation ICANN v. EPAG has potentially influenced the EPDP on the Temp Spec, especially, in the context of Admin-C and Tech-C data. Thirdly, there is a necessity for a system of standardized access to non-public registration data, adjusted with the technical implementation process, which is also lawful under specific data protection laws. An overview of the detailed analysis of potential final answers in the context of the litigation in line with the GDPR and the general outlook is presented in Chapter 6.

4.1 GDPR Compliance Models and community input The various Compliance Models are comparatively and analytically examined on three widely community accepted essential criteria: ‘data collection, processing and retention,’ ‘scope of applicability’ and ‘layered/tiered access to WHOIS data.’ This chapter further discusses the similarities and differences between them. The figure below illustrates an overview of the twelve different Compliance Models of the community and ICANN (e. g., ECO Internet Industry Association, Electronic Frontier Foundation, ICANN Model from 1-2A-2B to 3, Appdetex, Governmental Advisory Committee, Intellectual Property Constituency, iThreat Cyber Group, Coalition for Online Accountability, Feldman Mode) and their varying impact on the WHOIS system. For the sake of completeness, it should be mentioned that the Policy Development Process of Phase 2 is still in progress, and there might be updates and changes in the future. According to the ‘Interim GDPR Compliance Model’ document dated 08 March 2018, there are some fundamental criteria addressed and previous, as well as ongoing, domain registration practices are questionable:  The registrar’s collection of registrant’s personal data (e. g., administrative and technical contacts) and transfer to registry and data escrow agent  Anonymization and replacement of current e-mail addresses of the registrant, as well as administrative and technical contacts in the public WHOIS database  Globally permission of the application of the Compliance Model for registries and registrars

______Matthias Markus Hudobnik 25 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

 Application of the Compliance Model to contact information provided by registrants who are legal persons  The requirement of registries and registrars to supply full access to the public WHOIS database even though the implementation of a layered/tiered access via an accreditation program141

Figure 10: Overview of the different GDPR Compliance Models142

4.1.1 Data collection, processing, and retention The first essential category ‘data collection, processing, and retention’ of all below named Compliance Models is divided into the following subcategories: collection from the registrant to the registrar, data transfer from registrar to the registry, data transfer to escrow agents, and data retention. Before discussing and comparing the different data fields in the chart, it is crucial to define the purpose of the processing activities.143 The purpose of ICANN is stated in Section 4.6 (e) ICANN Bylaws as the following: “Subject to applicable laws, ICANN shall use commercially reasonable efforts to enforce its policies relating to registration directory services and shall work with Supporting Organizations and Advisory Committees to explore structural changes to improve accuracy and access to generic top-level domain registration data, as well as consider safeguards for protecting such data”144 and in (d) leg cit. “adequately address issues of competition, consumer protection, security, stability and resiliency, malicious abuse

141 Cf ICANN, ‘The Cookbook’ (n 16) pp. 2-3. 142 See ICANN, ‘Proposed Interim GDPR Compliance Models and Selected Community Input (Working Draft)’, 1 February 2018, available at accessed 30 April 2019. 143 Cf ICANN, ‘Working Draft Non-Paper - Selected Interim GDPR Compliance Models & Comments’, 1 February 2018, available at accessed 30 April 2019. 144 See ICANN, ‘Section 4.6 (e) of the BYLAWS FOR INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | A California Nonprofit Public- Benefit Corporation’, 18 June 2018, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 26 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______issues, sovereignty concerns, and rights protection prior to, or concurrent with, authorizing an increase in the number of new top-level domains in the root zone of the DNS.”145 Nevertheless, as the EDPB has already analyzed in the letter dated 05 July 2018, it is crucial to strictly differentiate between the various processing activities that are completed in the context of the WHOIS system and the exact purpose specification of the different implicated parties.146

Table 1: Data collection, processing, and retention147

Electro Coalitio nic ICANN ICANN ICANN ICANN n for Fronti AppDe iThrea Felma ECO Model Model Model Model IPC GAC Online er tex t n 3 2B 2A 1 Account Found ability ation Data collection, processing and retention Unclea r, but implie s full Minimal collect data ion of collecte Full thick Collec d from thick data. tion registra data, ICANN from r. No except org or regist collecti Full thick data* no its rant on of registra agent to admin nt e- would regist and mail have rar tech address some contact role in informa redacti tion** on of person al data. Unclea r, but implie s full Must transf transfer er of thin thick Data data. data. transf Permits ICANN er , but org or from does Full transfer of thick data* N/A its regist not agent rar to require, would regist transfer have ry of some registra role in nt redacti data** on of person al data. Registr Regist ar rants transfer who minimal are Data data natura transf collecte l er to d. person escro Registry Full transfer of existing registration data* N/A s w transfer would agent thin have s data + data registra transf r data if erred receive by d from ICANN

145 See ICANN, ‘Section 4.6 (d) of the BYLAWS FOR INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | A California Nonprofit Public- Benefit Corporation’, 18 June 2018, available at accessed 30 April 2019. 146 Cf EDPB, ‘Letter from Jelinek to Marby’ (n 69) pp. 2-3. 147 See ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 27 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

registra to r** data escro w agent Life of registr ation + 2 years* (Note: Eliminat As long existin e ICANN Life of Life of Life of as Life of Life of Life of g 1- Life of data registr registr registr needed Data registr registr registr year registr retentio ation ation ation to fulfil retent ation ation ation waiver ation N/A N/A n + 60 + 60 + at specifie ion + 1 + 1 + 2 s for + 2 require days* days* least 2 d year year years* Europ years* ments* * * years* purpose ean * s registr ars would be preser ved) ** = More substantial change from status quo, * = Greater preservation of status quo

4.1.1.1 Collection from the registrant to the registrar The first chart in this subcategory shows that almost all – except the Coalition for Online Accountability model with no collection of the registrant e-mail address and the Feldman model where it is unclear, but it implies a full collection of thick WHOIS data – community models completely follow the full thick WHOIS data collection regime. Only the ECO model pursues a different approach with a minimal data collection from the registrar and no collection of administrative and technical contact information of the registrant. Although the vast majority of community commenters support the concept of full thick WHOIS data collection, others e. g., ECO thought that there is a need for a holistic approach with a proper privacy impact assessment and a precise determination of the respective data fields in line with the principle of data minimization and a revised purpose specification. With regards to full thick WHOIS, there would, therefore, seem to be a definite need for a further purpose description to justify the requirement for registrars to transfer that data to the registries.148 According to Article 5 (1) lit. b) GDPR (further discussed in Chapter 3.1.3), the collection of personal data is only allowed for “specified, explicit and legitimate purposes.”149 Concerning the principle of data minimization, a determination of the particular purposes for the current WHOIS system generally is an essential first step and should not be granted in conjunction with the original purpose of registrar’s collection of registrant’s personal data through the domain registration process under contractual obligations between these parties. The main question is whether the original purpose is sufficient enough or whether a separate legal principle is required?150 Whereas the original purpose for processing registrant’s personal data is based on the legal principle “processing is necessary for the performance of a contract”151 according to Article 6 (1) lit b) GDPR.152

148 Cf ibid. 149 See Article 5 (1) lit. b) of the Regulation (EU) 2016/679 (n 6) 35. 150 Cf ICANN, ‘The Cookbook’ (n 16) pp. 7-9. 151 See Article 6 (1) lit. b) of the Regulation (EU) 2016/679 (n 6) 36. 152 Cf Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. ______Matthias Markus Hudobnik 28 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

In contrast to that, the purpose of the current WHOIS system is based on the legal principle “processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party”153 according to Article 6 (1) lit f) GDPR. There would, therefore, seem to be a definite need for a review of the purpose descriptions and expansion of the registration data processing activities beyond the original purpose description in connection with the operation of the WHOIS system. Another possible area of investigation concerning the principle of data minimization and data collection will be whether if it is necessary to collect the same amount of registrant’s personal data under 2013 RAA or if a reduction of data elements is requisite in order to be compliant with the GDPR.154 Additionally, it appears that there are outdated data fields (e. g., fax numbers and the physical addresses), which may no longer necessarily be collected. Under Article 5 (1) lit. c) GDPR it must be “adequate, relevant and limited to what is necessary concerning the purposes for which they are processed”155 which might not be the case in this particular circumstance anymore.156

4.1.1.2 Data transfer from registrar to registry Following the ‘Thick WHOIS Transition Policy’ dated 01 February 2017, registrars are contractually obligated to transfer full thick WHOIS data to registries.157 The data of chart number one for this subcategory is like the first subcategory. It demonstrates that there is an almost holistic view of all Compliance Models – except the Coalition for Online Accountability model which do not address this issue and the Feldman model which is unclear but, it implies a full transfer of thick WHOIS data – to support the approach of a full thick WHOIS data transfer. Here again, only the ECO model suggests a different path while the transfer must contain thin WHOIS data, it permits registrars to transfer registrants data to the registries, but it is not necessarily required to do so.158 As the ‘Final Report on the Thick WHOIS Policy Development Process’ dated 21 October 2013 insists that thick WHOIS data transfer supports a further accessible and more stable domain name system through the mutual data distribution on the registrar level as well as on the registry level. The result is, in case of a technical defect, the registry has the full registrant’s data set and may transfer it to an additional registrar to foster the data redundancy, which is a data quality improvement as a whole.159 Furthermore, it has also been illustrated in the ‘Interim GDPR Compliance Model’ document dated 08 March 2018, that there are not sufficient legal principles - in light of the GDPR - to justify the conditions for the registrar’s transfer of data to the registry.160 According to Article 6 (1) lit. f) GDPR, the transfer of registrant’s personal data from a registrar to a registry must be

153 See Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 154 Cf ICANN, ‘The Cookbook’ (n 16) pp. 9-11. 155 See Article 5 (1) lit. c) of the Regulation (EU) 2016/679 (n 6) 35. 156 Cf ICANN, ‘The Cookbook’ (n 16) 11. 157 Cf ICANN Board of Directors, ‘Thick WHOIS Transition Policy for .COM, .NET and .JOBS’, 1 February 2017, available at accessed 30 April 2019. 158 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 159 Cf Marika Konings, ‘Final Report on the Thick Whois Policy Development Process’, 21 October 2013, 3, available at accessed 30 April 2019. 160 Cf ICANN, ‘The Cookbook’ (n 16) 13. ______Matthias Markus Hudobnik 29 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______based on a legal principle, which may be in this context the principle of legitimate interests.161 The full definition of ‘legitimate interests’ is portrayed in Chapter 3.1.4, as well as recital (47) GDPR. This circumstance means for the interests of registries and registrars or third parties (e. g., law enforcement agencies) to attain stable and straightforward access to the domain name system, endorsed via the thick WHOIS system. With regards to the full thick WHOIS transfer, ICANN may also extend the purpose description (further details in Chapter 3.1.3) for the data processing activities with the aim of full thick WHOIS data transfer being compliant with Article 5 GDPR.162

4.1.1.3 Data transfer to escrow agents As explained in Chapter 2.3.6 and determined in the 2013 RAA and the RA, all gTLD registry operators, as well as accredited registrars, are currently contractually obligated to back up their whole gTLD registration data via an autonomous data escrow agent. The transfer of the full existing registration data (e. g., thick registration data including personal data) to the data escrow agent is protection for the registrant and guarantees gapless processing via a data backup in the event of a business mistake or technical break down of a gTLD registry operator or accredited registrar. The data fields in this subcategory of chart number one are analogical to the second subcategory, only with the minor difference of the full transfer of existing registration data to the data escrow agent instead of the transfer from a registrar to a registry. It also illustrates here the integrally view of all model commentators – except for the Coalition for Online Accountability model, which does not address this issue, and the Feldman model in which registrants who are natural persons would have data transferred by ICANN to the data escrow agent – to retain the concept of the full transfer of existing registration data to the data escrow agent. Here again, as in the second subcategory, only the ECO model believes in another notion, namely that the registrar transfers the minimal collected data to the registry. The registry, in turn, then transfers the registrars received registrant’s data and the thin data set to the escrow agent.163 Preferably, the data escrow agent would be located in Europe to prevent an outside escrowing of the full thick registration data, since most of the risks of the registries and registrars are mainly based in Europe.164 Similar to the second subcategory and according to Article 6 (1) lit. f) GDPR, the transfer of full thick registration data from a gTLD registry operator or accredited registrar to the data escrow agent is also based on the principle of legitimate interests165 of the named parties and who are therefore interested in a stable and accessible domain name system. The data escrowing

161 Cf Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 162 Cf ICANN, ‘The Cookbook’ (n 16) 14. 163 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 164 Cf ICANN, ‘The Cookbook’ (n 16) pp. 15-16. 165 Cf Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. ______Matthias Markus Hudobnik 30 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______is a safeguard for the registrant and guarantees the expected transition services in case of a problem or defect of a gTLD registry operator or accredited registrar.166

4.1.1.4 Data retention According to data retention, there is no separate provision in the RA to regulate this particular issue. Nevertheless, under Specification 2, Part B) lit. 4) RA, the escrow agent, which must be utilized by every registry, is contractually forced to deposit and safeguard the registration data for at least one year.167 Following the Data Retention Specification lit. 1.1) 2013 RAA, it is stipulated that registrants are obligated to collect all personal data of the registrant through the domain name registration and “shall maintain that information for the duration of registrar’s sponsorship of the registration and for a period of two additional years.”168 The fourth subcategory in chart number one illustrates that the majority of the Compliance Models prefer a retention period during the life of the registration, but shows a different range for the retention period beyond the registration between a minimum of 60 days (e. g., Electronic Frontier Foundation model and the ICANN Model 3) to one (e. g., ICANN Model 2A, and 2B) or even two years (e. g., ICANN Model 1, AppDetex, IPC, and GAC model), depending on the respective model. Particularly notable is the ECO model once again with the elimination of the ICANN data retention requirement. Both, the iThreat and Feldman model do not address this issue, and the Coalition for Online Accountability model is for data retention as long as needed to fulfill specified purposes, even if it is not entirely clear what is meant by this wording.169 According to Article 5 (1) lit. e) GDPR, the principle of storage limitation states that personal data needs to “kept in a form which permits the identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed,”170 which is fulfilled by the respective Compliance Models. The crucial question is, whether the lawfulness of processing under Article 6 GDPR is in the context of the particular purposes for processing under Article 5 GDPR in any cases of the data retention elements fulfilled. From this follows the adequate lengths of the retention periods. As a result, ICANN compiled a list in the ‘Interim GDPR Compliance Model’ document dated 08 March 2018, in which the legal basis for data retention requirements for every data element was formulated in line with the exact legitimate purpose for the collection and the lawful basis for the retention to be compliant with the GDPR. This issue will not be further discussed, as it is not directly related to the central questions of this thesis.171

166 Cf ICANN, ‘The Cookbook’ (n 16) 16. 167 Cf ICANN, ‘Specification 2, Part B) lit. 4) of the Registry Agreement’, 31 July 2017, pp. 50-51, available at accessed 30 April 2019. 168 See ICANN Board of Directors, ‘Retention Specification lit. 1.1) of the 2013 Registrar Accreditation Agreement’, 27 June 2013, 61, available at accessed 30 April 2019. 169 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 170 See Article 5 (1) lit. e) of the Regulation (EU) 2016/679 (n 6) 36. 171 Cf ICANN, ‘The Cookbook’ (n 16) pp. 17-18. ______Matthias Markus Hudobnik 31 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

4.1.2 Scope of applicability The second category ‘scope of applicability’ of all below named Compliance Models is divided into two subcategories: territorial applicability implies global, or EEA (European Economic Area) and ‘legal entities’ are addressed as natural and legal persons.

Table 2: Scope of applicability172

Electro Coaliti nic ICANN ICANN ICANN ICANN on for Frontie AppDe Felma ECO Model Model Model Model IPC GAC iThreat Online r tex n 3 2B 2A 1 Accoun Found tability ation Applicability Territo Unclea rial r, but applic seems ability: to Global Global Global EEA EEA EEA EEA EEA EEA EEA EEA Global imply ** ** ** only* only* only* only* only* only* only* only* ly or global only to applic EEA ability. Legal Registr Registr Registr Registr Registr Registr Registr Registr Registr Registr Registr Registr entitie ations ations ations ations ations ations ations ations ations ations ations ations s: of of of of of of of of of of of of Regist natura natura natura natura natura natura natura natura natura natura natural natura rant l and l and l and l and l and l l l l l and l and types legal legal legal legal legal person person person person person legal legal affect person person person person person s s s s s person person ed s** s** s** s** s** only* only* only* only* only* s** s** ** = More substantial change from status quo, * = Greater preservation of status quo

4.1.2.1 Territorial applicability (global or EEA) According to the territorial applicability in connection with ICANN’s contractual agreements (e. g., 2013 RAA, RA) with the respective parties (e. g., registries, registrars, and registrants) is to highlight that there is no territorial differentiation necessary because of the unified contractual clauses. The encompassing question is whether the Compliance Models should be applied globally to the location of the respective parties as previously mentioned or only to the EEA, namely where the nexus of the parties exists.173 Chart number two of this subcategory demonstrates that the majority of the – except for the Electronic Frontier Foundation model, the ICANN Model 3 and 2B which apply globally, and the ECO model where it is unclear, but it seems to imply global applicability – community models apply only to the EEA.174 Nevertheless, there are some communities in favor of stronger protection and harmonization in the context of the registration data separately from the location debate, whether the parties are inside or outside of the EEA, and irrelevant of the data flows and processing activities. Further consequences of global applicability are the fact that this creates foreseeability, interoperability, and transparency strengthens the domain name system as a whole and is also in the interest of the public internet community. An additional concern of a non-global application is the fear that some parties would not be compliant with the GDPR. In contrast, it is interesting to note that there are commentators who criticize global applicability, namely because it would be an overestimation in terms of the application of the

172 See ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 173 Cf ICANN, ‘The Cookbook’ (n 16) 19. 174 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 32 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

GDPR and would violate ICANN’s purposes to preserve the current WHOIS system while only modifying the uncompliant sections to the minimum required extent. Furthermore, some commentators recommend the realization of the Compliance Model via a new self-registered WHOIS data field for registrants to be verified as living in the EU; therefore, results that the applicability of the GDPR would be minimized to a great extent due to where it would be required to be compliant.175 From a legal point of view, there is no way through Article 3 (1) GDPR, (further details in Chapter 3.1.1) which stipulates that “the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not.”176 Under Article 3 (2) GDPR, a data controller or processor which is not located in the EU but processing personal data of EU residents through their activities e. g., a) leg cit. “the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or b) leg cit. the monitoring of their behavior as far as their behavior takes place within the Union”177 is held accountable under this regulation. The guidance and determination for (2) leg cit. is stipulated in (23) GDPR or further details explained in Chapter 3.1.1. Taking all of this into account results in the following applicability of the GDPR, namely that registries and/or registrars based in the EEA that process personal registration data are liable under Article 3 GDPR. As well as for registries and/or registrars who are not based in the EEA, but are providing services to registrants based in the EEA containing personal registration data processing from EEA based registrants. The same principles shall apply for non-EEA based registries and/or registrars who process personal registration data of registrants not based in the EEA, where registries and/or registrars are obliged by EEA-based processors to process personal registration data as such. The idea of the extra-territoriality of the GDPR is to ensure a maximum level of protection for EU data subjects in circumstances in which data controllers and/or processors are located outside of the EEA, but are linking their business cases to EU data subjects.178

4.1.2.2 Legal entities addressed as natural or legal persons (registrant types affected) Under ICANN’s contractual agreements (e. g., 2013 RAA, RA) with the respective parties (e. g., registries and registrars) it is to portray that there is no contractual distinction noted in the domain registration process, whether the registrant is addressed as a natural or legal person.179 The second subcategory of chart two shows that seven out of twelve Compliance Models are supporting registrations of natural and legal persons, whereas, five of them only provide registrations of natural persons.180 Under Article 4 (1) GDPR, “an identifiable natural

175 Cf ICANN, ‘The Cookbook’ (n 16) pp. 19-21. 176 See Article 3 (1) of the Regulation (EU) 2016/679 (n 6) 32. 177 See Article 3 of the Regulation (EU) 2016/679 (n 6) pp. 32-33. 178 Cf ICANN, ‘The Cookbook’ (n 16) pp. 20-21. 179 Cf ICANN, ‘The Cookbook’ (n 16) pp. 22. 180 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 33 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”181 As a result, a domain registration of a natural person falls under the scope of applicability of the GDPR. The initial observations demonstrate that there may be a link between natural and legal persons in that sense, that the personal data of a natural person may be linked to a legal entity as partnership e. g., GmbH via the close commercial and financial connection of the natural person. Subsequently, the information of the legal entity can be associated with the natural person them self because of the near relationship or the natural person’s share of the legal entity. Since the GDPR does not protect legal persons as they do not fall under the scope of applicability, it may be, nevertheless, a difficult task in practice to differentiate legal persons from natural ones because they may contain personal data of natural persons and therefore be reliable under the GDPR. A pragmatic solution of the Compliance Model would be the implementation of the domain registration data as a whole, which would be stored in the WHOIS databases.182

4.1.3 Layered/tiered access to public WHOIS data The third category ‘layered/tiered access to WHOIS data’ of all below named Compliance Models is divided into public and non-public WHOIS data; whereas, the section public WHOIS is separated into nine subcategories: registrant name, registrant postal address, registrant e- mail, registrant phone and fax, admin and tech contact names, admin and tech contact postal addresses, admin and tech contact e-mail addresses, admin and tech contact phone, and registrars offering to opt-in to publish additional data.

181 See Article 4 (1) of the Regulation (EU) 2016/679 (n 6) 33. 182 Cf ICANN, ‘The Cookbook’ (n 16) pp. 22-23. ______Matthias Markus Hudobnik 34 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Table 3: Public WHOIS.183

Electron ICAN ICAN ICAN Coalition ic ICANN N N EC AppDe N IP for Online Frontier Model Mod Mod GAC iThreat Felman O tex Mod C Accounta Foundat 3 el el el 1 bility ion 2B 2A Layered/tiered access to WHOIS data Public WHOIS Yes, but registra Yes, nts may except Yes, apply to natural Registrant except Yes, ICANN persons name in No no No* No* Yes Ye except no for No** No** Yes* may opt- public ** perso * * * s* personal approva out of WHOIS? nal data* l to publishing data* redact personal person data* al data* Yes, except Yes, but natural registra persons nts may may opt- Yes, apply to Registrant out of except Yes, ICANN postal publishing No no No* No* Yes Ye except no for address in No** No** Yes* personal ** perso * * * s* personal approva public data. nal data* l to WHOIS? However, data* redact must person publish al state/provi data* nce and country* Yes, but registra Yes, nts may except Yes, apply to natural Registrant except Yes, ICANN Ye persons e-mail in No no No* No* No* except no for No** No** s* Yes* may opt- public ** perso * * * personal approva * out of WHOIS? nal data* l to publishing data* redact personal person data* al data* Yes, but registra Yes, nts may except Yes, Yes, apply to Registrant natural except except Yes, ICANN phone and N persons No no No* No* No* no except no for fax in No** No** o* may opt- ** perso * * * person personal approva public * out of nal al data* l to WHOIS? publishing data* data* redact personal person data* al data* Yes, but registra Yes, nts may Administra except Yes, Yes, apply to tive and natural except except Yes, ICANN technical N persons No no No* No* No* no except no for contact No** No** o* may opt- ** perso * * * person personal approva names in * out of nal al data* l to public publishing data* data* redact WHOIS? personal person data* al data* Yes, except Yes, but natural registra Administra persons nts may tive and Yes, Yes, may opt- apply to technical except except out of Yes, ICANN N contact No no No* No* No* no publishing except no for No** No** o* postal ** perso * * * person personal personal approva * addresses nal al data. data* l to in public data* data* However, redact WHOIS? must person publish al state/provi data* nce and

183 See ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 35 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

country* Yes, but registra Administra nts may tive and Yes, apply to technical except Yes, ICANN contact e- No no Yes Yes Yes Ye except no for No** No** Yes* Yes* mail ** perso * * * s* personal approva addresses nal data* l to in public data* redact WHOIS? person al data* Yes, but registra Yes, nts may Administra except Yes, apply to tive and natural except Yes, ICANN technical persons No no No* No* Yes Ye except no for contact No** No** Yes* may opt- ** perso * * * s* personal approva phone in out of nal data* l to public publishing data* redact WHOIS? personal person data* al data* Registrars offering to opt-in to publish No Yes Yes Yes Ye Yes* Yes* Yes* N/A Yes* Yes* Yes* additional ** * * * s* data in public WHOIS? ** = More substantial change from status quo, * = Greater preservation of status quo

4.1.3.1 Public WHOIS According to Article 5 (1) lit c) GDPR and in the context of the public WHOIS system, the question arises, whether the general publication of all the registration data in the WHOIS databases is specified, explicit, and necessary for the legitimate purpose. The data processing principles of the GDPR applied here were comprehensively explained in Chapter 3.1.3, as the principle of lawfulness, fairness, and transparency, the principle of purpose limitation and data minimization which may be relevant in the context of the WHOIS system.184 Furthermore, this processing needs to fulfill the principle of data minimization to be compliant with the GDPR.185 Under the Specification 4 RA and the Registration Data Directory Service (WHOIS) Specification 2013 RAA, registries and registrars are contractually obliged to “providing free public query-based access to”186 the primary domain name registration data fields of the registrants. However, the existing consensus policies fail to resolve the compliance issues with the GDPR, and obviously, the former or (present) situation of entirely open and unlimited access to the full thick WHOIS data will, under no circumstances, be appropriate and lawful under the GDPR. A detailed analysis of the respective data fields is further discussed in the relevant subcategories below.187

184 Cf ICANN, ‘The Cookbook’ (n 16) 23. 185 Cf Nygren and Stenbeck, ‘gTLD Registration Directory Services and the GDPR’ (n 62) pp. 8-9. 186 See ICANN Board of Directors, ‘Registration Data Directory Service (WHOIS) Specification of the 2013 Registrar Accreditation Agreement’, 27 June 2013, 51, available at accessed 30 April 2019. See also ICANN Board of Directors, ‘Specification 4, Registration Data Publication Services lit. 1) Registration Data Directory Services of the Registry Agreement’, 31 July 2017, 63, available at accessed 30 April 2019. 187 Cf ICANN, ‘The Cookbook’ (n 16) 24. ______Matthias Markus Hudobnik 36 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

4.1.3.1.1 Registrant name The first subcategory of the third chart illustrates that generally, seven out of twelve community models are supporting the fact that the registrant’s name should be published in the public WHOIS database; whereas, five of them are against this open publication.188 In addition, that four out of the seven community models are in favor publication with slight modifications as follows: The iThreat model has the exception that natural persons may opt- out of publishing personal data, the Feldman model states that registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3 and the Coalition for Online Accountability model support the publication in the public WHOIS database as long as it contains no personal data.189 Although some of the community commenters believe in a proper privacy impact assessment, an accurate determination of the individual data elements to ensure that they are in line with the processing principles of the GDPR. In short, whether the utilized data field includes personal data and if so, is public access necessary, proportionate, and limited to the purpose of the processing activity.190

4.1.3.1.2 Registrant postal address The data of the chart third for this subcategory is similar to the first subcategory. It shows that generally, seven out of twelve community models are supporting the fact that the registrant’s postal address should be published in the public WHOIS database; whereas, five of them are against open publication. It is also the same situation here as stated above that four out of the seven community models are in favor of publication with the following slight modifications: The iThreat model has the exception that natural persons may opt-out of publishing personal data but must publish state/province and country, the Feldman model states that the registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3 and the Coalition for Online Accountability model support publication in the public WHOIS database as long as it contains no personal data.191 Additionally, some community commenters advocate preserving the postal address field with the particular information of the state/province/country and others insist on keeping the city and/or postal code field of the registrant in the public WHOIS database for the reason that the jurisdiction of the registrant may be identified more easily.192

4.1.3.1.3 Registrant e-mail address The data fields in this subcategory of chart three are analogic to the second subcategory, but with the minor distinction that the resulting data is equally allocated between the twelve Compliance Models because of the changes in the particular data field of ICANN Model 1. Six out of twelve community models support the fact that the registrant’s e-mail address data field

188 Cf ibid. 189 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 190 Cf ICANN, ‘The Cookbook’ (n 16) pp. 24-25. 191 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 192 Cf ICANN, ‘The Cookbook’ (n 16) pp. 24-25. ______Matthias Markus Hudobnik 37 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______should be published in the public WHOIS database; whereas, the other six community models are against this publication. The results are slightly different as stated above for the reason that four out of the six in favor community models provide a publication with the following small modifications: The iThreat model has the exception that natural persons may opt-out of publishing personal data, the Feldman model states that registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3 and the Coalition for Online Accountability model support publication in the public WHOIS database as long as it contains no personal data.193 Remarkably, quite many commentators have observed that the registrant’s e-mail address data field may be, in terms of cybercrime prevention and investigation, the most useful data field in the WHOIS database, as well as the most relevant and accurate one because it is necessary for the verification and domain registration process itself. Some commenters have grave concerns that a user-accreditation, in general, will result in a less efficient investigation chain; thus, hindering the identity process of the real perpetrators. In contrast, it is interesting to point out that there are commentators who advocate that the registrant’s e-mail address should only be published publicly, voluntarily by the explicit consent of the registrant as a data subject under Article 7 GDPR. Furthermore, some commentators recommend implementing a web interface with a captcha-form to ensure anonymized communication with the registrant if required and the message will be forwarded to the proper contact (e. g., registrants personal e- mail address).194

4.1.3.1.4 Registrant phone and fax Similarly, in the fourth subcategory of the third chart, five out of twelve community models support the fact that the registrant’s phone and fax should be published in the public WHOIS database; whereas, seven of them are against their publication. All of the five community models in favor would publish with the following small modifications: The iThreat model has the exception that natural persons may opt-out of publishing personal data, the Feldman model states that registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3, the Coalition for Online Accountability model and the GAC model support the publication in the public WHOIS database as long as it contains no personal data.195 It seems possible that these results are coherent with some commentator’s views that the fax number is outdated and should no longer be relevant in the WHOIS system.196

4.1.3.1.5 Administrative and technical contact names In the context of administrative and technical contact data, it should be articulated that some Compliance Model commentators suggest having at least the e-mail addresses of the administrative and technical contacts published as public WHOIS data. This publication would

193 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 194 Cf ICANN, ‘The Cookbook’ (n 16) 25. 195 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 196 Cf ICANN, ‘The Cookbook’ (n 16) 26. ______Matthias Markus Hudobnik 38 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______be done in order to support the stability, operability, and security of the DNS and the Internet as a whole via this significant technical information. Others argue that in most cases, the information of the administrative and technical contact is identical with the registrant’s personal information and it is therefore not necessary to publish this data set openly: or at least a case by case assessment would be required to clarify, whether personal data is involved or not.197 In the fifth subcategory of the third chart, five out of twelve community models support the idea that administrative and technical contact names should be published in the public WHOIS database; whereas, seven of them are against this publication. All of the five in favor community models would publish with the following small modifications: The iThreat model has the exception that natural persons may opt-out of publishing personal data, the Feldman model states that registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3, the Coalition for Online Accountability model and the GAC model support the publication in the public WHOIS database as long as it contains no personal data. Chapter 5 further analyzes details of the administrative and technical data related to the case ICANN v. EPAG.198

4.1.3.1.6 Administrative and technical contact postal addresses The sixth subcategory is identical to the fifth subcategory of the third chart, as five out of twelve community models support the notion that administrative and technical contact postal addresses should be published in the public WHOIS database; whereas, seven of them are against this publication. All of the five community models in favor of this would publish with the following small modifications: The iThreat model has the exception that natural persons may opt-out of publishing personal data but must publish state/province and country, the Feldman model states that registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3, the Coalition for Online Accountability model and the GAC model support the publication in the public WHOIS database as long as it contains no personal data. Here again, Chapter 5 further analyzes details of the administrative and technical data related to the case ICANN v. EPAG 199

4.1.3.1.7 Administrative and technical contact e-mail addresses The seventh subcategory of chart number three shows that the majority of the Compliance Models prefer that the administrative and technical contact e-mail addresses should be published in the public WHOIS database; whereas, three of them are against publication. Three out of the nine community models that are in favor will publish with the following small modifications: In the Feldman model, the registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3, as well as the Coalition for Online Accountability model

197 Cf ICANN, ‘The Cookbook’ (n 16) pp. 26-27. 198 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 199 Cf ibid. ______Matthias Markus Hudobnik 39 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______support the publication in the public WHOIS database as long as it contains no personal data. Once again, Chapter 5 further analyzes details of the administrative and technical contact data related to the case ICANN v. EPAG.200

4.1.3.1.8 Administrative and technical contact phone The eighth subcategory is similar like the seventh one of the third chart, namely that the majority of the Compliance Models prefer that the administrative and technical contact phone should be published in the public WHOIS database; whereas, five out of them are against publication. Four out of the nine community models that are in favor would publish with the following small modifications: The iThreat model has the exception that natural persons may opt-out of publishing personal data, the Feldman model states that registrants may apply to ICANN for approval to redact personal data, and the ICANN Model 3 and the Coalition for Online Accountability model support the publication in the public WHOIS database as long as it contains no personal data. Chapter 5 further analyzes details of the administrative and technical contact data related to the case ICANN v. EPAG.201

4.1.3.1.9 Registrars offering to opt-in to publish additional data The data field in this subcategory of chart number three shows that ten out of twelve Compliance Models support the fact that registrars must offer registrants an opt-in to publish additional data in the public WHOIS database; whereas, only the ECO model is against publication and the GAC model does not address this issue in its model.202

4.1.4 Layered/tiered access to non-public WHOIS data The fourth category ‘layered/tiered access to WHOIS data’ of all Compliance Models is divided into public and non-public WHOIS data; whereas, the section non-public WHOIS is separated into two subcategories: self-certification access and accreditation program for access.

200 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 201 Cf ibid. 202 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 40 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Table 4: Non-Public WHOIS203

Electr Coaliti onic ICA on for Fronti NN ICANN ICANN AppDete ICANN iThre Online Felma ECO er Mo Model Model IPC GAC x Model 1 at Accou n Foun del 2B 2A ntabilit datio 3 y n Layered/Tiered Access to WHOIS data Non-Public WHOIS Yes, on Yes, on Yes, Yes, interim interim Yes, for on basis, basis, subject blank interi subject subject to Yes, No, et m to to registry/ subject create No, acce basis, registry/ registry/ No, registrar to anony Acc ss for Self- registrar registrar create balancin registr mized No, ess (no blanke certific balancin balancin anonymi g of ant’s e-mail acces via balan t ation g of g of zed e- request right to addre s via leg cing acces acces request request mail or’s object ss or a legal al requi s (no s to or’s or’s address legitimat N/A to No* web due due red) balanc non- legitimat legitimat or a web e providi form proce pro unles ing public e e form to interest ng to ss ces s requir WHOI interest interest contact against Non- contac only* s limite ed) S? against against registran data Public t only d unless data data t* subject’ WHOIS registr * exce limited subject’ subject’ s data* ant* ption except s s rights/fr * s ions rights/fr rights/fr eedoms apply apply* eedoms eedoms ** ** * ** ** Yes, accredita Yes, tion accred program itation Yes, No, similar to progra accred Yes, Yes, Accred acc Expert m to itation Yes, accredit accredit itation No, ess Working be progra accred ation ation progra acces via Group develo m itation program program m for s via leg recomme ped in based progra to be to be acces legal al ndations Yes* consul on m for develop develop No* N/A No* s to due due (access * tation existin limited ed in ed in non- proce pro given at with g user consulta consulta public ss ces level the proces groups tion with tion with WHOI only* s appropri GAC ses of ** the the S? only ate for and EU GAC** GAC** * each other ccTLD user and stakeh s** stated olders purpose) ** ** ** = More substantial change from status quo, Green = Greater preservation of status quo

4.1.4.1 Non-public WHOIS The non-public WHOIS regime can be categorized into a (self)-certification approach, accreditation approach, and legal due process approach.204 ICANN’s current contractual agreements (e. g., 2013 RAA and RA) with the respective parties (e. g., registries and registrars) and their requirement of public-query based access to WHOIS data will not be in line with the GDPR. Therefore, the current system requires modifications, and the encompassing question is: Who should be able to access non-public WHOIS data and under which procedures? The ‘Interim GDPR Compliance Model’ document dated 08 March 2018, discusses some of the main aspects of potential procedure models and highlights the advantages and disadvantages of the (self)-certification approach, the accreditation approach, and the legal due process approach of the respective models. The concepts of (self)- certification and accreditation are central for the layered/tiered access to non-public WHOIS data; nonetheless, the implementations must be compliant with the GDPR. The compliance

203 See ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 204 Cf ibid. ______Matthias Markus Hudobnik 41 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______with the GDPR may be doable with a certification process in the form of a code of conduct for non-public WHOIS data access according to Article 40 GDPR or a data protection certification mechanism under Article 42 GDPR.205 Under Article 41 GDPR, “the monitoring of compliance with a code of conduct pursuant to Article 40 may be carried out by a body which has an appropriate level of expertise in relation to the subject-matter of the code and is accredited for that purpose by the competent supervisory authority.”206 Taking this into account, the approved ‘code of conduct for non- public WHOIS data access’ must be monitored by an appropriate body following Article 41 GDPR. According to Article 42 GDPR, the certification permits data processors and/or controllers the explicit access to non-public WHOIS data while the certification is - pursuant to Article 43 GDPR - conducted by an accredited certified body, which is also in charge of the monitory of the certification process as such. This circumstance will be not further discussed since it is not directly related to the central questions of this work, but a detailed evaluation of the respective data fields is reported in the relevant subcategories below.207

4.1.4.1.1 Self-certification access The first subcategory of the fourth chart demonstrates that six out of twelve community models support the fact that a self-certification access to non-public WHOIS data should be performed; whereas, five of the whole Compliance Models are against this procedure and one does not even address this issue. ICANN Model 2A and 2B are in favor of a self-certification access to non-public WHOIS data with a slight modification on an interim basis, subject to registry/registrar balancing of requestor’s legitimate interest against data subject’s rights/freedoms. ICANN Model 1 has the same procedure but with the minor difference that there is no ‘interim basis.’ The IPC model is for blanket access where no balancing is required unless limited exceptions apply to it. Similarly, the GAC model supports the interim basis for blanket access, and there is also no balancing required unless limited exceptions are applicable. The Coalition for Online Accountability focuses on the subject to registrant’s right to object, to prove non-public WHOIS data access and the iThreat model does not address this issue at all. There are several significant differences between the Compliance Models mentioned above and the others who are not in favor of a self-certification access to non- public WHOIS data. Specifically, ICANN Model 3 and the Electronic Frontier Foundation model do not support the self-certification access procedure to non-public WHOIS data and are in favor of access via legal due process only. It is of note that the legal due process is the prevailing concept to grant access based on the respective legal frameworks or jurisdictions procedure (via an e. g., subpoena, warrant or court order for the relevant third party request)

205 Cf ICANN, ‘The Cookbook’ (n 16) 27. 206 See Article 41 (1) of the Regulation (EU) 2016/679 (n 6) 58. 207 Cf ICANN, ‘The Cookbook’ (n 16) 29. ______Matthias Markus Hudobnik 42 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______and, additionally, it should be mentioned that this is from a privacy point of view the most protective concept for data subjects.208 In contrast, it is interesting to note that there are commentators who criticize the high requirements of this concept to grant access, and believe that it is an obstacle and a delay for urgent cybercrime investigations via this WHOIS data access, as it is an effective method for identification purposes. Other community commentators argue that such access by law enforcement or intellectual property lawyers must be explicitly stipulated by law and this level of legal due process is appropriate.209 The ECO model, as well as the AppDetex model, which are against the self-certification access procedure to non-public WHOIS data, believe in the implementation of anonymized e-mail addresses or a web form to contact the registrant. The Feldman model also denies the self-certification access regime but does not offer any other potential solution.210 Additionally, self-certification access to non-public WHOIS data is an efficient approach in the sense that only third parties with a legitimate purpose are permitted to have access: something which is currently already in practice at the access to zone file data in particular. Although some of the community commenters believe that the case-by-case assessment at the self-certification access procedure – without a standardized review method for all gTLDs as a whole – will not be efficient and too elaborately for the involved parties (e. g., registries and registrars). Another crucial suggestion of some community commentators is to point out the fact that there should be an autonomous access-form for the self-certified parties limited to their specific purpose of access to prevent significant delays in connection with critical data sets and this will generally keep the procedure fast, simple, and efficient. Taking this into account will also help lessen the burden of the involved parties (e. g., registries and registrars) and accomplish data certainty for the users.211

4.1.4.1.2 Accreditation program for access The second subcategory of the fourth chart shows that, overall, seven out of twelve community models support the implementation of an accreditation program for access to non-public WHOIS data; whereas, four of the Compliance Models are against this program and one does not address this issue. ICANN Model 2A and 2B in consultation with the GAC model are in favor of developing an accreditation program for access to non-public WHOIS data but do not provide more specific details about this particular program. The ECO model only focuses on an accreditation program for limited user groups as well as the AppDetex model; however, with the minor difference that the AppDetex model believes in an accreditation program similar to the expert working group recommendations where access is given at an appropriate level for each user and stated purpose. The Feldman model supports the accreditation program for access to non-public WHOIS data based on existing processes of EU ccTLDs. The IPC model is

208 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 209 Cf ICANN, ‘The Cookbook’ (n 16) pp. 28-29. 210 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 211 Cf ICANN, ‘The Cookbook’ (n 16) pp. 27-28. ______Matthias Markus Hudobnik 43 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______in favor of the implementation of an accreditation program for access to non-public WHOIS data but does not address any potential solutions. Contradictorily, ICANN Model 3 and the Electronic Frontier Foundation model do not support an accreditation program for access to non-public WHOIS data and are in favor of access via legal due process only. Similarly, the ICANN Model 1, as well as the Coalition for Online Accountability model, which are also against an accreditation program for access to non-public WHOIS data but do not offer any other potential solutions. Finally, the iThreat model does not address this issue at all.212 Some community commenters summarized the bases of the accreditation approach in comparison to the self-certification approach as the following: Firstly, the accreditation program will allow the access to full WHOIS data in general and will lead to a burden reduction for the involved parties (e. g., registries and registrars) through the access-requests from several groups. Secondly, it supports the concept of data consistency and transparency across participants (e. g., registries and registrars) and guarantees a fair, confidential, and secure data exchange with the legitimate groups (e. g., law enforcement agencies, intellectual property lawyers, industry). The next step would be the implementation of the accreditation program for access to non- public WHOIS data as such. An additional concern of the implementation of the layered access model is the dimension of availability of data for the accredited users; namely, should it be the full WHOIS data set or bulk access to all WHOIS data records to mitigate criminal abuse effectively. Others recommend pursuing the concept of some ccTLDs, gaining the relevant data sets through the registry-contact-forms and deny the regime of full access to WHOIS data because there is no specific requirement necessary to do so.213

4.1.5 Conclusion The main aim of this subchapter is to address interim results of the first part of the research question, which generally focuses on how can access to crucial information and protected data in the WHOIS system be ensured? Specifically, the thesis focuses on the Compliance Models and whether the data fields of the essential criteria, such as: ‘data collection,’ ‘processing and retention,’ ‘scope of applicability’ and ‘tiered/layered access to non- public/public WHOIS’ data are compliant with the GDPR. The above data proves the first hypothesis; that the GDPR was the catalyst for the adoption of the Compliance Models and subsequently the modification process of the previous WHOIS database publication practices. In March 2017, ICANN started taking the WHOIS compliance issues seriously by holding a session called ‘Cross-Community Discussion with Data Protection Commissioners’ within the scope of ICANN58.214 From that time on, ICANN figured out their crucial role and regularly came under legal pressure because of the fast-approaching enforcement date of the GDPR. Subsequently, ICANN asked the various communities for input and the adoption of the

212 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 213 Cf ICANN, ‘The Cookbook’ (n 16) pp. 27-30. 214 Cf ICANN, ‘Panel on ICANN and Data Privacy issues’, Cross-Community Discussion with Data Protection Commissioners, ICANN58 meeting, 13 March 2017, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 44 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Compliance Models in line with the GDPR (this is further explored in Chapter 4). ICANN, even recognized the potential risk of incurring severe penalties if they fall under the application of the GDPR (further considered in Chapter 3.1.1) and had various conversations with the W29/EDPB (as previously emphasized in Chapter 2.2.3.1, 2.2.3.2, 3.2, 5.1.1 and 5.3.3) which already raised this compliance issue in 2003215 as well as 2006216 - without any success. The interim result was that the ICANN Board adopted Temporary Specification for gTLD Registration Data (further explained in Chapter 4.2) approved on 17 May 2018. This came into force briefly with the GDPR on 25 May 2018, followed by the EPDP on the Temp Spec. That these compliance issues were already highlighted in 2003/2006 was also part of the correspondence in the litigation, and criticized by the defendant (further details in Chapter 5.1.1 and 5.3.3). As a result, the present research results show that the GDPR was the catalyst for the adoption of the Compliance Models, as well as setting the procedure in motion. Starting with the detailed research questions on the Compliance Models of the charts in Chapter 4.1, this is analyzed as follows:

4.1.5.1 How can the purpose and lawfulness of processing activities be determined, and which data of the registrant is specifically collected? As pointed out in Chapter 4.1.3 and 4.1.1.1, and in line with EDPB’s guidelines, it is crucial to separate the various processing activities that are completed in the context of the WHOIS system and the exact purpose of the different parties that are implicated.217 The results of the investigation of the various Compliance Models show that there is generally a lack of accuracy in terms of the previously mentioned separation in almost all of the models, with the minor exception of the ECO model which very accurately explains their holistic approach, whilst also fulfilling the processing principles and the legal grounds of the GDPR. The research has also demonstrated that the vast majority of the Compliance Models stand behind the concept of full thick WHOIS data collection: they have no proper privacy impact assessment, no precise determination of the respective data fields in line with the principle of data minimization, and no revised purpose specification. The following conclusions can be drawn from the present study that there seems to be a definite need for a review of the purpose descriptions and expandability of the registration data processing activities beyond the original purpose description, in connection with the operation of the WHOIS system. A reasonable approach to tackle this issue could be to investigate the relationship of the principle of data minimization and data collection, and consider whether it is still necessary to collect the same amount of registrant’s personal data under the 2013 RAA, or if a reduction of data elements is requisite in order to be compliant with Article 5 (1) GDPR. These findings suggest that there are outdated data fields e. g., fax numbers, and physical addresses, which may no longer

215 Cf WP29, ‘Letter from Isabelle Falque-Pierrotin to Cherine Chalaby and Göran Marby regarding GDPR’ (n 63) 3. 216 Cf Article 29 Data Protection Working Party, ‘Letter from Peter Schaar to Vinton G. Cerf regarding WHOIS’, 22 June 2006, pp. 1-2, available at accessed 30 April 2019. 217 Cf EDPB, ‘Letter from Jelinek to Marby’ (n 69) pp. 2-3. ______Matthias Markus Hudobnik 45 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______necessarily be collected, and under Article 5 (1) lit. c) GDPR these fields might not be218 “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed.”219

4.1.5.2 What data can be transferred from the registrar to the registry and the data escrow agent? Initially, it should be mentioned that under the ‘Thick WHOIS Transition Policy’, registrars are contractually obligated to transfer full thick WHOIS data to registries.220 The results of Chapter 4.1.1.2 indicate that there is an almost holistic view of all Compliance Models – except two models – to support the approach of a full thick WHOIS data transfer. The parties involved justify this with the argument that, in case of a technical defect, the registry has the full registrant’s data set, and may transfer it to an additional registrar to foster the data redundancy, which is a data quality improvement as a whole.221 From a legal point of view, the transfer of registrant’s personal data from registrants to registries must be based on a legal principle, which may be, in this context, the principle of legitimate interests.222 The most prominent finding to emerge from this study is that the legal principles under the GDPR are currently not sufficient enough to justify the registration data transfer from registrars to registries.223 The results are equal in the context of the data escrow agent, where the transfer of full thick registration data from a gTLD registry operator or accredited registrar to the data escrow agent is also based on the principle of legitimate interests.224 The following conclusion can be drawn from the present study: that ICANN may also extend the purpose description transfer (further details concerning the purpose description explained in Chapter 4.1.3) with regards to the full thick WHOIS data processing activities, in order to be compliant with Article 5 GDPR.225

4.1.5.3 How long should the period of data retention for the registrar, registry, and the escrow agent be? The findings in Chapter 4.1.1.4 convey that, in general, the majority prefer a retention period during the life of the registration. However, the data shows a different range for the retention period beyond the registration from a minimum of 60 days to one or two years, depending on the respective model. The question raised by this study is whether the lawfulness of processing is in line with the particular processing purposes, and whether the particular data retention elements fulfill the criteria of the GDPR in any case. The adequate lengths of the retention period might be concluded from this question. This information can be used to develop a list, with the legal basis for data retention requirements for every data element

218 Cf ICANN, ‘The Cookbook’ (n 16) 10. 219 See Article 5 (1) lit. c) of the Regulation (EU) 2016/679 (n 6) 35. 220 Cf ICANN, ‘Thick WHOIS Transition Policy’ (n 157). 221 Cf ICANN, ‘The Cookbook’ (n 16) pp. 13-14. 222 Cf Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 223 Cf ICANN, ‘The Cookbook’ (n 16) pp. 13-14. 224 Cf Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 225 Cf ibid. ______Matthias Markus Hudobnik 46 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______corresponding with the exact legitimate purpose for the collection and the lawful basis for the retention in order to be compliant with the GDPR, which was previously fostered by ICANN.226

4.1.5.4 What is the scope of applicability for the different possible Compliance Models? Initially, the encompassing question is whether the Compliance Models should apply globally; autonomous of the location of the respective parties mentioned above, or only to the EEA, namely where the nexus of parties exist.227 The current data in Chapter 4.1.2.1 highlights that the majority of the community models apply only to the EEA.228 Nevertheless, there are some respectable arguments for both approaches comprehensively analyzed in Chapter 4.1.2.1 and in terms of the legal perspective in Chapter 4.1.2.2. The most prominent finding to emerge from this study is a discussion of whether the scope of this extra-territoriality is convincingly applicable on the WHOIS system, and in terms of data processing activities on a global scale, given the obstacles regarding the exact scope of where the GDPR applies. However, there is a strong possibility that the recent signs of progress will improve in the long term, and the WHOIS system may be a more uniform and consistent system for a broader range of jurisdictions.229

4.1.5.5 How is the access to public/non-public WHOIS data to be organized, for example via accreditation program or a tiered/layered access model? The aim of the first part of this research question is to examine in general: How can access to crucial information and protected data in the WHOIS system be ensured? Specifically, the thesis focuses on the Compliance Models concerning the public WHOIS data and draws a line between the legitimate interests of the involved parties, and the data subject’s rights and freedoms, as it is their data that is processed in the WHOIS databases. The following conclusions of public WHOIS data can be drawn from the present data of Chapter 4.1.3.1. There should be:  No publication of the name data field of the registrant with the exception of the organization/legal entity of the registrants, in case the name of the legal entity includes personal data via the link to the natural person (e. g., registrant)  No publication of the address data field of the registrant (e. g., city, postal code, street) with the exception of the country and state/province. As a result, a general identification/localization of the registrant is possible, but personal details will only be provided to accredited users  No publication of the registrant’s e-mail address data field, meaning that general contact is possible without the identification of the registrant via a web form or an anonymized e-mail address (e. g., forwarded to the registrants one)

226 Cf ICANN, ‘The Cookbook’ (n 16) pp. 16-18. 227 Cf ICANN, ‘The Cookbook’ (n 16) 19. 228 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). 229 Cf ICANN, ‘The Cookbook’ (n 16) pp. 19-21. ______Matthias Markus Hudobnik 47 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

 No publication of the registrant’s phone and fax number data field  No publication of the registrant’s administrative and technical contact details data field. As a result, general contact is possible without the identification of the registrant’s administrative and technical contact via a web form or an anonymized e-mail address (e. g., forwarded to the registrant’s administrative and technical contacts one).230 The aim of the second part of the present research question is to scrutinize the Compliance Models concerning the non-public WHOIS data and the results of the self-certified access, as well as the accreditation program for access to non-public WHOIS data. A closer examination of the data in Chapter 4.1.4.1 concerning the access to full non-public WHOIS data for third party interests provides the following:  The ‘self-certification approach’ of the third party means that the respective party is declaring their specific legitimate purpose and the access to full WHOIS data is only lawfully permitted under the limitation of this particular purpose  The ‘certification approach,’ which is the same as above, applies and, additionally, a code of conduct must be approved to be compliant  The ‘accreditation approach’ means that only third parties selected and certified or accredited via an accredited program, are permitted to access the full WHOIS data set  The ‘legal due process approach’ is based only on the respective applicable law or jurisdiction e. g., a subpoena or an order from a court or tribunal of the third party which permits the access to full WHOIS data for this respective party.231 Taken together, these results from Chapter 4.1.4.1.1 highlight that generally, six out of twelve community models support the fact that self-certified access to non-public WHOIS data should be performed; whereas, five of the whole Compliance Models are against this procedure and one does not address this issue. There are several significant differences between the various Compliance Models and procedures which are comprehensively analyzed in Chapter 4.1.4.1.1. In the context of an accreditation program for access to non-public WHOIS data, the results of Chapter 4.1.4.1.2 illustrate that the majority of the community models are supporting the implementation of an accreditation program. There may not be definite conclusions drawn from the present data because there is a diverse range of potential methods to solve the non- public WHOIS data access debate. Possible solutions include: a case-by-case assessment regarding self-certified access; access via legal due process; the implementation of anonymized e-mail addresses or a web form to contact the registrant; and an accreditation program for access to non-public WHOIS data.232 This research has generated many questions regarding how can access to crucial information and protected data in the WHOIS system be ensured? This may potentially not be sufficient to

230 Cf ICANN, ‘The Cookbook’ (n 16) pp. 26-27. 231 Cf ICANN, ‘The Cookbook’ (n 16) 27. 232 Cf ICANN, ‘Selected Interim GDPR Compliance Models & Comments’ (n 143). ______Matthias Markus Hudobnik 48 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______be compliant with the GDPR, but simply a first step in the right direction via the procedures explained above. A reasonable risk in this approach to ensuring access to crucial information and protected data in the WHOIS system, is that at a third party request, some of the respective parties, such as registrars, may safeguard criminals under the guise of protecting the registrant’s privacy; and therefore, may not release any critical information. The results of an accreditation program in Chapter 4.1.4.1.2 support the idea of potentially implementing a layered access model, contractually tied to a code of conduct or a similar policy document.233

4.2 Temporary Specification for gTLD Registration Data This section descriptively reflects the Temporary Specification for gTLD Registration Data (Temp Spec) approved on 17 May 2018 by the ICANN Board, effective on 25 May 2018, which allows ICANN and the gTLD registry operators and registrars to continue their current work under temporary rules to fulfill the existing ICANN agreements and community-developed policies in light of the GDPR.234 Additionally, the Temp Spec may remain effective for up to one year, and the ICANN Board must reaffirm these interim rules every 90 days from their validity, namely from the 25 May 2018. The Temp Spec applies to all involved parties (e. g., registry operators and registrars) via the contractual agreements and the temporary policy specifications in the 2013 RAA and the RA, but does not alter contracted parties data collection, data retention, data transfer, and escrow obligations. The implementation of the Temp Spec is mandatory for all contracted parties regardless of the territoriality. Furthermore, there is a scope of applicability, as there is no distinction of legal entities, and whether the registrant is a natural or legal person as such.235 A closer examination of the Temp Spec document conveys that there are several similarities with ICANN’s Compliance models from e. g., ICANN Model 1 to 2A, 2B, 3 to the final ‘Interim Model,’ the so-called ‘Calzone Model’. Furthermore, ICANN is trying to bridge the gap between ICANN’s mission stated in their bylaws and the GDPR compliance, while trying to retain the current WHOIS system to the greatest extent possible. Taking this into account, the author demonstrates below in chart number five, the alteration of ICANN’s final Compliance Model so- called ‘Calzone Model’ and the Temp Spec. This data is also comparable to the other Compliance Models analyzed in Chapter 4.1; whereas, the data set structure is the same as the following: ‘data collection, processing, and retention,’ ‘scope of applicability and ‘layered/tiered access to WHOIS data.’ Consequently, this allows the reader of this diploma thesis to quickly acquire a clear understanding of the different Compliance Models and the Temp Spec, as well as their focus in the context of the WHOIS system in compliance with the

233 Cf ICANN, ‘The Cookbook’ (n 16) pp. 28-29. 234 Cf ICANN, ‘Temporary Specification for gTLD Registration Data’ (n 64) pp. 1-2. 235 Cf ICANN, ‘Summary of the Temporary Specification for gTLD Registration Data’, Webinar, Global Domains Division & Contractual Compliance, 6 June 2018, pp. 4-6, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 49 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

GDPR. Thus, the author will point out the significant change of the state of the art situation and the differences between these two models.236

Table 5: Calzone Model v. Temp Spec237

Temporary Specification for gTLD Registration ICANN Interim Model (Calzone Model) Data (Temp Spec) Data Collection, processing and retention Collection from registrant to Full thick data Full thick data** registrar Data transfer from registrar to Full transfer of data collected Full transfer of data collected** registry Data transfer to escrow agents Full transfer of data collected Full transfer of data collected** Life of registration + 2 years (note: Life of registration + 2 years** (note: existing Data retention existing waivers for European registrars waivers for European registrars would be preserved) would be preserved) Applicability Must be applied to EEA, may be applied Must model be applied globally globally, subject to a data processing Must be applied to EEA, may be applied beyond EEA or only to European economic agreement between ICANN and the where it is commercially reasonable to do so area? contracted parties Registrations of natural and legal Registrant types affected Registrations of natural and legal persons persons Layered/tiered access to WHOIS data Public WHOIS Registrant name in public Only registrant organization (if applicable) Only registrant organization (if applicable) in public WHOIS? in public WHOIS (not registrant name) WHOIS (not registrant name) Only registrant state/province and Registrant postal address in Only registrant state/province and country in public country in public WHOIS (not registrant public WHOIS? WHOIS (not registrant street, city, postal code) street, city, postal code) Registrar is required to create anonymized e-mail or Registrant e-mail in public Create anonymized e-mail or a web form a web form to contact registrant WHOIS? to contact registrant Registry is required to direct user to registrar for method to contact registrant Registrant phone and fax in No No public WHOIS? Administrative and technical No No contact names in public WHOIS? Administrative and technical contact postal addresses in No No public WHOIS? Registrar is required to create anonymized e-mail or a web form to contact administrative and technical Administrative and technical Create anonymized e-mail or a web form contacts contact e-mail addresses in to contact administrative and technical registry is required to direct user to registrar for public WHOIS? contacts method to contact Administrative and technical contacts Administrative and technical No No contact phone in public WHOIS? Registrar must offer opt-in to publish additional Registrars offering to opt-in to registrant data; registrar may (but is not required) to publish additional data in public Yes offer opt-in to publish additional Admin and Tech WHOIS? contact data Non-public WHOIS No. Create anonymized e-mail address or Self-certification access to non- a web form to contact registrant or due No public WHOIS? process Yes, in consultation with the Yes, registrar and registry required to provide Governmental Advisory Committee, data reasonable access to non-public data to 3rd parties protection authorities and contracted with legitimate interests, except where overridden by parties with full transparency to the interests or fundamental rights and freedoms of data ICANN community. User groups with a subject; also required to provide access where Unified access model for access legitimate interest and who are bound to WP29/European Data Protection Board, relevant to non-public WHOIS? abide by codes of conduct requiring court, applicable legislation or regulation provides adequate measures of protection could guidance that provision of data to specified classes access non-public WHOIS data based on of users is lawful. Further community discussion will pre-defined criteria and limitations under result in standardized unified access model to be the unified access model. implemented. ** Means no change needed in Temp Spec because already required by existing provisions.

Chart number five from this subchapter shows that the first category ‘data collection, processing, and retention’ of the above named two models is divided into four subcategories of collection from registrant to registrar, data transfer from registrar to registry, data transfer to

236 Cf ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’, 17 May 2018, available at accessed 30 April 2019. 237 See ibid. ______Matthias Markus Hudobnik 50 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______escrow agents and data retention, and the results of the two models in this category are identically. As a result, there is no change in the Temp Spec necessary because the existing provisions already require it. Further details of the category ‘data collection, processing, and retention’ in connection with the other Compliance Models are comprehensively analyzed in Chapter 4.1.1.238 In the second category ‘scope of applicability’ is to remark that both models must be applied to the EEA when the processing of personal data is connected to the EEA and may apply on a global level if it is unfeasible for contracted parties to restrict their requests stringently to the EEA.239 As subject to a data processing agreement between ICANN and the contracted parties, as clarified above, all contracted parties are obliged to apply the Temp Spec regardless of their geographical location. In terms of the legal entities, the registrations of domain names by a natural and/or legal person refer to the examples as outlined in Chapter 4.1.2.2. Further details of the category ‘scope of applicability’ in connection with the other Compliance Models are comprehensively analyzed in Chapter 4.1.2.240 The third category, ‘layered/tiered access to public WHOIS data,’ illustrates the different data fields and their entitled existence. In short, the broadest modification is that only the registrant’s organization (if applicable) field will be displayed in the public WHOIS database but not the names of the respective registrants. The same applies to the registrant’s postal address; only the registrant’s state/province and country will be shown in the public WHOIS database, not the registrants street, city, and postal code. In terms of the e-mail address data field of the registrants, the Calzone Model differs from the Temp Spec. The Calzone Model suggests creating an anonymized e-mail or a web form to contact registrants while the Temp Spec classifies this data field in provisions for registries and registrars. The registries are obligated to direct users to registrars for the method to contact registrants, and the registrars are required to create an anonymized e-mail or a web form to contact registrants. Here again, the Calzone Model suggests creating an anonymized e-mail or a web form to contact registrants while the Temp Spec categorizes this data field in requirements for registries and registrars. The registries are obligated to direct users to registrars for the method to contact administrative and technical contacts, and the registrars are required to create an anonymized e-mail or a web form to contact administrative and technical contacts. The last significant distinction in this category is the opt-in proposal of registrars that permits publishing additional data in the public WHOIS database. The Calzone Model is in favor of this opt-in declaration, while the Temp Spec substantiates and enhances it as registrars are obligated to offer an opt- in statement to publish additional personal data of the registrants while registrars may (but are not required) offer an opt-in statement to publish additional administrative and technical contact data. Further details of the category ‘layered/tiered access to public WHOIS data’ in

238 Cf ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’ (n 236). 239 Cf ICANN, ‘ICANN Board Approves Temporary Specification for gTLD Registration Data’, 17 May 2018, available at accessed 30 April 2019. 240 Cf ICANN, ‘Summary of the Temporary Specification for gTLD Registration Data’ (n 235) 6. ______Matthias Markus Hudobnik 51 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______connection with the other Compliance Models are comprehensively analyzed in Chapter 4.1.3. In the fourth category, ‘layered/tiered access to non-public WHOIS data,’ both models share several similar key features with minor differences. As in regards to the self-certification access to non-public WHOIS data, both models negate this data field, but the Calzone Model offers the solution of creating an anonymized e-mail address or a web form to contact registrants or a due process, similar to the methods of category three as outlined above. In connection with the Unified Access Model for Access to non-public WHOIS data, the Calzone Model, as well as the Temp Spec, support this approach while the Calzone Model follows the path in conjunction with other involved actors e. g., GAC, DPA’s and the contracted parties with full transparency to the ICANN community.241 As stated in chart number five, in the category non-public WHOIS of this subcategory are defined as being “user groups with a legitimate interest, who are bound to abide by codes of conduct requiring adequate measures of protection could access non-public WHOIS data based on pre-defined criteria and limitations under the unified access model.”242 Whereas, the Temp Spec specifies this category of non-public WHOIS that registries and registrars are obliged to offer reasonable access to non-public WHOIS data as the third party request has legitimate interests and does not override interests or fundamental rights and freedoms of data subjects. This condition is also postulated where e. g., the EDPB/WP29, relevant courts, applicable legislations or regulations assist advice that particular terms and provisions of data to specified classes of users are legitimate. The final community discussions should lead to an implementation of a Unified Access Model for non-public WHOIS data.243 Further details of the category ‘layered/tiered access to non-public WHOIS data’ in connection with the other Compliance Models are examined in Chapter 4.1.4. For the sake of completeness, it should be mentioned that the EDPB has evaluated some potential compliance issues of the Temp Spec in connection with the GDPR, as well as having provided crucial guidance and potential answers to open questions which are also related to the case ICANN v. EPAG, and will be comprehensively analyzed in Chapter 5.244

4.2.1 Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data It should be noted for this subchapter that the Policy Development Process is still in progress and not finalized. The author aims to provide the reader with an overview of the recommendations of the Generic Names Supporting Organization (GNSO) EPDB on the Temp Spec, but the focus of this work is on the Compliance Models as well as the litigation ICANN v. EPAG. As already stated in the introduction of Chapter 4.2, the Temp Spec was approved on 17 May 2018 by the ICANN Board, enter into force on 25 May 2018, which allows ICANN and the gTLD registry operators and registrars to continue their current work under temporary rules

241 Cf ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’ (n 236). 242 See ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’ (n 236). 243 Cf ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’ (n 236). 244 Cf EDPB, ‘Letter from Jelinek to Marby’ (n 69) pp. 1-4. ______Matthias Markus Hudobnik 52 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______to fulfill the existing ICANN agreements and community-developed policies in light of the GDPR.245 Consequently, the next step, after the Temp Spec came into force, was the EPDP on the Temp Spec initiated on 19 July 2018 by the GNSO with the objective of agreeing whether or not, the Temp Spec may be ultimately realized as an ICANN Consensus Policy within the period of twelve months from their validity implementation from 25 May 2018.246 Additionally, the final result of the EPDP should be compliant with the GDPR and other respective data protection and privacy laws.247 The EPDP draft team (e. g., the council leadership, and interested council members) articulated an EPDP-initiation request, followed from the adoption of an EPDP-charter248 to make concrete the issues that the EPDP will potentially observe.249 On 04 March 2019, the GNSO approved the EPDP on the Temp Spec, which was the beginning to realize an ICANN Consensus Policy through a modification process of the current WHOIS system to replace the Temp Spec. The ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (final report), dated 20 February 2019, consists of 29 policy recommendations (e. g., data processing purpose, data elements for collection, transfer, retention, and redaction) and reflects on the adjustment or even deletion of a number of data elements which will no longer be necessary. As well as underscores the final decision of the litigation ICANN v. EPAG. The author focuses on the most relevant recommendations of the final report; otherwise, it would go far beyond the scope of the diploma thesis and its research questions.250 Recommendation 1 illustrates the discussion regarding the purposes of the processing of gTLD registration data in the context of the new ICANN policy in seven points as the following: Firstly, the subjects of this preliminary recommendation are terms, conditions, and policies of registries, registrars, and ICANN Consensus Policies. The main scope is to determine the rights of registrants of a registered domain name and to safeguard that registrants can utilize their rights of use, and disposition of the registered domain name, as well as to handle the activation and respective allocation to another registrant. Secondly, the preservation of the security, stability, and resilience of the DNS in line with the mission of ICANN, while permitting access and release to legitimate data requests and not excluding the publication of intellectual property investigations. Thirdly, to facilitate the interaction and notification with the registrant and their representative in the context of the registered domain name. Fourthly, the registration data of a registrant must be maintained securely in case of non-availability, a business mistake, or technical break down of a gTLD registry operator or accredited

245 Cf ICANN, ‘ICANN Board Approves Temporary Specification’ (n 239). 246 Cf ICANN, ‘How to Get Involved: Launch of the EPDP on the Temporary Specification for gTLD Registration Data’, available at accessed 30 April 2019. 247 Cf ICANN GNSO, ‘Initial Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’, Executive Summary, 21 November 2018, available at accessed 30 April 2019. 248 Cf GNSO Council, ‘Motion to Approve the Charter for the Temporary Specification for gTLD Registration Data EPDP Team’, 19 July 2018, available at accessed 30 April 2019. 249 Cf GNSO Council, ‘Expedited Policy Development Process Initiation Request’, 19 July 2018, available at accessed 30 April 2019. 250 Cf ICANN GNSO, ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’, 20 February 2019, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 53 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______registrar.251 Fifthly, the handling of contractual compliance monitoring requests, audits and complaints filed by respective parties e. g., ICANN, registry operators, registrars, registrants, and others in line with the RA, 2013 RAA and any “applicable data processing agreements, by processing specific data only as necessary.”252 Sixthly, to organize the operationalization and adoption of “policies for the resolution of disputes regarding or relating to the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names), namely, the UDRP, URS, PDDRP, RRDRP, and the TDRP.”253 Seventhly, to establish a validation system for a non-compulsory gTLD registration policy confirmation for registrants on eligible principles, facilitated, and implemented by registry operators voluntarily as well as embedded in the RA.254 Recommendation 5 defines the data elements required to be collected by registrars as follows:255

Table 6: Recommendation 5, the registrars collected data elements256

Data elements (collected & generated*) Collection logic Domain name Required Registrar WHOIS server* Required Registrar URL* Required Registrar registration expiration date* Optional Registrar* Required Registrar IANA ID* Required Registrar abuse contact e-mail* Required Registrar abuse contact phone* Required Reseller* Optional Domain status(es)* Required Registrant fields -Name Required -Organization Optional -Street Required -City Required -State/province Required -Postal code Required -Country Required -Phone Required -Phone ext Optional -Fax Optional -Fax ext Optional -E-mail Required Tech fields -Name Optional -Phone Optional -E-mail Optional Name server(s) Optional DNSSEC Optional Name server IP address(es) Optional Additional data elements as identified by registry Optional operator in its registration policy, such as (i) status as registry operator affiliate or trademark licensee [.MICROSOFT]; (ii) membership in community [.ECO]; (iii) licensing, registration or appropriate permits (.PHARMACY, .LAW] place of domicile [.NYC]; (iv) business entity or activity [.BANK, .BOT]

As shown in the table above, the collection logic ‘optional’ means that registrars may offer this collection optionally or registrants may provide these data elements optionally, and if so, in

251 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 5. 252 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 5. 253 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 6. 254 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 6. 255 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 7-8. 256 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 7-8. ______Matthias Markus Hudobnik 54 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______both variants, the data elements must also be processed.257 In the context of the technical contact, it is essential to note that registrants may optionally provide these data sets if foreseen by the registrar. As a result, the EPDP team recommends that the registrar informs the registrant at the registration procedure about the free choice either to firstly “designate the same person as the registrant or its representative as the technical contact”258 or secondly “provide contact information which does not directly identify the technical contact person concerned.”259 Recommendation 7 defines and identifies which particular data elements are transferred from registrars to registries.

Table 7: Recommendation 7, transfer of data elements from registrar to registry260

Data elements (collected & generated*) Transfer logic Domain name Required Registrar WHOIS server* Required Registrar URL* Required Registrar registration expiration date* Optional Registrar* Required Registrar IANA ID* Required Registrar abuse contact e-mail* Required Registrar abuse contact phone* Required Reseller* Optional Domain status(es)* Required Registrant fields -Name Optional -Organization Optional -Street Optional -City Optional -State/province Optional -Postal code Optional -Country Optional -Phone Optional -Phone ext Optional -Fax Optional -Fax ext Optional -E-mail Optional Tech fields -Name Optional -Phone Optional -E-mail Optional Name server(s) Optional DNSSEC Optional Name server IP address(es) Optional Additional data elements as identified by registry Optional operator in its registration policy, such as (i) status as registry operator affiliate or trademark licensee [.MICROSOFT]; (ii) membership in community [.ECO]; (iii) licensing, registration or appropriate permits (.PHARMACY, .LAW] place of domicile [.NYC]; (iv) business entity or activity [.BANK, .BOT]

Recommendation 8 deals with data processing policies among the data escrow providers and ICANN, and endorse ICANN to focus on “legally-compliant data processing agreements”261 with the respective data escrow providers. The EPDP team also suggests refreshing the contractual specifications – for the transfer of the processed data to the data escrow provider – of the involved parties (e. g., registries and registrars). This approach will foster the consistency and

257 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 7. 258 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 8. 259 See ibid. 260 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 9-10. 261 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 10. ______Matthias Markus Hudobnik 55 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______legitimacy of their purpose description of the particular data elements listed below as the following:262

Table 8: Recommendation 8, transfer registrars to the data escrow agent263

Data elements (collected & generated*) Collection logic Domain name Required Registrar registration expiration date* Optional Registrar* Required Reseller* Optional Registrant fields -Name Required -Street Required -City Required -State/province Required -Postal code Required -Country Required -Phone Required -Phone ext Optional -Fax Optional -Fax ext Optional -E-mail Required Tech fields -Name Optional -Phone Optional -E-mail Optional

Table 9: Recommendation 8, transfer registries to the data escrow agent264

Data elements (collected & generated*) Collection logic Domain name Required Registry domain ID* Required Registrar WHOIS server* Required Registrar URL* Required Updated date* Required Creation date* Required Registry expiry date* Required Registrar registration expiration date* Optional Registrar* Required Registrar IANA ID* Required Registrar abuse contact e-mail* Required Registrar abuse contact phone* Required Reseller* Optional Domain status(es)* Required Registry registrant ID* Required Registrant fields -Name Optional -Organization Optional -Street Optional -City Optional -State/province Optional -Postal code Optional -Country Optional -Phone Optional -Phone ext Optional -Fax Optional -Fax ext Optional -E-mail Optional Tech fields -Name Optional -Phone Optional -E-mail Optional Name server(s) Optional DNSSEC Optional Name server IP address(es) Optional Additional data elements as identified by registry Optional operator in its registration policy, such as (i) status as registry operator affiliate or trademark licensee [.MICROSOFT]; (ii) membership in community [.ECO]; (iii) licensing, registration or appropriate permits (.PHARMACY, .LAW] place of domicile [.NYC]; (iv) business entity or activity [.BANK, .BOT]

262 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 10. 263 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 10-11. 264 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 11-12. ______Matthias Markus Hudobnik 56 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Recommendation 10 suggests a reduction of processed personal data in the public Registration Data Directory Service (RDDS) already utilized in the Temp Spec (e. g., the registry domain ID, the registry registrant ID, the registrant’s data fields, and the tech fields), as well as the publication and access via the query service of such data fields if they are neither redacted nor anonymized as can be seen in Table 10.265

Table 10: Recommendation 10, requirements for processing personal data in public RDDS266

Data elements (collected & generated*) Redacted Disclosure logic Domain name No Required Registry domain ID* Yes Required Registrar WHOIS server* No Required Registrar URL* No Required Updated date* No Required Registry expiry date* No Required Registrar registration expiration date* No Optional Registrar* No Required Registrar IANA ID* No Required Registrar abuse contact e-mail* No Required Registrar abuse contact phone* No Required Reseller* No Optional Domain status(es)* No Required Registry registrant ID* Yes Required Registrant fields -Name Yes Required -Organization Yes Required -Street Yes Required -City Yes Required -State/province No Required -Postal code Yes Required -Country No Required -Phone Yes Required -E-mail Yes Required Tech ID* Yes Required Tech fields -Name Yes Required -Phone Yes Required -E-mail Yes Required Name server(s) No Optional DNSSEC No Optional Name server IP address(es) No Optional Last update of Whois database* No Required

In a nutshell, Recommendation 12 suggests that the registrant’s information in the organization data field is subject of a further confirmation process of the respective registrant, namely whether the registrant confirms the further publication or not. A negation of the publication results in redaction or deletion of the respective data field. The recommendation also clarifies that there will be a transition period for the registrars to handle current and past registrations, as well as to implement a procedure for future registrations. During this phase, it will be permitted to redact the organization data field. A registry operator may redact or publish the respective data field in the RDDS.267 Recommendation 13 endorses the registrar - which is also in line with Section 2.5.1 of the Temp Spec - in the context of the e-mail communication to facilitate an e-mail address or a web form to reach the appropriate point of contact. An identification or publication of the contact or the e-mail address is just with the consent of the registrant lawful. Moreover, the EPDP recommends at the registrars level to store log files anonymously to certify the

265 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 49-50. 266 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 49-50. 267 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 51-52. ______Matthias Markus Hudobnik 57 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______communication course between the involved parties, but without the original content of the conversation, as well as the parties to ensure ICANN’s compliance purposes in the event of a request.268 Recommendation 16 recommends that “registrars and registries are permitted to differentiate between registrants on a geographic basis, but are not obligated to do so.”269 Recommendation 17 proposes the possibility for registries and registrars to distinguish between legal and natural persons in the registration process, but it is not compulsory, as well as the final result of this issue will be determined in Phase 2 of the EPDP.270 Recommendation 20 highlights the following data processing activities and involved parties to be considered within the gTLD registration data process documented in Phase 1. It is worth to mention that this recommendation is not the final result and may be changed by the final contractual agreements where the roles and responsibilities will be determined.271

Table 11: Recommendation 20, purposes, processing activities, parties, and lawful basis272

ICANN purpose1 As subject to Registry and Registrar terms, conditions and policies, and ICANN Consensus Policies: - To establish the rights of a Registered Name Holder in a Registered Name; to ensure that a Registered Name Holder may exercise its rights in the use and disposition of the Registered Name; and - To activate a registered name and allocate it to a Registered Name Holder. Processing activity Responsible party2 Lawful basis3 ICANN Article 6 (1) lit. b) GDPR for registrars Collection Registrars Article 6 (1) lit. f) GDPR for ICANN and registries Registries Certain data elements (domain name and name servers) would be Transmission from Registrars required to be disclosed. The lawful basis would be Article 6 (1) lit. b) registrar to registry Registries GDPR should personal data be involved for registrars and Article 6 (1) lit. f) GDPR for registries. For other data elements Article 6 (1) lit. f) GDPR. Certain data elements (domain name and name servers) would be Registrars required to be transferred from the registrar to registry. The lawful basis Disclosure Registries would be Article 6 (1) lit. b) GDPR should personal data be involved for registrars and Article 6 (1) lit. f) GDPR for registries. Data retention ICANN Article 6 (1) lit. f) GDPR 1) The term ICANN purpose is used to describe purposes for processing personal data that should be governed by ICANN organization via a Consensus Policy. Note there are additional purposes for processing personal data, which the contracted parties might pursue, but these are outside of what ICANN and its community should develop policy on or contractually enforce. It does not necessarily mean that such purpose is solely pursued by ICANN organization. 2) Note, the responsible party is not necessarily the party carrying out the processing activity. This applies to all references of ‘responsible party’ in these tables. 3) In relation to the application of Article 6 (1) lit. b) GDPR, input provided by external legal counsel. ICANN purpose Maintaining the security, stability and resiliency of the Domain Name System In accordance with ICANN’s mission through the enabling of lawful access for legitimate third-party interests to data elements collected for the other purposes identified herein. Processing activity Responsible party Lawful basis ICANN Collection Registrars Article 6 (1) lit. f) GDPR Registries Transmission from N/A N/A

268 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 52-53. 269 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 57. 270 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 57. 271 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 67. 272 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 67-71. ______Matthias Markus Hudobnik 58 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

registrar to registry Disclosure ICANN Article 6 (1) lit. f) GDPR Data retention ICANN N/A ICANN purpose Enable communication with and/or notification to the Registered Name Holder and/or their delegated agents of technical and/or administrative issues with a Registered Name Processing activity Responsible party Lawful basis Registrar Article 6 (1) lit b) GDPR for registrars Collection Registries Article 6 (1) lit f) GDPR for registries Transmission from ICANN Article 6 (1) lit. f) GDPR registrar to registry Registries Disclosure TBD N/A Data retention ICANN N/A ICANN purpose Provide mechanisms for safeguarding Registered Name Holders’ Registration Data in the event of a business or technical failure, or other unavailability of a Registrar or Registry Operator Processing Activity Responsible party Lawful basis Collection ICANN Article 6 (1) lit. f) GDPR Transmission from ICANN Article 6 (1) lit. f) GDPR registrar to registry Disclosure ICANN Article 6 (1) lit. f) GDPR Data retention ICANN Article 6 (1) lit. f) GDPR ICANN purpose Handle contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users. Processing Activity Responsible party Lawful basis Collection ICANN Article 6 (1) lit. f) GDPR5 Transmission from ICANN Article 6 (1) lit. f) GDPR registrar to registry Disclosure N/A N/A Data Retention ICANN Article 6 (1) lit. f) GDPR ICANN purpose Coordinate, operationalize and facilitate policies for resolution of disputes regarding or relating to the registration of domain names (as opposed to the use of such domain names), namely, the UDRP, URS, PDDRP, RRDRP and future-developed domain name registration- related dispute procedures for which it is established that the processing of personal data is necessary Processing Activity Responsible party Lawful basis ICANN Article 6 (1) lit. b) GDPR for registrars Collection Registrars Article 6 (1) lit. f) GDPR for registries ICANN Transmission from Article 6 (1) lit. b) GDPR for registrars Registries registrar to registry Article 6 (1) lit. f) GDPR for registries Registrars ICANN Registries Transmission to dispute Registrars dispute Article 6 (1) lit. b) GDPR for registrars resolution providers resolution provider - Article 6 (1) lit. f) GDPR for registries and ICANN processor or independent controller Disclosure N/A N/A Data retention N/A N/A ICANN purpose Enabling validation to confirm that Registered Name Holder meets optional gTLD registration policy eligibility criteria voluntarily adopted by Registry Operator. Processing Activity Responsible party Lawful basis Collecting specific data for Article 6 (1) lit. b) GDPR for registrars RA-mandated eligibility Registries Article 6 (1) lit. f) GDPR for registries requirements Collecting specific data for Article 6 (1) lit. b) GDPR for registrars Registries registry operator-adopted Article 6 (1) lit. f) GDPR for registries

______Matthias Markus Hudobnik 59 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

eligibility requirements Transmission from registrar to registry RA- Article 6 (1) lit. b) GDPR for registrars Registries mandated eligibility Article 6 (1) lit. f) GDPR for registries requirements Transmission from registrar to registry Article 6 (1) lit. b) GDPR for registrars Registries registry-adopted eligibility Article 6 (1) lit. f) GDPR for registries requirements Disclosure Registries N/A Data retention Registries Article 6 (1) lit. f) GDPR

Recommendation 22 determines the significance of data processing agreements of ICANN organization with disputed resolution providers to determine the data retention period, as well as other items and fosters the possibility to release these decisions in public.273 Recommendation 26 refers to the provisions of joint controllers in Article 26 GDPR, processors in Article 28 GDPR, and furthermore, portrays the eligibility of ICANN organization to complete contractual agreements (e. g., Data Processing Agreement, Joint Controller) with data escrow providers and EBERO providers. These non-contracted parties are a crucial part of the registration data processing chain and are essential for establishing the requirements, and processes concerning the various data processing parties in general.274 Recommendation 27 suggests updating the relevant and necessary policy documents and procedures within the framework of the WHOIS system as the following documents: “Registry Registration Data Directory Services Consistent Labeling and Display Policy, Thick WHOIS Transition Policy for dot com, dot net, dot jobs, Rules for Uniform Domain, Name Dispute Resolution Policy, WHOIS Data Reminder Policy, Transfer Policy, Uniform Rapid Suspension System Rules.”275 Pursuant to Recommendation 28, the final gTLD Registration Data Policy shall be effective on 29 February 2020 and both, registries and registrars should be compliant - either via this final gTLD Registration Data Policy or the modification of the current practices to be in line with the Temp Spec, which expires on 25 May 2019 - until this date. Furthermore, the modifications of registries and registrars - to fulfill the (expired) Temp Spec - will not be sanctioned, particularly those modifications till 29 February 2020.276 Recommendation 29 focuses on remaining domain registrations with an administrative contact but with no or incomplete contact information of the registrant. Therefore, the recommendation is that previously to the removal of the “administrative contact fields, all registrars must ensure that each registration contains registered name holder contact information”277 required before 29 February 2020.278

273 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 72. 274 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 75. 275 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 75-76. 276 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 76. 277 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 76. 278 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 76. ______Matthias Markus Hudobnik 60 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

4.2.2 Conclusion The EPDP Final Report on the Temporary Specification for gTLD Registration Data dated 20 February 2019 is the Phase 1 of the EPDP-charter, established by the GNSO, which summarizes and modifies several significant policy provisions (e. g., data processing purpose, data elements for collection, transfer, retention and redaction) out of the 29 total recommendations. The final report sets out new arrangements to be compliant with the GDPR, especially, in the Temp Spec but also with other relevant policy documents and procedures (e. g., 2013 RAA, RA). On 04 March 2019, the GNSO approved the final report, which is now open for public comments from the members of the ICANN community until 17 April 2019. After the public comment period, the ICANN Board must decide whether or not to adopt the report as an ICANN Consensus Policy and implement it before 25 May 2019.279 The author analyzes only the most important of a multitude of recommendations. Firstly, Recommendation 1 is linked to Recommendation 20, which defines the respective purpose description for every processing activity in a very accurate manner, and connects them with the relevant lawful bases of the responsible parties for the gTLD registration data, which is the basis for the whole collection and transfer process of the personal data. In short, there are seven defined purposes but it is debatable whether the second purpose - “contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission through enabling responses to lawful data disclosure requests”280 - is adequate for the collecting and processing of personal data in the context of WHOIS?281 From a legal point of view, this seems to be more of a processing activity than a purpose as such. Furthermore, this ‘purpose’ might not be in line with the principle of data minimization. The precise articulation of the second purpose is also very general, and it is possible to subsume nearly every meaning under it. In short, it is crucial to distinguish between a purpose and a particular processing activity.282 Moreover, Article 6 (1) lit. f) GDPR stipulates that “processing is necessary for the purposes of the legitimate interests pursued by a third party.”283 Therefore, third parties with a legitimate interest can, in any case, lawfully access or disclose (redacted) personal data. The result of the final report shows that the business caucus, together with the governments, won this battle of purposes against the non- commercial group, and that is the reason why this purpose was determined.284 Secondly, Recommendation 5 defines the data elements that are required to be collected by registrars, which confirms the final results of the litigation further examined in Chapter 5. This

279 Cf ICANN, ‘GNSO Council Adopts EPDP Final Report on the Temporary Specification for gTLD Registration Data’, 04 March 2019, available at accessed 30 April 2019. 280 See ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 5. 281 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) 5. 282 Cf European Commission, ‘Comments on the Temporary Specification for gTLD Registration Data Policy Recommendations’, 17 April 2019, pp. 1- 5, available at accessed 30 April 2019. 283 See Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 284 Cf Milton Mueller, ‘Whois Reform, at Last’, 05 March 2019, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 61 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______recommendation ensures registration data consistency, and reflects the change of data collection for numerous data field’s (e. g., registrant fields and tech fields) which will no longer be required and only optionally collected, with the consent of the data subject. Thirdly, Recommendation 10 covers the redaction of personal data fields but only to a minimum level; namely the most sensitive data fields have been redacted, including the tech fields (e. g., name, phone, e-mail) which is again in line with the outcome of the litigation. Fourthly, Recommendation 12, Recommendation 16, and Recommendation 17 are still subjects of Phase 2 and not definitely regulated. It is the view of the author that these three recommendations have much in common; explicitly, the legal scope of discretion of registrars in the event of a breach of the GDPR.285 In short, Recommendation 12 proposes that the registrar is only allowed to publish personal data with the consent of the registrant, otherwise the registrar must either redact the organization data field or delete the (already stored) personal information. In either case they must implement an opt-in procedure for the registrant to disclose this particular data element if intended.286 According to Recommendation 16, it is admissible for registries and registrars to differentiate between the respective registrants geographically. This condition may result in legal issues for registrars as data controllers and/or processors, because such personal data may be published somewhere, and the respective publisher will, consequently, be subject to the GDPR. For this reason, there are some communities (further emphasized in Chapter 4.1.2.1) in favor of a unified global standard to solve this issue. The same applies to Recommendation 17, where the registrant is admitted to differentiate among legal entities (e. g., legal and natural persons) but is not forced to do so. Firstly, from a legal point of view, the legal person may in some constellations be associated with the natural person, mainly when there is a strong relation to the natural person (e. g., if they hold shares of the legal entity). Secondly, from a factual point of view, it might be an issue - especially for smaller entities (e. g., registries and registrars) - to distinguish these legal details in the context of legal v. natural persons and organizational v. personal information, because they do not have a team of legal experts within their organizational structures. This circumstance results in uncertainty regarding this current provision and that is a reason why it is still in progress and part of Phase 2. Recommendation 17 suggests a study, and further consultation of ICANN organization with the Internet community, to develop a satisfactory solution. Meanwhile, a similar opt-in procedure for the registrant as in Recommendation 16 would have been privacy-friendly, namely to only disclose personal data of the registrant with the consent of the particular data subject.287

285 Cf ibid. 286 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 14-15. 287 Cf ICANN, ‘Final Report of the Temp Spec for gTLD Registration Data EPDP’ (n 250) pp. 17-18. Cf ICANN, 'The Cookbook' (n 16) pp. 22-23. Cf Mueller, ‘Whois Reform, at Last’ (n 284). ______Matthias Markus Hudobnik 62 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Chapter 4.1.2.2 further discusses whether legal entities should be addressed as natural or legal persons. Phase 2 of the EPDP-charter includes a set of issues and an ICANN Implementation Review Team (IRT), which is instructed to develop operational and contractual specifications for the policy implementation process. Taking this into account, the contracted parties need to decide whether to follow the Temp Spec or the new ICANN Consensus Policy, between the expiration date of the Temp Spec and the final policy document of the IRT. These matters include: a system for standardized access to non-public registration data, technical standards for access to non-public registration data, the territorial applicability of the GDPR in non-EU areas, legal entities as legal v. natural persons and credentials for access and terms of access e. g., certification v. accreditation.288 The results of the investigation show that there is an urgent need to develop access agreements to non-public registration data as well as develop technical standards for access to non-public registration data.289 Recommendations 5, 7, 8 and 10 prove that the second hypothesis - namely that ICANN v. EPAG has potentially influenced the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec), especially in the context of Admin-C and Tech-C data - is correct. In short, almost all tech fields are optional to collect (e. g., this applies for the collected data of the registrars, the transfer of data elements from registrars to registries, transfer registrars/registries to the data escrow agent or redacted in the public RDDS) as was argued by the defendant in the litigation ICANN v. EPAG. The third hypothesis, which states that there is a necessity for a system of standardized access to non-public registration data, adjusted with the technical implementation process, which is also lawful under specific data protection laws, cannot be finally proven because this matter is part of Phase 2 of the EPDP on the Temp Spec. However, as described above it can be concluded that ICANN established a so-called ‘Technical Study Group on Access to Non- Public Registration Data’ which may work together with the EPDP team to find an appropriate solution to this issue. A comprehensive analysis of the non-public WHOIS regime categorized into a (self)-certification approach, accreditation approach, and legal due process approach is further explained in Chapter 4.1.4.1. An outlook on future issues is further discussed in the general conclusion in Chapter 6 .

288 Cf Olivier Crepin-Leblond, Kurt Pritz and Keith Drazek, ‘ICANN, the GDPR and WHOIS’, Notes of Nigel Hickson, WSIS Forum, 11 April 2019, available at accessed 30 April 2019. 289 Cf ibid. ______Matthias Markus Hudobnik 63 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

5 Case, ICANN v. EPAG Domainservices GmbH This chapter emphasizes the first litigation since the GDPR came into force on 25 May 2018.290 The case proves the hypothesis in the respective conclusion of the subchapter, but also in the general conclusion, namely that the litigation ICANN v. EPAG has potentially influenced the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec), especially, in the context of Admin-C and Tech-C data. This chapter compares and analytically assesses the arguments of the court claims of the respective parties (e. g., ICANN as the applicant and EPAG, an ICANN-accredited registrar, as the defendant) and analyzes them in their different litigation stages of the involved German courts (e. g., Regional Court of Bonn and Higher Regional Court of Cologne). ICANN’s initial intention was to file a claim against EPAG to get further insights from the courts regarding the interpretation of the GDPR. In order to defend the personal data collection practices of registrants in the WHOIS databases to a maximum extent possible, but still being compliant under the GDPR. ICANN’s main aim was to guarantee the current data collection practices of the involved parties and retain GDPR compliant access to the data in the WHOIS databases for parties, which can prove that they have a legitimate purpose. EPAG as a future defendant in the trail clearly stated that they would no longer collect personal data – in other words, administrative and technical contact information via a new domain name registration process even if they are contractually obligated by ICANN through the 2013 RAA to do so. As an ICANN- accredited registrar, EPAG was convinced that particular provisions – in 2013 RAA replaced by the Temp Spec – to collect the administrative and technical contact information might not be compliant with the GDPR any longer.291 ICANN approved Temp Spec, which allowed ICANN and the gTLD registry operators and registrars to continue their current work under temporary rules to fulfill the existing ICANN agreements and community-developed policies in light of the GDPR. The detailed analyses of the various litigation stages of the involved German courts are further discussed in the relevant subcategories below.292

5.1 ICANN’s Motion for the Issuance of a Preliminary Injunction On 25 May 2018, ICANN hereinafter ‘applicant’ ordered by way of a preliminary injunction EPAG hereinafter ‘defendant’ located in Germany to “cease and desist, as an ICANN accredited registrar with regard to any generic Top-Level Domain”293 shown on a listing of the Top-Level Domains for which EPAG serves as a registrar, “from offering and/or registering second level domain names without collecting the following data of the registrant that registers that second level domain name through the defendant: The name, postal address, e-

290 Cf ICANN, ‘ICANN v. EPAG Domainservices, GmbH’, 25 May 2018, available at accessed 30 April 2019. 291 Cf ICANN, ‘ICANN Files Legal Action in Germany to Preserve WHOIS Data’, 25 May 2018, available at accessed 30 April 2019. 292 Cf ICANN, ‘ICANN Board Approves Temporary Specification’ (n 239). 293 See Jakob Guhn, ‘Motion for the issuance of a preliminary injunction’, JONES DAY Rechtsanwälte, 25 May 2018, pp. 1-2, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 64 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______mail address, voice telephone number, and (where available) fax number of the technical contact for the registered second level domain names; and/or the name, postal address, e- mail address, voice telephone number, and (where available fax number of the administrative contact for the registered second level domain name.”294 The applicant stipulates that the defendant is contractually bound to the applicant via the on 22 January 2014 signed 2013 RAA and, therefore, accredited by ICANN to act as such a registrar. The applicant points out that under Section 3.4 2013 RAA, the defendant is obligated to maintain the respective data in an electronic database securely and this provision is connected to the Subsection 3.3.1.1 to 3.3.1.8 2013 RAA as follows:295 “3.4.1 For each registered name sponsored by registrar within a gTLD, registrar shall collect and securely maintain, in its own electronic database, as updated from time to time: [...] 3.4.1.2 The data elements listed in Subsections 3.3.1.1 to 3.3.1.8”296; The Subsections 3.3.1.1 to 3.3.1.8 refer to the following personal data collection and/or processing of the registered names: “3.3.1.1 The name of the registered name; 3.3.1.2 The names of the primary name server and secondary name server(s) for the registered name; 3.3.1.3 The identity of registrar (which may be provided through registrar’s website); 3.3.1.4 The original creation date of the registration; 3.3.1.5 The expiration date of the registration; 3.3.1.6 The name and postal address of the registered name holder; 3.3.1.7 The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the registered name; and 3.3.1.8 The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the registered name.”297 As was pointed out in the introduction, ICANN approved Temp Spec, which allow ICANN and the gTLD registry operators and registrars to continue their current work under temporary rules to fulfill the existing ICANN agreements and community-developed policies in light of the GDPR.298 The Temp Spec came into force on 25 May 2018 and still forces registry operators and registrars to collect all personal registration data of the domain name registrants and all registrars are contractually bound by Section 4 2013 RAA. Section 4.4 Temp Spec defines under which purposes processing and collecting of personal data is legitimate. Section 4.4.1 Temp Spec determines the rights of a registered name holder, their potential practice while respecting the registered domain name, and299 “providing access to accurate, reliable, and

294 See ibid. 295 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 3. 296 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) pp. 3-4. 297 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 4. 298 Cf ICANN, ‘ICANN Board Approves Temporary Specification’ (n 239). 299 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 14. ______Matthias Markus Hudobnik 65 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______uniform registration data based on legitimate interests who are not outweighed by the fundamental rights of the respective data subjects.”300 According to the preliminary injunction of the applicant is fundamentally to mention that Section 4.4.7 Temp Spec has determined that “the publication of technical and administrative points of contact administering the domain names at the request of the registered name holder”301 should be facilitated, which is in line with the argument of the applicant to urge the defendant to fulfill the contractual obligations by still performing the data processing and collection. The Temp Spec supports the applicants view, namely that the proportionality of the data processing and collection of technical and administrative contacts are dealt and in line with Section 4.5 of the Temp Spec as well as Section 7.1 Temp Spec, which replaced Section 3.7.7.4 of the 2013 RAA. In contrast, the defendant insists on the legal position that the collection of Tech-C and Admin-C is violating the GDPR and will, therefore, not collect these data – as particularly illustrated above - sets any longer.302 The applicant articulates that the “contractual claim against the defendant to process the data as agreed in Section 3.3.1.1 to 3.3.1.8 2013 RAA, including the data with regard to the Tech-C, Section 3.3.1.7 2013 RAA and the Admin-C, Section 3.3.1.8 2013 RAA”303 has an additional cause of action regarding the secure maintaining of the personal data according to Section 3.4.1.2 2013 RAA. Also, the applicant clarifies in their preliminary injunction that the applicability of the GDPR “does not change the contractual obligations of the defendant – it is still obliged to collect and to keep the data under Article 6 (1) lit. a) and/or f) GDPR”304 and demonstrates the reasons for the collection of Tech-C and Admin-C data as the following:305 Firstly, the applicant stipulates in the preliminary injunction that the defendant “tries to justify non-collection”306 of Tech-C and Admin-C data regardless of effective observation of whether the respective data field is linked to personal data or not. Secondly, the applicant refers to various legal grounds of Article 6 GDPR (further details are comprehensively analyzed in Chapter 3.1.4) and alleges that if the Tech-C and Admin-C are linked to personal data, the collection may be legitimate via the legal bases of consent of the data subject under Article 6 (1) lit. a) GDPR. Additionally, the applicant illustrates that the 2013 RAA, including the Temp Spec e. g., Section 7.2, do not oppose a consent request of the data subject to lawfully process their data and that there is neither a violation nor voidness according to Article 7 (4) GDPR.307 Moreover, the applicant adds that “the performance of the domain name registration is not conditional on the provision of consent”308 and that there is no requirement that personal data

300 See ICANN Board of Directors, ‘Section 4.4.1 of the Temporary Specification for gTLD Registration Data’, 17 May 2018, pp. 7-8, available at accessed 30 April 2019. 301 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 14. 302 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) pp.14-15. 303 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 17. 304 See ibid. 305 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 17. 306 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 17. 307 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) pp. 17-18. 308 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 18. ______Matthias Markus Hudobnik 66 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______must be used to identify the Tech-C and/or Admin-C neither in the 2013 RAA nor in the Temp Spec. The applicant also fundamentally concludes that a domain name registration might also be completed without passing any further personal data by the registrant to the registrar or registry operator. Finally, the applicant highlights that where the customer determines the person to operate as Admin-C or Tech-C, who does not provide the consent for the position of the Admin-C or Tech-C, the responsibility will remain with the registrant. Under Article 6 (1) lit. b) GDPR, the applicant acknowledges that the collection may be legitimate via the legal bases necessary for the performance of a contract which is fulfilled in this particular situation. Also, under this legal basis, the applicant emphasizes once more on the importance of the collection of Admin-C and Tech-C data in terms of the representation of tasks through the domain name registration and that there is no way through the non-collection because it is required under the contract.309 Furthermore, the applicant subsumes the facts of the case under Article 6 (1) lit. f) GDPR that the “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”310 and, therefore, advocates that it is even in the public interest to preserve the defendant’s collected data of Admin-C and Tech- C.311 The applicant claims that “these functions are an essential part of the domain name system making sure that also large companies and natural persons without having a technical background are in the position to name an individual, through name or title, or a professional service provider, as such contact”312 and notes that it is not stipulated to use personal data of a natural person.313 Lastly, the applicant insists in the preliminary injunction that the purpose of the collection is pointed out in Section 4.1 to 4.3 Temp Spec and is legitimate due to the ICANN bylaws which “clearly set out why the interests of the public outweigh any interest of the data subject when processing Tech-C or Admin-C details.”314 As a result, there is no doubt that the balancing test between the data controller and the data subject predominates towards the interests of the particular data subject, as concluded in the preliminary injunction of the applicant. For this reason, the applicant proposed an injunctive relief to prevent irreparable harm because of the non-compliance procedure of the defendant, the further loss of these data sets and the resulting uncertainty of the WHOIS system as further articulated in the preliminary injunction. The implementation of the Temp Spec is precisely the reason to prevent this potential uncertainty within the WHOIS system.315 The applicant further states that the defendant “must enable contact with the Admin-C and Tech-C via an e-mail address or web form, which must

309 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) pp. 18-19. 310 See Article 6 (1) lit. f) of the Regulation (EU) 2016/679 (n 6) 36. 311 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 19. 312 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 19. 313 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 19. 314 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) 20. 315 Cf Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) pp. 21. ______Matthias Markus Hudobnik 67 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______not identify the contact e-mail address or the contact itself.”316 As a result, “the defendant is under no obligation to publicly disclose the Admin-C and Tech-C data”317 in general as finally emphasized in the preliminary injunction of the applicant.

5.1.1 EPAG’s protective letter Firstly, the defendant demonstrates in their protective letter that they would no longer collect personal data e. g., Admin-C and Tech-C data via a new domain name registration process because these data elements are not required. The defendant further states in the protective letter that the data of the domain holder permits an explicit allocation of a domain name to the holder as well as a contact to the domain holder if required. The applicant considers that the legal task can be effortlessly fulfilled without a further collection of Admin-C and Tech-C data and that there is no danger for the security and stability of the domain name system as a whole in acting as such. Additionally, the defendant advocates that if a further collection of data fields is required, then this is disputed and must be explicitly proven in connection with the enforcement of claims under trademark law as well as criminal prosecution.318 It is essential to mention that in the majority of the domain registrations, the customer data is identical with the domain holder. The Admin-C and Tech-C data which substantiated the defendant with data of “10 million registered domain names of the registrar Domains lnc, an ICANN-accredited registrar belonging to the Tucows group like the defendant”319 where they illustrated that “in significantly more than half of all registered domains the e-mail address of the domain holder is identical to that of Admin-C and Tech-C.”320 The defendant also outlines in the protective letter that “in more than three-quarters of all cases, all information for the first name, last name, organization, address, and e-mail is completely identical between owner and Admin-C”321 this strongly supports the argument of the defendant not further collect any Admin-C and Tech-C data elements. The defendant’s protective letter further states that in the event of technical and/or administrative queries, the defendant contacts the domain holder or the holder of the customer account if necessary but there is no Admin-C or Tech-C in this procedure explicitly required. Therefore, no collection of this particular data fields compulsory for the domain name registration process as such. Lastly, the defendant denies the general disadvantage argued by the applicant through the less collection or non-collection of the Admin-C or Tech-C data sets and clarifies that there is even the possibility to collect such data elements if it is particularly obligated to do so at a later date. Secondly, the defendant refers to Section 3.7.2 of the 2013 RAA and warns that the applicant cannot force the defendant to act unlawfully against this respective provision where the registrar is required not to act against applicable laws and state regulations. Consequently, to

316 See Guhn, ‘Motion for the issuance of a preliminary injunction’ (n 293) pp. 21. 317 See ibid. 318 Cf Thomas Rickert, ‘EPAG Protective Letter’, Rickert Rechtsanwaltsgesellschaft mbH, 28 May 2018, 5, available at accessed 30 April 2019. 319 See Rickert, ‘EPAG Protective Letter’ (n 318) 6. 320 See ibid. 321 See Rickert, ‘EPAG Protective Letter’ (n 318) 6. ______Matthias Markus Hudobnik 68 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______that observation, the defendant asserts that the GDPR is applicable for the defendant because EPAG is based in Germany as the processing takes place within the EU according to Article 3 (1) GDPR, and more importantly they process personal data under Article 2 (1) GDPR. Following Article 5 (1) lit c) GDPR the principle of data minimization must be fulfilled as well as processing which is relevant, adequate, and limited to the necessary purpose. Moreover, the defendant argues in the protective letter that under Article 25 GDPR the principle of ‘privacy by the design’ and ‘privacy by default’ are violated via the applicant’s obligations. It is generally to acknowledge that the provisions of personal data (e. g., address, telephone number, fax number, and e-mail address) processing are relevant through a domain name registration regardless of the status of the legal entity as a natural or legal person. If the domain holder is a legal person, the GDPR may underlie because the name can include or refer to personal data. As the defendant also conveys in the protective letter that this is only not the case if data elements (e. g., address, telephone number, fax number, and e-mail address) are not allocated to a natural person. The defendant is in favor of a non-collection of Admin-C and Tech-C data because neither for the registration process of a domain name nor for the transfer or renewal of a domain name as well as for potential domain disputes or abuses or technical issues only registrant’s contact information’s are necessary. The defendant underpins this argument in the protective letter, namely that this is in line with the principle of data minimization as well as that all the above noted contractual obligations and purposes are feasible via various ways (e. g., the address, telephone or e-mail) by only using the data elements of the registrant. The only exception in connection with a data collection may be unavoidable in terms of gTLDs with eligibility or nexus requirements e. g., dot law, where supplementary specifications need to be fulfilled but, interestingly, such a differentiation is not concluded by the applicant in the contractual agreements as such. In contrast to that observation, the applicant is contractual, forcing the defendant to collect all possible personal registration data elements without further legitimation. The defendant further points out that there is no statement regarding the collection of this particular data neither in the Temp Spec nor the 2013 RAA.322 The defendant also refers in the protective letter to the letter of the WP29 to ICANN dated 22 June 2006 complaining the (same) WHOIS problematics as above described by the defendant and that the applicant is not willing to modify the WHOIS system since many years.323 The same observation is rendered by the International Working Group on Data Protection in Telecommunications (IWGDPT so-called ‘Berlin Group’) cited in the protective letter of the defendant. They stated that “there are several concerns about the registration data for domains or names.“324 Especially, that “the requirements defined in 2013 RAA for the collection of data from registrants appear excessive and disproportionate and appear to occur

322 Cf Rickert, ‘EPAG Protective Letter’ (n 318) pp. 6-8. 323 Cf WP29, ‘Letter from Peter Schaar to Vinton G. Cerf regarding WHOIS’ (n 216) pp. 1-2. Cf also Rickert, ‘EPAG Protective Letter’ (n 318) 8. 324 See International Working Group on Data Protection in Telecommunications, ‘Working Paper on Privacy and Data Protection Issues with Regard to Registrant data and the WHOIS Directory at ICANN’, 27-28 November 2017, 4, available at accessed 30 April 2019. See also Rickert, ‘EPAG Protective Letter’ (n 318) 9. ______Matthias Markus Hudobnik 69 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______without the voluntary consent of the persons concerned”325 which is also in line with the arguments of the defendant. The IWGDPT assessed that “various data processing activities required by the 2013 RAA do not correspond to the original purpose of the gTLD guideline adopted by ICANN in 2006.”326 Additionally, the IWGDPT recommended in the context of the principle of data minimization that “personal data collected from and about registrants must be limited to those data necessary for the purposes described in recommendation No. 1 of this Working Paper.”327 As a final point, the defendant refers to the legal basis of Article 6 (1) GDPR and notes that it should be based between registrars and domain name holders, but this may also be third- party interests following Art. 6 (1) lit. f) GDPR.328 The defendant further advocates that “there is already no verifiable explanation in 2013 RAA or the Temp Spec as to why ICANN either has its own interests or third party interests that are so important that they always outweigh the interests of the party concerned and ICANN should, therefore, be entitled to demand and enforce the collection of this data by contract without further ado.”329 Lastly, the defendant portrays that “the [applicant] relies on the alleged use of different contact data for combating abuse”330 but does not report that “the WHOIS is targeted in bulk and systematically with spam and phishing e-mails, read and used for purposes that do not correspond to the purpose of the WHOIS database.”331 The defendant concludes the protective letter with the rejection of the applicant’s preliminary injunction because it is entirely as well as unfounded, and there is no cause as well as no complaint about the interim relief.332

5.2 Court Order from the Regional Court of Bonn on Application for Preliminary Injunction On 29 May 2018, the Regional Court of Bonn from now on ‘court’ denied the application for a preliminary injunction because in its view it was unfounded as well as not substantiated. The court points out that it is factual that there is the formally contractual obligation via the Section 3.4.1 related to 3.3.1.7 to 3.3.1.8 of the 2013 RAA between the applicant and the defendant, which obligates the defendant to further storage and collect Admin-C and Tech-C contact data. This procedure is also in line with the previous domain name registration process and practices of the defendant.333 Nevertheless, the defendant must also fulfill the applicable laws in connection with their services as a registrar and the court advocates that “the [applicant] can only claim loyalty to

325 See ibid. 326 See IWGDPT, ‘Working Paper on Privacy and Data Protection Issues’ (n 324) 4. See also Rickert, ‘EPAG Protective Letter’ (n 318) 9. 327 See IWGDPT, ‘Working Paper on Privacy and Data Protection Issues’ (n 324) 7. See also Rickert, ‘EPAG Protective Letter’ (n 318) 10. 328 Cf Rickert, ‘EPAG Protective Letter’ (n 318) 11. 329 See Rickert, ‘EPAG Protective Letter’ (n 318) 11. 330 See ibid. 331 See Rickert, ‘EPAG Protective Letter’ (n 318) 11. 332 Cf Rickert, ‘EPAG Protective Letter’ (n 318) pp. 11-12. 333 Cf Germany: Regional Court of Bonn (n 68) pp. 4-5. ______Matthias Markus Hudobnik 70 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______the contract from the defendant to the extent that the contractual agreements are following applicable law, § 242 BGB.”334 The chamber of the court refers to Article 5 GDPR and that the storage and collection are only lawful under “specified, explicit and legitimate purposes”335 as stipulated in lit. b) leg cit. Moreover, “adequate, relevant and limited to what is necessary concerning the purposes for which they are processed”336 according to lit. c) leg cit. The chamber claims that “the [applicant] has not demonstrated that the storage of other personal data than that of the domain holder, which continues to be indisputably collected and stored, is indispensable for the purposes of the [applicant].”337 The chamber further states that it is evident that the collection and storage of more data fields result in a more precise identification process of the registered domain name holder who is also the person in charge of the domain name. Nonetheless, the registrant is frequently the same person – as demonstrated in defendant’s protective letter – as the administrative and technical contact and therefore the court states that there is no additional collection and storage of these particular data fields required.338 The court also argues that this assumption is in line with the principle of data minimization and further assesses that the applicant’s principal concern regarding the criminal preventions, security problems of the Internet based on the none-collection, and storage of the administrative and technical contact are unjustified. The chamber does not see the need for a data collection of Admin-C and Tech-C data fields.339 The chamber further states, “according to the concurring argument of both parties in this respect, the same personal data could be used in all three categories, i. e., those of the domain holder himself, the so-called Tech-C as well as the Admin-C, i. e., with corresponding information from a registrant only one data record instead of three, was collected and stored and this also in the past did not lead to the fact that a registration of the domain had to be denied in the absence of data going beyond the domain holder himself.”340 Conversely, the court evaluates the fact that if the additional storage and collection of Admin-C and Tech-C data – as stipulated in the preliminary injunction of the applicant – is indispensable. It is unclear to the court why it was then even possible to act without an additional collection and storage of Tech-C and Admin-C data because this is as well as was the case through the registrants ‘free choice’ at the domain name registration to provide these data elements voluntarily.341 Subsequently, the chamber highlights “this means that the person wishing to register will also be able to voluntarily provide their consent to the collection and storage of corresponding

334 See Germany: Regional Court of Bonn (n 68) 5. Cf § 242 of the Performance in good faith in the Civil Code, Bürgerliches Gesetzbuch (BGB), available at accessed 30 April 2019. 335 See Article 5 (1) lit. b) of the Regulation (EU) 2016/679 (n 6) 35. 336 See Article 5 (1) lit. c) of the Regulation (EU) 2016/679 (n 6) 35. 337 See Germany: Regional Court of Bonn (n 68) 5. 338 Cf Germany: Regional Court of Bonn (n 68) 5. 339 Cf ibid. 340 See Germany: Regional Court of Bonn (n 68) 5. 341 Cf Germany: Regional Court of Bonn (n 68) pp. 5-6. ______Matthias Markus Hudobnik 71 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______personal data in the future under Article 6 (1) lit. a) GDPR and Section 7.2.2 of the 2013 RAA - but he was not forced to do so even before.”342 Finally, the court references to the protective letter of the defendant and additionally states that the proof details of the defendant’s illustrated number of registrants who have not stored and collected different contact details do not even have any implications at all.343

5.3 ICANN’s Immediate Appeal The applicant’s legal assessment in the immediate appeal dated 13 June 2018 is based on the following two arguments: Firstly, the defendant can fulfill the contractual requirements through the collection of administrative and technical contact data and is even not obligated to collect them as a personal data set. Secondly, the collection of personal data of a natural person is feasible as it is required under the contractual obligations between the applicant and the defendant.344

5.3.1 Lawfully collection of Admin-C and Tech-C data as well as lack of obligation to collect personal data The applicant points out that the collection of Admin-C and Tech-C data is lawfully as well as that there is the contractual obligation under the 2013 RAA and the Temp Spec to collect personal data of natural person’s e. g., Admin-C and Tech-C data. According to (14) GDPR, only the processing of personal data in connection with natural persons is obligated. The applicant further claims in the immediate appeal that ”the application for a preliminary injunction is not directed at the collection of personal data, but rather the collection of Admin-C and Tech-C data.”345 In the view of the defendant generally, no collection of Admin-C and Tech-C data is performed neither if it is personal data or not nor a differentiation is done if the data subject is a legal or natural person. Nevertheless, the chamber rejected the injunctive relief of the applicant due to the conflict of the data collection (e. g., Admin-C and Tech-C) with the GDPR as a whole, and therefore the applicant made an alternative application for relief.346 The alternative application for relief of the applicant states the following: “only if the consent of the Admin-C and Tech-C for the collection of this data has been obtained for the purpose of enabling contact for administrative and technical matters or if no personal data of a natural person is concerned in the first place.”347 The applicant further conducts that regardless of the interpretation method of the GDPR, the chamber of the court must accept this limitation as well as an alternative application for relief.348 The final argument in the alternative application of the applicant is that “even after the strictest reading of the GDPR imaginable, it can and must be lawful to provide your contact

342 See Germany: Regional Court of Bonn (n 68) 6. 343 Cf Germany: Regional Court of Bonn (n 68) 6. 344 Cf Jakob Guhn, ‘Immediate Appeal’, JONES DAY Rechtsanwälte, 13 June 2018, 18, available at accessed 30 April 2019. 345 See Guhn, ‘Immediate Appeal’ (n 344) 18. 346 Cf Guhn, ‘Immediate Appeal’ (n 344) pp. 18-19. 347 See Guhn, ‘Immediate Appeal’ (n 344) 32. 348 Cf Guhn, ‘Immediate Appeal’ (n 344) 32. ______Matthias Markus Hudobnik 72 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______details voluntarily and with your consent because you want to act for the (legitimate) purpose of providing services for the registrant.”349 Consequentially, under this purpose, the collection of the particular data elements mentioned above is necessary and a distinct procedure to efficiently manage the contact. Additionally, it supports the identification process of the Admin- C and Tech-C, who might be reliable in the case of a domain name violation and may provide the injured party with useful information. The injured party may have a legitimate interest in investigating the domain name violation.350

5.3.2 Lawfully collection of Admin-C and Tech-C data even if it is personal data In the applicant’s view, the collection of Admin-C and Tech-C data of natural persons is lawful for the reason that the binding obligations are fulfilled under the GDPR. As these obligations are the following: Article 5 (1) lit. b) GDPR, Article 5 (1) lit. c) GDPR as well as Article 5 (1) lit. a) GDPR and Article 6 GDPR.351 Firstly, the applicant highlights in the immediate appeal that in the decision of the Regional Court of Bonn on the application for preliminary injunction “the chamber has neither correctly understood the legitimate purpose of data collection for the Admin-C and Tech-C, nor has it examined the principle of data minimization in relation to this actual purpose.”352 The applicant further refers to the purposes of Section 4.4.5, 4.4.6 (e. g., to fulfill the established communication) and 4.4.7 (e. g., management of domain names via a request of the domain name holder). As well as the Section 4.4.8 (e. g., consumer protection, investigation of cybercrime) and 4.4.9 (e. g., law enforcement requirements) of the Temp Spec and examines again that these purposes are specified, explicit and legitimate according to Article 5 (1) lit. b) GDPR. In other words, the registrant may delegate the task to a third person where the information of the Admin-C and Tech-C is necessary to perform the task as well as for law enforcement and trademark purposes to determine the registrant or if the activity is delegated to a third person. Further details regarding the applicant’s submission for the preliminary injunction discussed in Chapter 5.1 and the purpose limitations under Article 5 GDPR in Chapter 4.1.3.353 Secondly, the applicant once again assesses that the processing is adequate and limited to what is necessary under Article 5 (1) lit c) GDPR. The applicant claims that the court fails to “recognize the specified and explicit purposes in its decision and does not strike the right balance between the question of the need to collect the data and legitimate purposes.”354 According to the decision mentioned above, the chamber’s view is that the data collection is not essential for preventing domain name security difficulties, which is against the applicant’s view. The applicant argues that the court’s conclusion is incorrect and denies that the collection does not prevent the security of the domain name system and refers to the

349 See Guhn, ‘Immediate Appeal’ (n 344) 32. 350 Cf Guhn, ‘Immediate Appeal’ (n 344) 32. 351 Cf Guhn, ‘Immediate Appeal’ (n 344) 19. 352 See Guhn, ‘Immediate Appeal’ (n 344) 19. 353 Cf Guhn, ‘Immediate Appeal’ (n 344) pp. 19-21. 354 See Guhn, ‘Immediate Appeal’ (n 344) 22. ______Matthias Markus Hudobnik 73 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______arguments in the preliminary injunction (further details explained in Chapter 5.1). Moreover, the applicant supports their argument with the fact that “the data collection is necessary to enable the registrant to name additional technical and administrative contact points for the administration of the domain name.”355 Also, encourages this argument by referencing to the example of the defendant and that there are nearly 50 percent of the 10 million registered domain names with a third person as Admin-C or Tech-C - for various reasons e. g., UDRP or trademark issues - and not the domain holder as such which indicates the significance to collect this data sets. Finally, the applicant highlights that the guidance of the WP29 is purely focusing on the publication of WHOIS data as well as on ICANN’s implementation of the Temp Spec and their compliance with the GDPR. Rather than directing to the storage and collection of the administrative and technical contact data fields. Subsequently, the applicant summarizes that the data is relevant for the purpose by the proportionality test because the data collection of the Admin-C and Tech-C information is suitable to accomplish the legitimate objective, namely the possible contact to the third person who might potentially be assigned with the tasks of the registrant. Also, is the collected data limited to what is necessary as the applicant illustrated in the immediate appeal through the argument that only data elements for the identification purposes of the Admin-C or Tech-C are collected and only for entities with a legitimate interest in the identification process e. g., trademark owners or law enforcement agencies. Consequently, no data fields are collected without a relation to the legitimate purpose and those are limited to what is necessary - in contrast to the legal view of the court - to be compliant with Article 5 (1) lit. c) GDPR.356 Further details regarding the applicant’s submission for the preliminary injunction is explained in Chapter 5.1, and the purpose limitations under Article 5 GDPR are explained in Chapter 3.1.3. Thirdly, the processing is lawfully under Article 5 (1) lit. a) GDPR in relation to Article 6 GDPR. The applicant is against - as already stated in the preliminary injunction - the view of the chamber and supports their legal point of view in the immediate appeal by reciting (40) of the GDPR. It stipulates that “in order for processing to be lawful, personal data should be processed based on the consent of the data subject concerned or some other legitimate basis, laid down by law.”357 The practices in the present case are in line with the GDPR as the applicant highlighted that the processing of the Admin-C and Tech-C data is only completed with the consent of the data subject under Article 6 (1) lit. a) GDPR as well as the performance of a contract according to Article 6 (1) lit. b) GDPR and the legitimate interest under Article 6 (1) lit. f) GDPR. According to Article 6 (1) lit. a) GDPR the data is only processed if the consent of the registrant is available; the same procedure applies to third parties, where the consent of the third party is necessary. Moreover, the applicant concludes that there is also consent for the publication in the WHOIS

355 Cf Guhn, ‘Immediate Appeal’ (n 344) 22. 356 Cf Guhn, ‘Immediate Appeal’ (n 344) pp. 23-24. 357 See (40) of the Regulation (EU) 2016/679 (n 6) 23. Cf Guhn, ‘Immediate Appeal’ (n 344) 24. ______Matthias Markus Hudobnik 74 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______database needed to publish the particular data elements, which is also in line with Section 7.2.2 of the Temp Spec where an additional consent request for the publication is intended. As a result, the applicant evaluates that the defendant is, in any case, able to fulfill their contractual obligations lawfully, namely to further collect administrative and technical contact data via seeking the consent of the registrant as a data subject which is in line with the GDPR. The applicant mentions the performance of a contract - where the data subject is a party of the agreement - under Article 6 (1) lit. b) GDPR as another possible option.358 The applicant clarifies that “fulfillment of a contract makes it clear that the applicability of Art. 6 (1) lit. b) GDPR does not depend on the contractual partner of the data subject and the person responsible for processing the data being identical.”359 This view of the applicant is also in line with (44) GDPR which stipulates that “processing should be lawful where it is necessary for the context of a contract or the intention to enter into a contract.”360 Further details regarding the applicant’s submission for the preliminary injunction explained in Chapter 5.1 and the purpose limitations of Article 5 GDPR in Chapter 3.1.3 in connection with the legal grounds of Article 6 GDPR in Chapter 3.1.4. Additionally, the applicant points out that the legal ground of legitimate interests, according to Article 6 (1) lit. f) GDPR permits the data processing of Admin-C and Tech-C data elements because it is in the interest of e. g., controllers, and third parties.361 The applicant advocates in the immediate appeal that “the legitimate interest of the controllers and third parties in the processing of personal data of a natural person, if provided, outweighs that of the Admin-C or Tech-C”362 and moreover addresses the term ‘legitimate interests’ as well as ‘reasonable expectations’ by referencing to (47) GDPR (further details discussed in Chapter 3.1.4). On the following arguments is the applicant conceptualizing the controllers and respective third parties legitimate interests: Firstly, the applicant highlights that the legitimate interest of data processing is in line with ICANN’s core mission, their bylaws as well as Section 4.4.8 and 4.4.9 of the Temp Spec (further details in relation to the Temp Spec explained in Chapter 4.2). The applicant also refers to the explanations in the immediate appeal where the significance of the collection and storage of the administrative and technical contact data is already comprehensively illustrated (further details explained in Chapter 5.2). Secondly, the applicant evaluates that the Admin-C and Tech-C are supporting the registrant and third parties in the event of frauds, spam, and other abusive online attacks. These data fields will prevent them from delays, especially if the domain holder is a company or a natural person without the appropriate skill set to solve these online exploitations promptly. Moreover, the applicant underpins that in the view of the court this will mean that only the domain holder itself will be contacted and will be required to solve these issues without a delay, guidance,

358 Cf Guhn, ‘Immediate Appeal’ (n 344) pp. 24-26. 359 See Guhn, ‘Immediate Appeal’ (n 344) 26. 360 See (44) of the Regulation (EU) 2016/679 (n 6) 25. 361 Cf Guhn, ‘Immediate Appeal’ (n 344) 27. 362 See Guhn, ‘Immediate Appeal’ (n 344) 28. ______Matthias Markus Hudobnik 75 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______and expertise of administrative or technical contact. The applicant also analyzes the fact that the administrative and/or technical contacts role might be to act as a bridge between the registrant and registrar e. g., handling the renewal of the domain name or act as a local administrator since the domain name holder might be located somewhere else. Moreover, the applicant points out that legitimate interest is also fulfilled in terms of trademark infringements related to domain names and that the infringed party has the apparent interest to determine the person behind this violation. Therefore, the collection and storage of the additional administrative and technical contact data supports this investigation process immensely and provides the necessary information as to where and how to contact the perpetrator. As a result, the applicant concludes that the collection of Admin-C and Tech-C information generally provides more effectiveness in cybercrime investigations and the delegation of the tasks as mentioned above are compliant with Article 6 (1) lit. f) GDPR.363 Lastly, the applicant characterizes that at the balancing test the legitimate interests of controllers and third parties overweight the fundamental rights and freedoms of the data subjects (e. g., Admin-C, and Tech-C) under Article 7 and Article 8 of the Charta of Fundamental Rights of the European Union.364 For the reasons that a publication of the Admin- C and Tech-C data is only published in the WHOIS database with the respective consent of the data subject as described in the preliminary injunction (further details in Chapter 5.1) as well as under Section 2.4 of the Temp Spec (further details in Chapter 4.2). Subsequently, if this is not possible a web form or an anonymized e-mail address must be maintained under the Temp Spec. Additionally, the applicant portrays that there are reasonable expectations of an Admin-C and Tech-C contact estimated, which are often consolidated by a contractual agreement between the registrant and the registrar. Therefore the data processing can be - under the conditions of (47) GDPR - reasonably expected as well as subsumed via the legitimate interests e. g., fraud detection, network security stipulated in (49) GDPR.365 In conclusion, the applicant justifies the processing of administrative and technical contact data by once again referencing to Section 4.5 of the Temp Spec which ensures for specific measures “the proportionality of data processing concerning the weighing of interests”366 following Article 6 (1) lit. f) GDPR. Taking this into account, the applicant concludes that Article 6 (1) lit. f) GDPR is linked with procedural rules of Article 13 (1) lit. d) GDPR and Article 14 (2) lit. b) GDPR which stipulates that the data subject affected via the ‘legitimate interests’ needs to be informed as well as has a right to object following Article 21 GDPR. For this reason, the applicant determines that a situation where the collection and storage of personal

363 Cf Guhn, ‘Immediate Appeal’ (n 344) pp. 28-29. 364 Cf Article 7 and Article 8 of the Charta of Fundamental Rights of the European Union (2000/C 364/01), 18.12.200, 10, available at accessed 30 April 2019. 365 Cf Guhn, ‘Immediate Appeal’ (n 344) 30. 366 See Guhn, ‘Immediate Appeal’ (n 344) 30. ______Matthias Markus Hudobnik 76 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______administrative and technical contact data are performed without the consent of the data subject is unrealistic.367 At last, the applicant completes that “all these circumstances lead to an appropriate balance between the legitimate interests of third parties and the interests, fundamental rights and freedoms of the Tech-C and Admin-C”368 and claims that the data processing is compliant with Article 6 (1) lit. f) GDPR. At the end of the immediate appeal the applicant insists that “if the chamber or the Senate nevertheless deems further submissions on certain prerequisites of the GDPR necessary, the applicant kindly asks for a corresponding judicial note.”369

5.3.3 EPAG’s Comments on ICANN’s Immediate Appeal In the defendant’s comments on the applicant’s immediate appeal dated 10 July 2018, the defendant at first-hand points out that the proceedings are “the applicant’s inability to assess and adapt its practices to comply with European data protection law.”370 The defendant criticizes the since 2003 from data protection authorities assessed compliance issues of the applicant as well as the intention to change the existing WHOIS system to the minimum extent feasible to be compliant with the GDPR, as stated in the Temp Spec. Additionally, the defendant highlights that “the result is inconsistent, contradictory and ultimately does not comply with applicable law”371 and illustrates that the GDPR is more extensively than a minimal change of the publication of personal data in the WHOIS system as such. The defendant advocates again that with the review process of their data protection policies and the effect of the GDPR they will no longer collect Admin-C and Tech-C data - because it is not necessary and in line with the principle of data minimization - to be compliant with the GDPR.372 Furthermore, the defendant refers to the letter of the EDPB dated 05 July 2018 and notes that the guidance of the EDPB is in line with their view, namely that it is essential to differentiate between the different purposes for data processing and collection of the various involved parties and not lump them together. Moreover, the defendant points out that the applicant has an inconsistent data protection assessment, and the defendant is forced to violate the GDPR when transferring or processing personal data and is incapable of fulfilling the respective agreements. Firstly, the defendant examines that the applicant violates various GDPR principles e. g., the principle of purpose limitation according to Article 5 (1) lit. b) GDPR, as well as the principle of data minimization under Article 5 (1) lit. c) GDPR and the legal basis for the lawfulness of processing, namely necessary for the performance of a contract under Article 6 (1) lit. b) GDPR which is not appropriate. Secondly, the applicant advocates that there are suitable alternative legal basis’s applicable and that the data collection of Admin-C and Tech-C

367 Cf Guhn, ‘Immediate Appeal’ (n 344) 31. 368 See Guhn, ‘Immediate Appeal’ (n 344) 31. 369 See ibid. 370 See Thomas Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’, Rickert Rechtsanwaltsgesellschaft mbH, 10 July 2018, 2, available at accessed 30 April 2019. 371 See ibid. 372 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 3. ______Matthias Markus Hudobnik 77 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______is not necessary for the domain name registration process. Thirdly, the applicant’s submission does no correspond with the liability to inform the data subject about the data collected according to Article 13 and Article 14 GDPR.373 Fourthly, the defendant predicts the complete refusal of the applicant’s alternative claim for the reason that “in substance, it amounts to a reduction of invalid provisions to preserve validity that is neither legally nor contractually permissible.”374 In short, the defendant summarizes in the comments of the applicant’s immediate appeal the violations of the primary processing principles according to Art 5 GDPR in eleven concerns as the following:  Lack of specified purpose  Vagueness  Irrelevance of third party definitions  Applicant considers the further specification of the purpose necessary  No need for data collection for dispute resolution  Delegation of administrative tasks not necessary  No legitimate processing purpose concerning content control  No necessity for availability check  No legitimate purpose due to possible Admin-C liability  No comparability with the role of the representative of a trademark owner  Violation of the principle of data minimization under Article 5 (1) lit. c) GDPR375 For the sake of clarification, the author emphasizes the essential concerns in the context of the diploma thesis topic and their research questions. Starting with the lack of specified purpose, the defendant evaluates that the applicant’s immediate appeal (further details in Chapter 5.3) has not adequately determined the purpose for the processing of the administrative and technical contact data. Furthermore, the reference from Section 4.4.5 to 4.47 Temp Spec is surplus and not necessary because Section 4.4.7 Temp Spec is the only relevant provision referring to the disputed data elements. Mainly focuses on the purpose of publication of administrative and technical contact data as such, which is only allowed with the explicit consent of the data subject. The defendant also highlights that the usage of the administrative and technical contact data is not recognized by the purpose as mentioned above as well as that the referral clauses of the applicant stand only in connection with the direct communication of the registrant. Besides, the defendant notes that the processing purposes of Section 4.4.8 and 4.4.9 Temp Spec are imprecise, as the wording of various terms is too generally formulated (e. g., issues, needs of law enforcement authorities) in the respective sections and subsequently, there is no proper subsuming feasible. Moreover, there is no separation between the purposes of controllers and third parties performed which was

373 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 4-5. Cf also EDPB, ‘Letter from Jelinek to Marby’ (n 69) 2. 374 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 5. 375 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 7-14. ______Matthias Markus Hudobnik 78 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______already criticized by the EDPB (further details at the beginning of this chapter) and results in a lack of determination of the processing purposes.376 Secondly, the collection of Admin-C and Tech-C data is for the delegation of specific administrative tasks if intended by the registrant - contrarily to the view of the applicant - not necessarily and without it, it is also a delegation of specific tasks doable. Therefore, the defendant suggests maintaining an anonymized or generic e-mail address for the registration process linked to the domain name holder for an internal allocation of the respective responsibilities, which will be an appropriate solution. The defendant further warns that the collection of Admin-C and Tech-C data is not an added value - as stipulated by the applicant - for the registrant as well as not precisely specified under the Temp Spec and the 2013 RAA and not in line with the GDPR principle of privacy by design.377 Thirdly, the applicant argues that the availability check of a domain name is conceivable without the further collection of Admin-C and Tech-C data and even without personal data of the registrant. In the context of intellectual property abuses, the right holder might contact the domain holder without necessarily knowing the administrative or technical contact. Fourthly, the defendant recertifies that the applicant’s reference to the decision from the Federal Court of Justice supports the argument that an Admin-C cannot generally be liable as an interferer and even if possible, this is no cause for a collection of administrative and technical contact data. Subsequently, there is no legitimate purpose for the collection of these data elements as such.378 Fifthly, the defendant recognizes that there is a violation of the principle of data minimization as data collection must be “adequate, relevant and limited to what is necessary concerning the purposes for which they are processed”379 under Article 5 (1) lit. c) GDPR, which is not the case in the current dispute. The defendant evaluates once again that neither for the registration of a domain name nor the delegation of tasks (e. g., transfer, renewal, domain breaches or prevention) to third parties is the collection of Admin-C and Tech-C data necessary. Also, the defendant’s illustrated figures in the protective letter indicate that the further collection is not requisite as well as the applicant’s answer underscores the non- collection of the data elements as mentioned above. The reason for that is that for the roughly 5 million out of 10 million without the collection of the additional data elements the domain name system functions (e. g., registration, transfer, renewal) similarly.380 The defendant points out that this argumentation is in line with the decision of the Regional Court of Bonn381 which stipulates that the domain name registration data e. g., the data of the domain holder and the data of the administrative and technical contact does not necessarily differ from each other. Therefore the extraordinary collection of the administrative and

376 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 7-8. 377 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 10. 378 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 11. Cf also Germany: Federal Court of Justice (Bundesgerichtshof BGH), I ZR 150/09, 09 November 2011, 24, available at accessed 30 April 2019. 379 See Article 5 (1) lit. c) of the Regulation (EU) 2016/679 (n 6) 35. 380 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 12. 381 Cf Germany: Regional Court of Bonn (n 68) 5. ______Matthias Markus Hudobnik 79 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______technical contact data is for a significant number of registrants exuberant. Besides, the applicant’s purposes for the data collection (e. g., consumer protection, online fraud investigation, DNS misuse) are not persuasive rather than sufficiently fulfilled with only the registration data of the domain holder.382 Under Section 3.18.2 of the 2013 RAA a registrar is contractual obligated to ICANN to “establish and maintain a dedicated abuse point of contact, including a dedicated e-mail address and telephone number that is monitored 24 hours a day, seven days a week, to receive reports of illegal activity by law enforcement, consumer protection, quasi-governmental or other similar authorities designated from time to time by the national or territorial government of the jurisdiction in which the registrar is established or maintains a physical office.”383 Under Specification 6 lit. 4.1 of the RA the same applies to the contractual relationship between a registry operator and ICANN. The registry operator is obligated to publish a abuse point of contact as the provision stipulates “registry operator shall provide to ICANN and publish on its website its accurate contact details including a valid e-mail and mailing address as well as a primary contact for handling inquiries related to malicious conduct in the TLD, and will provide ICANN with prompt notice of any changes to such contact details.”384 Thereof results that (not only) because of these contractual requirements firms usually communicate with the abuse point of contact of the registry operator or registrar and not with the respective Admin-A or Tech-C contact as such. Finally, the defendant concludes that this is another indicator that the applicants suggested a particular purpose for the collection of administrative and technical contact data is needless.385 Simultaneously, to the concerns of the processing principles stressed above the defendant also highlights that there is no lawfulness of processing according to Article 6 GDPR. Firstly, there are no alternative legal bases as presented by the applicant (e. g., the processing is necessary for the performance of a contract according to Article 6 (1) lit. b) GDPR; the processing is necessary for the purposes of the legitimate interests lit. f) leg cit. and lastly seeking the consent of the data subject for the data processing under a) leg cit.).386 The defendant recognizes that the applicant’s behavior to let the court select the appropriate legitimate purpose for the respective data processing is unfeasible as well as the GDPR stipulates to specify the particular purpose before subsuming the data processing under the specified clause.387 Secondly, to criticizes from the defendant’s point of view is that the applicant is switching within the particular data processing purposes, which is generally “impermissible under data

382 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 12. 383 See ICANN Board of Directors, ‘Specification 3.18.2 of the 2013 Registrar Accreditation Agreement’, 27 June 2013, pp. 21-22, available at accessed 30 April 2019. 384 See ICANN, ‘Specification 6 lit. 4.1) of the Registry Agreement’, 31 July 2017, 80, available at accessed 30 April 2019. 385Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 13-14. 386 Cf Article 6 (1) of the Regulation (EU) 2016/679 (n 6) 36. Cf also Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 14. 387 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 14-15. ______Matthias Markus Hudobnik 80 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______protection law and contradicts the transparency requirement.”388 The defendant evaluates that Section 3.7.7.6 2013 RAA and the Appendix C - Annex AS 7 of the Temp Spec are contradictory for the reason that the above-stipulated provision of the 2013 RAA, which determines the conditions of consent is phrased simultaneously as the Temp Spec provision, where data processing is based on the legitimate interest. In short, the defendant examines that there is no option to lawfully process data on the legal bases of consent because “the optional collection of the data for Admin-C and Tech-C is not provided for, only the optional publication of such data with consent, see Sections 7.2.2 and 7.2.4 of the Temp Spec, Appendix AS 7 in the Temp Spec.”389 The defendant further refers in this particular issue to the guidance letter of the EDPB from 05 July 2018, which is in line with the defendant. The letter of the EDPB stated that it should be a free decision of the domain holder to offer the administrative and technical contact data duplicated to the domain holder or deliver the data elements anonymized via an e-mail address or web form. In other words, the EDPB confirms that the present policy documents e. g., 2013 RAA and Temp Spec do not lay the foundation - organizational as well as practical - to optionally provide the administrative and technical contact data by the registrant. Thirdly, the defendant scrutinizes that there is the unlawful obligation to obtain a necessary consent from the data subject, which is a breach of Article 7 (4) GDPR and therefore impossible.390 It is worthy of mentioning that the GDPR generally prohibits the coupling of consent. According to Section 3.3.1 2013 RAA, the defendant is contractual bound “to provide the data referred to in Section 3.3.1.7 and 3.3.1.8 2013 RAA with regard to Admin-C and Tech-C”391 as well as there is no option for the involved party to freely decide to whether give the respective consent for the data collection or not. This procedure is reinforced by the Section 3.7.7.6 2013 RAA, where the registrant must guarantee to seek the particular consent. As a result, the defendant summarizes that these contractual provisions force the defendant as registrar to collect the particular data elements e. g., Admin-C and Tech-C and to forward them to the domain holders in an unreserved and similarly manner to fulfill the expected requirements.392 As the defendant states, this implies that they “have no choice but to demand the consent of the persons who are to act on their behalf as Admin-C or Tech-C, as otherwise, they will not be able to fulfill their contractual obligation towards the defendant.”393 The 2013 RAA violates the coupling provisions of the GDPR, and the applicant’s assumptions are mistaken and not compliant with the GDPR. Fourthly, the defendant observes that it is impossible to seek lawful consent, as Article 7 (1) GDPR obligates the person in charge to show the confirmation of the given consent. Subsequently, the defendant acknowledges that registrars are forced to get the consent confirmation of the registrants as well as from all other

388 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 14-15. 389 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 16. 390 Cf Article 7 (4) of the Regulation (EU) 2016/679 (n 6) 37. 391 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 17. 392 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 17. 393 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 17. ______Matthias Markus Hudobnik 81 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______entities which gain these particular data sets if they are determined as data controllers under the applicability of the GDPR. Lastly, the defendant concludes in the comments of the applicant’s immediate appeal that there is even no mechanism to file this confirmation application. The second data processing principle to investigate is the performance of a contract under Article 6 (1) lit. b) GDPR, where the defendant claims that it is not required to collect administrative and technical contact data - as already multiply stated above - to maintain the legal, contractual relationship between the registrant and registrar. Negligible for the current situation are possible individual agreements between third parties and registrants where further clauses through administrative and technical contacts are established, notes the defendant in their comments. Finally, the last data processing principle to consider is the legitimate interests under Article 6 (1) lit. f) GDPR. Also, at this processing principle once more, the defendant points out that the data collection practices are not necessarily based on the legitimate interests as contradictorily assessed by the applicant in the immediate appeal. Under Article 6 (1) lit. f) GDPR the defendant further clarifies that the applicant must beforehand tackle the respective concerned legitimate interests, determining the significance of the data processing as well as illustrating why to safeguard exactly this legitimate interest.394 Simultaneously, the defendant analyses that “the retention of contact data for many of the processing purposes used by the applicant must be regulated by law; this applies in particular where criminal prosecution or other sovereign interests are involved.”395 Lastly, the defendant refers in this context particularly to the case of the ECJ which stipulated that “all these conditions must be such as to limit the scope of the measure and consequently the scope of the persons concerned.”396 This observation is relevant for the present case because the transmission, as well as the retention, needs to be limited to what is necessary as well as proportionate. Taking this into account, the defendant points out that “the applicant has even weighed up the interests of the persons concerned and has examined less drastic measures to achieve the objectives which it may have pursued.”397 The defendant concludes that the applicant failed in the balancing test to weigh the respective interests of the particular parties through each other. Regarding the information requirements according to Article 13 and Article 14 of the GDPR the defendant indicates that it is impossible to inform the registrants as data subjects under the current conditions because the applicant is not providing the particular requirements for the defendant to collect and transfer the additional data elements. Under Article 13 GDPR, the data subject must be informed - including the purpose of processing and the legal basis - when the personal data is collected or processed as well as their recipients or groups of recipients as such. The defendant concludes that the information provided by the applicant is not appropriate enough for the

394 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 17-19. 395 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 20. 396 See ibid. See also C-203/15 Tele2 Sverige [2016] (ECJ, 21 December 2016), para. 103, 110, 120, available at accessed 30 April 2019. 397 See Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 20. ______Matthias Markus Hudobnik 82 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______reason that the purposes for processing are not precisely determined as well as the legal bases for the data collection and processing are not precisely formulated and therefore it is not possible to fulfill the requirements stipulated in the GDPR.398

5.4 Court Order from the Regional Court of Bonn in the Preliminary Injunction Proceedings On 16 July 2018, the Regional Court of Bonn ordered that “the applicant’s immediate appeal of 13 June 2018 against the decision of the chamber of 29 May 2018 will not be remedied and the case will be referred for a decision to the Higher Regional Court of Cologne as the court of appeal.”399 The court further points out that “there was no basis for granting relief, either in view of the original (main) application or in view of the submitted alternative application.”400 The court claims that it currently not sees the necessity for an additional collection of administrative and technical contact data, and it is evident that the collection of more data elements leads to a plainer clarification process of whom the data is stored as well as provides stronger, and more broaden opportunities to gain the data subject’s stored information. The essential point is that the court examines that also before the GDPR came into force the data collection of Admin-C and Tech-C was not compulsory and depended on a free will of the domain holder to provide the personal data or not. Taking this into account, the court argues that this proofs that the further collection of e. g., Admin-C, and Tec-C data elements is not necessarily because the domain name system worked in the past also without any further potential collection of these data elements. Subsequently, this illustrates that the argumentation of the applicant, namely to force the defendant collecting Admin-C and Tech-C data for the reason that these data elements are indispensable necessary seems to be mistaken.401 Moreover, the court was not convinced by the argument of the applicant “justifying the necessity of storing the data of third parties in the Admin-C and Tech-C categories with the corresponding needs of the registrant itself”402 and concludes that from a legal point of view it has no decisive relevance for the contractual connection among the defendant and applicant. The court also recognizes that the applicant might be correct that the defendant is contractually obligated to collect administrative and technical contact data via the agreement - based on consent if a person might be involved - with the applicant, but this does not apply to the alternative application in the immediate appeal.403 In short, the chamber criticizes that “it is too vague to determine how consent is to be secured or recorded in the registration process in the future and what specific action is therefore requested from the applicant.”404

398 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 22. 399 See Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) 2. 400 See ibid. 401 Cf Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) pp. 2-3. 402 See Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) 3. 403 Cf Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) 3. 404 See Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) 3. ______Matthias Markus Hudobnik 83 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

Moreover, the court assesses that defendant’s current collection practices gathering personal data are not in line with data protection law because the registration procedure cannot guarantee that the registrants have lawfully obtained the consent of the third party - if so there is currently no verification evaluation implemented to recognize it - for the data collection as such. The court highlights that the data collection and processing may be lawful if the defendant seeks the consent of the affected party e. g., data subject for the particular purposes, but it must stick to particular period time. The chamber concludes that the same applies for the alternative application of the claim in which the applicant emphasizes on exceptional cases where - related to administrative and technical contact data - elements are not falling under the scope of personal data under the GDPR. It is the case in the context of a legal person connected to a registrant’s delegation of the Admin-C and Tech-C tasks. Lastly, the court is referring to the above stated and concludes that the evaluation can only be effective and successful in connection with the implementation of an ex-post assessment by the defendant. This procedure may be utilized to evaluate if personal data is processed concretely, and this assumes that there are already (personal) data elements of the domain holder available; otherwise, it is not conceivable.405

5.5 ICANN’s Supplemental Submission to the Higher Regional Court of Cologne The applicant negates the justifiability of the court remedy order in the supplemental submission dated 27 July 2018 and illustrates the two following arguments:406 Firstly, the legal assessment of the remedy order lacks on the pertinent facts and secondly, the main, as well as the alternative claim, are legally well-founded.407 Starting with the first argument, the applicant states that the defendant is “still in the position to collect such data but is in the process of changing the system,”408 and the suggestion of the remedy order negates that the voluntary possibility for the registrant to still provide the defendant with the administrative and technical contact data is out of dispute. The applicant further claims that the defendant is still able to gain administrative and technical contact data from the registrant. Also, the applicant refers to the remedy order of the court to emphasize in the context of the consent verification process where the court argues that this was not possible within the respective framework, but the applicant represents the opposite view. In short, the decision of the court is misinterpreted, as the court has focused the responsibility on the wrong party for seeking the necessary explicit consent as such.409

405 Cf Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) pp. 3-4. 406 Cf Jakob Guhn, ‘Supplemental Submission’, JONES DAY Rechtsanwälte, 27 July 2018, 2, available at accessed 30 April 2019. 407 Cf Guhn, ‘Supplemental Submission’ (n 406) 2, 5, 10. 408 See Guhn, ‘Supplemental Submission’ (n 406) 2. 409 Cf Guhn, ‘Supplemental Submission’ (n 406) 3. ______Matthias Markus Hudobnik 84 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

The applicant claims that “the defendant as registrar is responsible for establishing its own domain name registration process”410 and if this process is not compliant with the GDPR, it is the registrar’s responsibility to adapt the procedure to be compliant with the GDPR. Taking this into account the applicant notes that neither the Temp Spec nor the 2013 RAA prevents the defendant from seeking the legal consent of the data subject for the registration process to be in line with the GDPR. Moreover, the applicant highlights that the court wrongly assumes that processing and collection of Admin-C and Tech-C data are optionally and not necessary. Subsequently, the applicant assesses that it makes very well sense to act as above mentioned if the data set is different from the domain holder’s data or the domain holder is instructing tasks of the Admin-C and Tech-C to third persons.411 According to Article 5 (1) lit. b) GDPR and the processing of administrative and technical contact data the applicant refers once again to the immediate appeal and their certain clarifications (further details emphasized in Chapter 5.3) which are in line with the guidance of the EDPB dated 05 July 2018 as well as that the concerns of the court are unfounded.412 In short, the EPDP indirectly approves the argumentation of a legitimate purpose if the registrant is voluntarily delegating tasks of an Admin-C or Tech-C to a third person.413 Finally, the applicant evaluates that the remedy order “does not even mention the criteria of legitimate purpose according to Article 5 GDPR; however, the applicant assumes that the regional court appears to no longer maintain the position that the data processing lacks a legitimate purpose according to Article 5 GDPR.”414 Furthermore, the applicant points out that the court even “does not cite any provision of the GDPR that is allegedly violated by collection the Admin-C and Tech-C data.”415 Concerning the main claim and under Article 6 GDPR the court states that the collection of administrative and technical contact data is not justified in terms of the consent verification of the data subject as well as the storage and collection of the administrative and technical contact data. Contrarily, the applicant contends that the “court’s reasoning is flawed”416 and that “the GDPR neither requires a ‘verification of consent’ from every entity relying on consent for its processing activities nor does the GDPR foresee an absolute imperative under which the ‘necessity’ criterion is applied.”417 In short, the applicant’s view is that the GDPR does not require a ‘verification of consent’ and argues that it “is merely a burden of proof rule” rather than “a condition for the validity of the consent”418 rule. In other words, the applicant illustrates that under Section 3.7.7.6 2013 RAA, the domain holder as usually the first controller has the contractual obligation to seek the consent of the third person involved, which is usually the Admin-C and Tech-C. The applicant

410 See Guhn, ‘Supplemental Submission’ (n 406) 3. 411 Cf Guhn, ‘Supplemental Submission’ (n 406) pp. 3-4. 412 Cf Guhn, ‘Supplemental Submission’ (n 406) 6. 413 Cf EDPB, ‘Letter from Jelinek to Marby’ (n 69) 4. 414 See Guhn, ‘Supplemental Submission’ (n 406) 6. 415 See ibid. 416 See Guhn, ‘Supplemental Submission’ (n 406) 7. 417 See ibid. 418 See Guhn, ‘Supplemental Submission’ (n 406) 7. ______Matthias Markus Hudobnik 85 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______summarizes that it is up to the defendant as registrar to freely decide if whether sticking to this delegation procedure or not. Besides, neither the Temp Spec nor the 2013 RAA is breaching as well as hindering this procedure of seeking consent. At the end of the main claim the applicant highlights that the court wrongly interpreted the meaning of necessity in the context of the data collection and storage e. g., as a general necessity-requirement rather than in line with Article 5 (1) lit b) and c) GDPR as in relation to the purpose for which data is processed.419 In short, the applicant analyses that this interpretation “limits the party’s freedom of contract, and in particular, their freedom to set their own data processing purposes.”420 This interpretation of the necessity-requirement is not implied by Article 6 (1) lit f) GDPR. According to Article 6 (1) lit f) GDPR “processing (collection) of Admin-C and Tech-C data is lawful, if processing (collection) is necessary for the purposes of the legitimate interests pursued by the controller or by a third party [...], necessity also has to be determined in relation to the purposes of the legitimate interests pursued by the controller or by a third party.”421 Pertinently to the present case is in the opinion of the applicant only outstanding “whether the collection of the Admin-C and Tech-C data is necessary for the purpose of the data collection”422 in the relation of the domain holder and the delegated task to third parties. Concerning the alternative claim, the applicant illustrates that it is well founded, and a collection based on consent as well as a collection of non-personal data is possible. In brief, the applicant claims that the court’s decision is erroneous as it states that the defendant’s collection of administrative and technical contact data - grounded on the legal basis of consent - was due to the vagueness of determination in the consent procedure and the lack of verification not conceivable. The applicant points out that the defendant is a data controller under the scope of the GDPR. Therefore, forced to act compliant and adds - as the court has already decided - that there is no GDPR provision as such stipulating the accuracy of the safeguarding and capturing of the consent-requirements for the upcoming registration procedure. In terms of the collection of non-personal data, the applicant contradicts to the decision of the court - the data collection is a precondition for the distinction of personal or non-personal data - namely, that it is defective and very well possible to collect without a further data distinction.423 Subsequently, such an argumentation would mean that “each and every processing of data would be unlawful where there would be a possibility that personal data of a third party could be entered.”424 Finally, the applicant adds that there is no previous method for data verification to guarantee that somebody’s initial submission of personal data as a domain holder indeed originates from this denoted domain holder. Lastly, the applicant concludes that the remedy order lacks on a

419 Cf Guhn, ‘Supplemental Submission’ (n 406) 8. 420 See Guhn, ‘Supplemental Submission’ (n 406) pp. 8-9. 421 See Guhn, ‘Supplemental Submission’ (n 406) 9. 422 See ibid. 423 Cf Guhn, ‘Supplemental Submission’ (n 406) pp. 10-12. 424 See Guhn, ‘Supplemental Submission’ (n 406) 12. ______Matthias Markus Hudobnik 86 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______legal basis as comprehensively illustrated above as well as that in the “applicant’s application for relief and immediate appeal, the order has to be granted.”425

5.5.1 EPAG’s Comments on ICANN’s Supplemental Submission The defendant contradicts in the comments on the applicant’s supplemental submission dated 01 August 2018 that the guidelines of the EDPB solely confirm that there is a more substantial adaptation - more sufficient than the applicant’s former modifications - of the Temp Spec as well as the WHOIS model required to be compliant with the GDPR. The defendant clarifies that the EDPB explicitly states that the registrant should generally not be forced to seek personal data. Contradictory, to the EDPB’s guidance the Temp Spec as well as the 2013 RAA - which are the legal grounds - oblige the registrant to provide personal data for the administrative and technical contact (further details in Chapter 5.3.3).426 The defendant points out that “the applicant has not yet taken the necessary steps to be able to collect data based on consent in a legally unobjectionable manner and to transfer it to the applicant and other parties involved.”427 The defendant further acknowledges the EDPB’s advice to strictly distinguish the lawfulness of collection from the publication of the personal data and adds the fact that the EDPB’s letter is only dealing with the publication of personal data, and this does not (automatically) presume that the preliminary collection is lawfully and compliant with the GDPR. Taking this into account the defendant refers to their comments on the applicant’s immediate appeal (further details in Chapter 5.3.3) were the defendant already stated that a lawful collection of personal data is the precondition for a later publication of such respective data. Furthermore, the defendant is referring to the guidelines of the EDPB, which examines that the applicant’s necessary data collection practices – as pointed out in the applicant’s main submission - are unlawful and not enforceable.428 Moreover, the defendant summaries that the alternative claim of the applicant – to optionally process and collect personal data - is not within the scope of the contractual agreement. Presumably, this would be the case; there are still the “legal and factual preconditions”429 missed “to enable the defendant to collect the data on this basis.”430 Finally, the defendant highlights that the “applicant is subject to a misconception”431 and further concludes that “it is not a question of finding a legal basis for the fact that the data processing requested by the applicant is not possible, but rather of finding legal bases which allows data processing.”432

425 See ibid. 426 Cf Thomas Rickert, ‘EPAG’s Comments on ICANN’s Supplemental Submission’, Rickert Rechtsanwaltsgesellschaft mbH, 01 August 2018, pp. 1-2, available at accessed 30 April 2019. 427 See Rickert, ‘EPAG’s Comments on ICANN’s Supplemental Submission’ (n 426) 2. 428 Cf Rickert, ‘EPAG’s Comments on ICANN’s Supplemental Submission’ (n 426) 2. 429 See Rickert, ‘EPAG’s Comments on ICANN’s Supplemental Submission’ (n 426) pp. 2-3. 430 See ibid. 431 See Rickert, ‘EPAG’s Comments on ICANN’s Supplemental Submission’ (n 426) 3. 432 See ibid. ______Matthias Markus Hudobnik 87 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

5.6 Order from the Higher Regional Court of Cologne Regarding ICANN’s Immediate Appeal On 01 August 2018, the Higher Regional Court of Cologne ordered that “the applicant’s immediate appeal of 13 June 2018 against the order of the Regional Court of Bonn of 29 May 2018, in the version of the non-remedy order of 16 July 2018, is rejected.”433 The court further assesses in the application of the main claim that “the granting the sought interim injunction fails in any case because the applicant has not sufficiently explained and made credible a reason for a preliminary injunction.”434 Furthermore, the basis of the claim focuses on the formulation rather than on the content, which results in cessation and desistance. Taking this into account, the court examines that the main application of the claim as well as the alternative application - with the minor difference of limitations at the alternative one - have similar intentions. The main application safeguards the applicant the collection of Admin-C and Tech-C data via the defendant who needs to fulfill the contractual agreements, namely offering the expected contractual promised services.435 The court points out “that a preliminary injunction is required in order to avoid substantial disadvantages”436 and is not convinced by the applicant’s argumentation of these substantial disadvantages. Also, for the applicant’s argumentation in the interim relief, that there are irreparable harm and the concern of the irretrievable data-loss in the case of a non-collection, applies the same. The court argues that a later data collection of the registrant’s personal data would also be feasible, and the technical change of the defendant does not hinder these practices.437 The court state that it is “not clear to what extent the storage of the data of the so-called Tech- C and the so-called Admin-C is necessary for the applicant’s purposes and, consequently, why failure to collect the data would result in substantial disadvantages.”438 Subsequently, the court analyzes that the collection of administrative and technical contact data is not necessary for the applicant’s purpose because until now it was up to the free will of the domain holder to delegate tasks to a third person - through the technical or administrative contact - or not. Taking this into account, the applicant states that a non-collection of administrative and technical contact data would result in a slower and less effective cybercrime investigation procedure and subsequently points out that, even if this would be the case, it does not justify the additional data collection, in the legal view of the court.439 Lastly, the court highlights that “irrespective of the fact that only the abstract danger of delays in a case of abusive practices cannot justify the sought preliminary injunction”440 and adds that defendant’s previous data set – which is undisputed by the applicant and further emphasized in Chapter 5.3.3 - supports the court’s legal decision. Finally, the court concludes

433 See Germany: Higher Regional Court of Cologne (n 68) 1. 434 See Germany: Higher Regional Court of Cologne (n 68) 2. 435 Cf Germany: Higher Regional Court of Cologne (n 68) 2. 436 See Germany: Higher Regional Court of Cologne (n 68) 3. 437 Cf Germany: Higher Regional Court of Cologne (n 68) pp. 3-4. 438 See Germany: Higher Regional Court of Cologne (n 68) 3. 439 Cf Germany: Higher Regional Court of Cologne (n 68) pp. 3-4. 440 See Germany: Higher Regional Court of Cologne (n 68) 3. ______Matthias Markus Hudobnik 88 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______that - as above mentioned - the applicant’s substantial disadvantages cannot be seen in the preliminary injunction and references the applicant to the main processing as to claiming their assert rights.441

5.7 ICANN’s Plea of Remonstrance It should be noted for this subchapter, that the content of the applicant’s plea of remonstrance is heavily based on procedure argumentations (e. g., violation of the applicants right to be heard and that the appellate court failed to give the applicant proper notice concerning Section 139 ZPO) of the applicant. Therefore, the author focuses on the most relevant arguments to the topic and the research questions. Firstly, the applicant once again analyzed the decision of the appellate court dated 01 August 2018 and submitted a plea of remonstrance with the request “to continue the immediate appeal proceedings according to Section 321a para. 5 ZPO”442 and further referred to the primary and alternative claim in the initial motion for issuance of the preliminary injunction (further emphasized in Chapter 5.1). Within the plea of remonstrance, the applicant demonstrates that the appellate court missed dealing with fundamental facts of the case as well as legal issues. The applicant negates the fact that a later collection of administrative and technical contact data is conceivable, but more astonishing is the fact that even the defendant was not arguing this approach as such. Secondly, the applicant refers to the application of the immediate appeal (further discussed in Chapter 5.3) where it is comprehensively explained that a later collection will be opposing the process in terms of the delegation of tasks to third parties since the data is not collected. The applicant states that the result would be an irreversible loss of these crucial data elements and forces the registrant to maintain these tasks - which were before (potentially) delegated to third parties via the administrative and technical contact - by them self. Additionally, the applicant highlights the risk that due to the legal uncertainty and the ongoing litigation, it may potentially take years without a final decision. In the end, this leads to a non-collection of these data elements and may result in the complete elimination of the previous collection practices of the administrative and technical contact data.443 Finally, the applicant claims that the appellate court has “fundamentally misunderstood the immediate consequences of its decision.”444 Lastly, the applicant assesses that the court is subject to a wrong legal assumption concerning the only abstract danger. In short, the applicant negates the court’s view and states that an only abstract danger is very well enough to justify the preliminary injunction.445

441 Cf Germany: Higher Regional Court of Cologne (n 68) pp. 3-4. 442 See Jakob Guhn, ‘Plea of Remonstrance’, JONES DAY Rechtsanwälte, 17 August 2018, pp. 1-2, available at accessed 30 April 2019. 443 Cf Guhn, ‘Plea of Remonstrance’ (n 442) pp. 7-9. 444 See Guhn, ‘Plea of Remonstrance’ (n 442) 9. 445 Cf Guhn, ‘Plea of Remonstrance’ (n 442) pp. 9-10. ______Matthias Markus Hudobnik 89 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

For example, in the case of fraud or cybercrime “the legally protected interests involved”446 are vitally important, have a profound impact and fall under the scope of applicability to justify also only on a theoretical danger approach. Furthermore, the applicant refers to the submission of the preliminary injunction and underscores that the administrative and technical contact is the key person to communicate and advice fraud or cybercrime victims, which is essential to mitigate the abusive behavior and react efficiently. Thirdly, the applicant highlights that the defendant is forced by contractual agreements (e. g., 2013 RAA, RA, Temp Spec) to collect and storage administrative and technical contact data, especially concerning the alternative claim, which does not force the defendant to collect and store personal data sets of the Admin-C and Tech-C. Also, the procedure in doing so is under the free will of the defendant, in either seeking the consent of the data subject or not. Lastly, the applicant refutes that “the defendant cannot argue that such cease and desist claim unfairly affects its interests.”447 Contradictorily the defendant’s practice of non-collection of administrative and technical contact data through the domain name registration is their independent decision and even when the collection is lawfully under the seeking consent from the particular data subject. Taking this into account, the applicant concludes that, the defendant is even in the situation to decide whether providing their domain registration services to registrants – through the collection practices as mentioned above - as contractually stipulated or breaching the agreement.448 Finally, the applicant points out that there is a matter of urgency related to the present case and criticizes that “the appellate court had wrongly applied stricter requirements on urgency and assumed that the Admin-C and Tech-C data can be collected at a later stage.”449 Subsequently, the appellate court would not have “wrongly rejected a concrete danger from the delays in collecting Admin-C and Tech-C data”450 and in conclusion, “it would not have rejected the urgency of the applicant’s claim.”451

5.7.1 EPAG’s Comments on ICANN’s Plea of Remonstrance In the defendant’s comments on the applicant’s plea of remonstrance dated 30 August 2018, the defendant at first-hand points out that it is unfounded as well as that there is no violation of the applicant’s right to be heard in the appellate court’s decision dated 01 August 2018.452 Contradictorily, the applicant attempts to newly roll up the case, which is not in line with the purpose of the plea of remonstrance and argues that the appellate court’s decision is reprehensible from a procedural point of view. Under Section 139 para. 2 ZPO is to highlight

446 See Guhn, ‘Plea of Remonstrance’ (n 442) 10. 447 See Guhn, ‘Plea of Remonstrance’ (n 442) 13. 448 Cf Guhn, ‘Plea of Remonstrance’ (n 442) pp. 11-13. 449 See Guhn, ‘Plea of Remonstrance’ (n 442) 14. 450 See ibid. 451 See Guhn, ‘Plea of Remonstrance’ (n 442) 14. 452 Cf Thomas Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’, Rickert Rechtsanwaltsgesellschaft mbH, 30 August 2018, 2, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 90 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______that “a violation of the judicial duty to give legal notice does not exist”453 as well as that the non-rejection of the court’s decision was a foreseeable scenario for the applicant.454 In the context of the right to be heard before the court, the defendant rectifies that “the fact that the applicant was obviously and inaccurately of the opinion that she had dismissed the respondent’s objections with this statement does not constitute a violation of the right to be heard.”455 Moreover, it is the applicant’s free choice to select their legal advisors, who are confident enough, dealing with these legal issues as such. Concerning the interpretation of the Senate of the Higher Regional Court, the defendant underscores the legal view, namely that it is not a matter of the legal formulation rather than a substantive interpretational issue of the respective content as such. Considering this, the defendant points out, that a review and clarification of the interpretation of the Senate’s decision would be a material issue and therefore out of range of the particular plea of remonstrance. The defendant adds that there are no causes to assume that the court aims to misinterpret the legal arguments of the respective parties to the proceedings nor are there any indications of a misjudged decision or a disproportionate exceedance of the scope of applicability.456 Thus, the defendant comments on the applicant’s plea of remonstrance and points out that the applicants main claim application is again substantively the same, namely unlawfully forcing the defendant to collect and storage administrative and technical contact data based on the 2013 RAA which is per se inadmissible under the GDPR. Also, the defendant contradicts the applicant’s view and claims that the facts of the dispute are accurately as well as underscores that a later collection of the administrative and technical contact data is possible even if there is a technical change in the defendant’s registration procedure. Moreover, the defendant acknowledges that even though if the registrant as the data subject is obligated to consent to the processing and storage at the end, it is not unfeasible to act in this manner and the defendant negates the entire and sustained data elements loss, in contrast to the applicant’s view. Thus, the applicant’s argumentation is contradictory for the reason that, on the one hand, the applicant states that, the selection of an administrative and technical contact is obligated for big companies. This circumstance may result in the correct behavior by the vast majority of domain holders for big companies, which means that this procedure will be doable at a later stage and even after the proceedings. On the other hand, if the domain holder has the (freely) option not to select the respective contacts, (e. g., Admin-C and Tech-C), this leads to an unreliable urgent necessity identified by the applicant’s plea of remonstrance. In the defendant’s final legal observation, there is no violation of the right to be heard applicable because there is no basis for this assumption as well as no link to the case related to such procedural requirement. Finally, the defendant negates that nor the - legally protected interests as stated by the applicant - abstract danger in case of abusive practices is

453 See Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) 3. 454 Cf Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) pp. 4-5. 455 See Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) 6. 456 Cf Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) 7. ______Matthias Markus Hudobnik 91 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______enough to justify the preliminary injunction, neither is this a violation of the right to be heard and in any case is a substantive review out of scope of the plea of remonstrance.457 At the end of the defendant’s comments on the applicant’s plea of remonstrance the defendant clarifies, that the applicant wrongly interpreted the decision of the court. In particular, the defendant states “that the issuance of a preliminary injunction generally requires that the legal criterion concrete danger must be fulfilled”458 rather than “that in the concrete case at hand the abstract danger of possible delays do not justify the issuance of a preliminary injunction.”459 In short, the defendant is incapable of illustrating specific adverse implications as well as the particular urgency requirement because the applicant’s submission is materially wrongful.460

5.8 Order from the Higher Regional Court of Cologne Regarding ICANN’s Plea of Remonstrance On 03 September 2018, the 19th Civil Senate of the Appellate Court of Cologne ordered: “that the plea of remonstrance of 17 August 2018 filed by the applicant concerning the order of the Senate of 01 August 2018 is rejected.”461 The Senate highlights that the applicant’s right to be heard is not violated and the Higher Regional Court of Colognes decision dated 01 August 2018 was nor unlawfully, neither surprisingly for the applicant, but somewhat foreseeable as well as the applicant could comment on it.462 Furthermore, the Senate points out that “in the absence of a violation of the right to be heard there is no possibility for a ‘new decision,’ weighing of interests or holding an oral hearing, ‘in order to clarify any ambiguities in this case.’”463 The court examines that the reasoning of the preliminary injunction is not similar to the Senate’s decision dated 01 August 2018 and therefore a further assessment has no right to exist. Moreover, the court does not see the matter of urgency in the context of the preliminary injunction which is in contrast to the consideration of a (potential) ECJ referral – where a timely decision is unforeseeable – as stipulated by the applicant cannot be approved by the Senate.464 Apart from that, the Senate examines that the issues comprehensively pointed out in the decision dated 01 August 2018, are inappropriate to solve the objections of the applicant. The Senate finally points out that “there are no reliable indications for its assumption that a temporary non-collection of data on the so-called Admin-C and Tech-C could not be rectified or that in such case such damage was caused to the applicant that the disadvantages associated with the requested injunction caused to the defendant and third parties are

457 Cf Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) pp. 8-9. 458 See Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) 9. 459 See ibid. 460 Cf Rickert, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’ (n 452) 9. 461 See Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) 1. 462 Cf Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) 2. 463 See Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) pp. 2-3. 464 Cf Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) 3. ______Matthias Markus Hudobnik 92 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______outweighed by the interests of the applicant, especially as the provision of the information, the collection of which the defendant now refuses, was also not previously obligatory.”465 The GDPR – which is already in force since 25 May 2018 - is supporting this argumentation of the Senate and obligates the parties, who are under the scope of applicability to fulfill various principles e. g., the principle of data minimization as well as that the activities of personal data processing are restricted as legally required to protect the rights of the data subjects. Finally, the court states that the ultimate result of the legal obligation to collect the administrative and technical contact data is grounded on the legal contract between the respective parties and their interpretation as such but bearing in mind that the procedure of a preliminary injunction is out of scope for this particular assessment. As a finite result, the Senate concludes in the plea of remonstrance that there is no cause for neither a legal nor a factual evaluation of the particular circumstances, which differ from the decision of the Higher Regional Court of Cologne dated 01 August 2018.466

5.9 Conclusion This litigation has shown both the practical relevance of the WHOIS system and the GDPR, and that a reform of the current situation is necessary and indispensable in order to be compliant with data protection laws. The defendant consistently referred to the data collection practice of the applicant, and emphasized that this procedure was neither necessary nor GDPR compliant. At the same time, the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec) was still in full progress. Already the ‘Initial Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’467 (initial report), dated 21 November 2018, stated that the data collection of Admin-C and Tech-C was not necessary and if it were to be collected, then it must be optional. On 03 September 2018, the Higher Regional Court of Cologne decided in the final judgment of the litigation, that the previous data collection practices were unlawful under the GDPR. This final decision was made whilst the EPDP on the Temp Spec was in process, and proves that the second hypothesis, namely that ICANN v. EPAG has potentially influenced the EPDP on the Temp Spec especially in the context of Admin-C and Tech-C data, is correct. The ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’468 (final report), dated 20 February 2019, reconfirms the above legal perspective within their 29 policy recommendations. As a result, almost all tech fields are either optional to collect (e. g., this applies for the collected data of the registrars, the transfer of data elements from registrar to registry, transfer registrars/registries to the data escrow agent) or redacted from the public RDDS, as was argued by the defendant in the litigation ICANN v. EPAG.

465 See Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) 3. 466 Cf Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) pp. 3-4. 467 Cf ICANN GNSO, ‘Initial Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 247). 468 Cf ICANN GNSO, ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 250). ______Matthias Markus Hudobnik 93 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

The following subchapter provides answers to the research questions raised in relation to the litigation at hand:

5.9.1 Is the further collection and storage of personal data - of the administrative and technical contact so-called Admin-C and Tech-C - besides the data of the registrant as stipulated via the 2013 RAA, lawful under the GDPR? The final decision of the comprehensively analyzed litigation ICANN v. EPAG (further details explained in Chapter 5.1 to 5.8) through the various procedural court stages, is that the collection of administrative and technical contact data is unlawful under the GDPR. The results of the final decision support the previous prediction that the WHOIS system was modified to be compliant with the GDPR as well as to restrict the current data collection practices of the different stakeholders involved to the maximum extent possible in order to make them compliant with the GDPR. Data collection is only lawful under particular purposes and legal grounds stipulated in the GDPR. For a better understanding, the author provides a brief chronological overview of the various procedural stages, starting with the decision of the Regional Court of Bonn. Firstly, the court decided that the application for a preliminary injunction was unfounded as well as unsubstantiated and concluded that there was no collection and storage of Admin-C and Tech-C required, which is also in line with the GDPR’s principle of data minimization. Finally, the court referred to the defendant’s clearly illustrated number of previous registrants, who had not stored or collected contact details, and did not even have any implications with their domains at all, which again strongly supports the court’s decision (further details emphasized in Chapter 5.2).469 Secondly, the Regional Court of Bonn referred to the applicant’s immediate appeal to the Higher Regional Court of Cologne without remedy. The Regional Court of Bonn underlines that it currently does not see any necessity for the collection of administrative and technical contact data. Furthermore, the court also argues that before the GDPR came into force, the data collection of Admin-C and Tech-C was not compulsory, and depended on the free will of the domain holder to provide their personal data or not. Finally, the Regional Court of Bonn highlighted that the data collection and processing may be lawful if the defendant seeks the consent of the data subject for their particular purposes, but must only retain the data for a particular period of time (further details explained in Chapter 5.4).470 Thirdly, the Higher Regional Court of Cologne rejected the applicant’s immediate appeal against the order of the Regional Court of Bonn. Also, the Higher Regional Court of Cologne advocated the legal view that the collection of administrative and technical contact data was not necessary for the applicant’s purpose, because previously it was up to the free will of the domain holder whether they made their data generally available, supplied personal data to a third party or withheld it. Another important practical implication – stated by the Higher Regional Court of Cologne - is that even if not collecting administrative and technical contact

469 Cf Germany: Regional Court of Bonn (n 68) pp. 4-6. 470 Cf Germany: Regional Court of Bonn in the Preliminary Injunction Proceedings (n 68) pp. 2-3. ______Matthias Markus Hudobnik 94 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______data would result in a slower and less effective cybercrime investigation procedure, this does not in itself justify the data collection. Finally, the Higher Regional Court of Cologne concluded that the applicant’s substantial disadvantages in the preliminary injunction were not seen by the court and referred the applicant to the primary processing (further details in Chapter 5.6).471 Fourthly, the Senate of the Appellate Court of Cologne finally decided to reject the applicant’s plea of remonstrance. The Senate concluded that the reasoning of the preliminary injunction differed from the decision of the Higher Regional Court of Cologne in the immediate appeal. Therefore, there was no cause for either a legal or factual evaluation of the particular circumstances, and no matter of urgency as postulated by the applicant (further details in Chapter 5.8). The findings of this litigation have several practical implications for the reform of the current WHOIS system, which has already been comprehensively analyzed at the beginning of this subchapter.472

5.9.2 Are the processing purposes in the Temp Spec for the data of the Admin-C and Tech-C sufficiently specified? It must be highlighted that the Temp Spec in particular is not sufficiently determined, as was already assessed in the guidelines of the EDPB, dated 05 July 2018, as well as in the submissions of the defendant. The EDPB specifically pointed out that it is essential to differentiate between the various purposes (e. g., the purposes of controllers and third parties) for data processing and the data collection of the various involved parties and not lump them together.473 In the litigation ICANN v. EPAG, the defendant underlined the fact that the Temp Spec fails to provide a correct guideline in the context of the processing purposes. The results illustrate that there are Sections in the Temp Spec (e. g., Section 4.4.8 and 4.4.9 Temp Spec), which are imprecise, as the wording of various terms are too general (e. g., issues, needs of law enforcement authorities) in the respective sections, and subsequently it is not feasible to properly subsume.474 The results of this investigation show that ICANN’s interests regularly outweigh the interests of the affected parties.475 These findings suggest that ICANN needs to fundamentally modify the Temp Spec, as may currently be the case in the ongoing EPDP on the Temp Spec in order to make it compliant with the GDPR. Thus, there is a definite need for the realization of the recommendations stipulated in the ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process,’ dated 20 February 2019.476

471 Cf Germany: Higher Regional Court of Cologne (n 68) pp. 3-4. 472 Cf Germany: Higher Regional Court of Cologne in the Plea of Remonstrance (n 68) pp. 3-4. 473 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) 4. Cf also EDPB, ‘Letter from Jelinek to Marby’ (n 69) 2. 474 Cf Rickert, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’ (n 370) pp. 7-8. 475 Cf Rickert, ‘EPAG Protective Letter’ (n 318) 11. 476 Cf ICANN GNSO, ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 250). ______Matthias Markus Hudobnik 95 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

6 General conclusion and outlook The main aim of this diploma thesis is to give a scientific analysis of the future of WHOIS and a perspective on the Policy Development Process under the GDPR, with a focus on the first significant litigation in this context, namely ICANN v. EPAG. Besides this, the diploma thesis summarizes the current situation and future expectations of the WHOIS system under the GDPR via general assessment of the analyzed Compliance Models on the one hand and, the previous Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data (Temp Spec) on the other. The author established three hypotheses in the Introduction. Two of them were fulfilled, namely the first and second, with the third unable to be finally proven, because the matter is part of the ongoing Phase 2 of the EPDP on the Temp Spec. The data in Chapter 4.1 and the conclusion of Chapter 4.1.5 prove that the first hypothesis, which states that the GDPR was the catalyst for the adoption of the Compliance Models and subsequently, the modification process of the previous WHOIS database publication practices, is correct. The WP29/EDPB already highlighted these compliance violations in connection with the WHOIS system since 2003477 - without any success in convincing ICANN and the stakeholders involved to modify the WHOIS system. After ICANN58, ICANN figured out their fundamental role in the context of WHOIS and the GDPR, and regularly came under legal pressure because of the encroaching date of the GDPR being enforced, which resulted in them seeking community input, and subsequently adopting various Compliance Models developed by the community. Consequently, the Temp Spec was adopted, and came into force on the same date as the GDPR, thus beginning the EPDP process. As a result, the application of the GDPR with its severe penalties was the reason for the adoption of the Temp Spec, which would otherwise never have been created. Also, the fact that these compliance violations, in connection with the WHOIS system, have been on the table since 2003, but never seriously been dealt with to make the WHOIS system complaint under the previous data protection laws, proves the validity of the first hypothesis. According to the second hypothesis, the analysis in Chapter 4.2 and the conclusion in Chapter 4.2.2 prove that the litigation ICANN v. EPAG has potentially influenced the EPDP on the Temp Spec, especially, in the context of Admin-C and Tech-C data. Firstly, the litigation ICANN v. EPAG, happened in parallel with the ongoing EPDP and was finally decided before the ‘Initial Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’478 (initial report), as well as the ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’479 (final report) was completed. Secondly, both reports fulfill precisely the criteria to be compliant

477 Cf WP29, ‘Letter from Isabelle Falque-Pierrotin to Cherine Chalaby and Göran Marby regarding GDPR’ (n 63) 3. 478 Cf ICANN GNSO, ‘Initial Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 247). 479 Cf ICANN GNSO, ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 250). ______Matthias Markus Hudobnik 96 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______under the GDPR, which were under debate in the correspondence concerning the particular data fields (e. g., Admin-C and Tech-C) of the parties in the dispute. The third hypothesis states that there is a need for a system of standardized access to non- public registration data, adjusted in accordance with the technical implementation process, which is lawful under specific data protection laws. This hypothesis cannot be finally proven because this matter is part of Phase 2 of the EPDP on the Temp Spec, but the similar categorizations made in the Compliance Models, including a (self)-certification, accreditation, and legal due process approach, are further explained in Chapter 4.1.4.1. The current study is based on present policy documents, guidelines from relevant stakeholder groups and the law, but it should be noted that little research has been conducted because of the current reality of this topic. A limitation of this study is that Phase 2 of the EPDP on the Temp Spec has not been finalized. However, the diploma thesis aims to be an illustrative and complementary contribution to this matter. The results of the study cover the significant policy developments and documents in connection with the WHOIS Policy Development Process up to 30 April 2019. The first aim of this study is to investigate, in general, how can access to crucial information and protected data in the WHOIS system be ensured? Specifically, in light of the first and second hypothesis, the thesis focuses on the Compliance Models and whether the data fields of the essential criteria, such as: ‘data collection,’ ‘processing and retention,’ ‘scope of applicability’ and ‘tiered/layered access to non-public/public WHOIS’ data are compliant with the GDPR. Subsequently, the following five research areas were analyzed:  Purpose and lawfulness of processing activities and the collection of specific registration data  Transfer of data from registrars to registries as well as to data escrow agents  Data retention period for registrars, registries as well as escrow agents  Scope of applicability for the different models  Access to public/non-public WHOIS data to be organized, for example via accreditation program or a tiered/layered access model Overall, the comprehensively analyzed Compliance Models in Chapter 4.1 and the conclusion of Chapter 4.1.5 as well as the EPDP on the Temp Spec with the final recommendations in Chapter 4.2 and the conclusion of Chapter 4.2.2, demonstrate that generally an immense effort is required to be compliant with the GDPR and, other data protection laws. The second aim of this diploma thesis is to legally assess the various procedural stages of the litigation ICANN v. EPAG, through two research questions concerning the lawfulness of the collection, and storage of the administrative and technical contact data, as well as the registrant’s data – contractually obligated by 2013 RAA - under the GDPR. Besides this, the second question asked whether the specification of the processing purposes in the Temp Spec - for the administrative and, technical contact data - is sufficiently determined. The results of

______Matthias Markus Hudobnik 97 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______this case demonstrate the practical relevance of the topic and, the global impact of the GDPR, as well as that an improvement of the current domain name registration practice is crucial to ensure legal and factual certainty for the parties involved. The comprehensively analyzed litigation in Chapter 5 indicates that the previous storage and collection of administrative and technical contact data was unlawful under the GDPR and that under the existing Temp Spec agreement, the data field of the registrant had already been redacted. In the author’s view, the modification of the WHOIS database has another crucial practical implication since the GDPR came into force, as well as the EPDP on the Temp Spec, which has potentially been influenced by the respective litigation (further emphasized in Chapter 5.9 and proving the second hypothesis). There is, therefore, a definite need for further modifications of other relevant policy agreements – very briefly mentioned in Chapter 2.2.3 - within the domain name registration process, and there is sufficient room for further enhancement of the specific rights of data subjects. Chapter 4.1.5, 4.2.2 and 5.9 illustrate a common ground, in the context of the storage and collection of administrative and technical contact data, between the Compliance Model, the EPDP on the Temp Spec and the litigation ICANN v. EPAG; namely that under the previous practices the continued collection was not necessary, and was therefore unlawful under the GDPR. Nevertheless, the author has identified similarities and differences between significant issues relating to the theoretical Compliance Models, the final report and the litigation ICANN v. EPAG. On 04 March 2019, Phase 1 of the EPDP-charter ended with the GNSO’s approval of the ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’480 (final report), dated 20 February 2019, which was then open for public comments until 17 April 2019. After the public comment period, the ICANN Board must decide whether or not to adopt the report as an ICANN Consensus Policy and implement it before 25 May 2019.481 Phase 2 of the EPDP-charter consists of a set of issues and an ICANN Implementation Review Team (IRT), which is instructed to develop operational and contractual specifications for the policy implementation process. Taking this into account, the contracting parties need to decide whether to follow the Temp Spec or the new ICANN Consensus Policy. This decision needs to be taken between the expiration date of the Temp Spec on 25 May 2019 and the final policy document of the IRT. The main issues are the following:482  Technical standards/ system for access to non-public registration data  Territorial applicability of the GDPR in non-EU areas  Legal entities e. g., legal v. natural persons

480 Cf ICANN GNSO, ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’ (n 250). 481 Cf ICANN, ‘GNSO Council Adopts EPDP Final Report on the Temporary Specification for gTLD Registration Data’ (n 279). 482 Cf Crepin-Leblond, Pritz and Drazek, ‘ICANN, the GDPR and WHOIS’ (n 288). ______Matthias Markus Hudobnik 98 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

 Credentials for access and terms of access e. g., certification v. accreditation483 A reasonable approach to cope with this, is the future issue of standardized access to non- public registration data. ICANN established a so-called Technical Study Group on Access to Non-Public Registration Data (TSG), which is responsible for assessing the current status quo to find potential technical implementation solutions for the verification and permission of third party access to non-public registration data, where there is a legal and legitimate interest.484 On 04 April 2019, the NTIA commented on the EPDP and Phase 2 and highlighted the significance of creating a system which lawfully (e. g., through legitimate interest) allows access and the disclosure of non-public registration data for third parties (e. g., law enforcement, IP rights holders and cyber security researchers) to adequately follow their previous investigations.485 On 22 April 2019, ICANN responded and confirmed the NTIA’s statement and referred to the TSG, who finished a potential Technical Model for Access to Non-Public Registration Data. The model is planned to be shared with the EDPB in order to get further guidance on whether this model minimizes the “legal liability for ICANN gTLD contracted parties who provide access to non-public gTLD registration data.”486 On 17 April 2019, the European Commission (EC) analyzed Phase 1, highlighted the main concept of the GDPR and which elements needed to be fulfilled (e. g., a purpose for the data processing under a specific processing activity related to the specific personal data set) so that the result is a lawful processing of personal data. The EC confirmed the EDPB’s guidelines, regarding how to accurately differentiate between a purpose and a particular processing activity, and expressed their concern in the context of purpose two in Recommendation 1 (further explained in Chapter 4.2.2). In short, they analyzed that this is not the case for this particular purpose. Taking this into account, the differentiation of purposes between the various parties involved (e. g., ICANN, contracted parties) does not hinder or limit the access to non-public registration data by third parties with a legitimate purpose. The EC also stressed Article 6 GDPR, specifically, in terms of legitimate interest as a legal basis for disclosure of personal data to third parties (further developed in Chapter 3.1.4). The EC further underlined that legitimate interest as a legal basis for the processing of personal data, needs to outweigh the interests and fundamental rights of the data subject - as the result of a balancing test done by the data controller - to be compliant with the GDPR. In the author’s view, this means in practice that a registrar, as a potential data controller, may be forced to handle the procedure on a case by case basis. In the future, this may result in delays,

483 Cf ibid. 484 Cf ICANN, ‘ICANN’s Technical Study Group on Access to Non-Public Registration Data’, available at accessed 15 March 2019. Cf also ICANN, ‘RDAP FAQs’, available at accessed 30 April 2019. 485 Cf NTIA Office of Public Affairs, ‘NTIA letter to ICANN regarding WHOIS’, 04 April 2019, 1, available at accessed 30 April 2019. 486 See ICANN, ‘Letter of 04 April 2019 regarding ICANN Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data’, 22 April 2019, pp. 1-2, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 99 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______especially in the context of IP rights holders, where their respective right has to be audited and determined by the respective bodies, and then determined by a case by case balancing test. Thus, this strict and occasional procedure of assessment will also conflict with a potential system of blanked access to personal data. It should be mentioned that the EC advised public authorities such as law enforcement institutions that legitimate purpose is not sufficient as a legal basis to lawfully process personal data. Instead, it is far more lawful to investigate under a legal basis provided by the national law.487 On 24 April 2019, the Governmental Advisory Committee (GAC) highlighted concerns regarding the current requirements in the Temp Spec, and stated that they “are failing to meet the needs of the law enforcement institutions and cyber security investigators.”488 Moreover, the GAC is firmly in favor of a fast implementation process of the recommendations in the final report of Phase 1, and supports their legal review by the EDBP, especially with regard to the purposes stipulated in the final report in order to be compliant with the GDPR. Taking this into account, the GAC finally refers to the GAC Kobe Communiqué Advice489 dated 14 March 2019, and the above-mentioned NTIA letter490 dated 04 April 2019, and recommends that the implementation process of Phase 2 should be careful, substantial and finished within one year or less.491 Further work needs to be done on the Registration Data Access Protocol (RDAP), which is strongly connected to the Technical Study Group on Access to Non-Public Registration Data (TSG) because the implementation of such a technical access-solution is based on the RDAP, which will probably substitute the WHOIS protocol in the future.492 On 30 April 2019, the TSG published the ‘TSG01: Technical Model for Access to Non-Public Registration Data’ with a technical solution summarized by the following four actor models:  Actor Model 1: ICANN as Gateway and Sole Identity Provider and Authorizer  Actor Model 2: ICANN Gateway Using Multiple Identity Providers with ICANN as Sole Authorizer  Actor Model 3: ICANN Gateway Using Multiple Identity Providers with Third-Party Authorizers  Actor Model 4: ICANN as Gateway and Sole Identity Provider with Third-Party Authorizers.493 The TSG further concludes the final report with the following technical solutions:  “Accommodate all of the above-mentioned actor models

487 Cf European Commission, ‘Comments on the Temp Spec for gTLD Registration Data Policy Recommendations’ (n 282) pp. 1-3. Cf also Farzaneh Badii, ‘European Commission Weighs in on the Side of Privacy in WHOIS’, 22 April 2019, available at accessed 30 April 2019. 488 See Manal Ismail, ’Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data’, 24 April 2019, 1, available at accessed 30 April 2019. 489 Cf GAC, ‘GAC Kobe Communiqué Advice’, 14 April 2019, available at accessed 30 April 2019. 490 Cf NTIA Office of Public Affairs, ‘NTIA letter to ICANN regarding WHOIS’ (n 485) 1. 491 Cf Ismail, ‘Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data’ (n 488) 2. 492 Cf ICANN, ‘ICANN’s Technical Study Group on Access to Non-Public Registration Data’ (n 484). 493 Cf Technical Study Group on Access to Non-Public Registration Data, ‘TSG01: Technical Model for Access to Non-Public Registration Data’, 30 April 2019, pp. 19-20, pp. 29-30, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 100 An analysis of the Policy Development Process under the GDPR with a focus on the litigation ICANN v. EPAG ______

 Allow parties claiming legal, legitimate purposes for accessing non-public gTLD registration data to access it in a uniform way  Provide sufficient logging in order to enable auditing  Ensure the integrity of the delivered data  Enable trust in the proposed system by way of regular transparency and performance reports  Require adherence to established, deployed standards, allowing for a design that supports wide interoperability  Exhibit a relatively simple design that enables high availability, redundancy, and scalability  Further assure public trust by identifying procedures for handling deviations from policy or regulation.”494 By March 2015, the IETF had already developed the RFC 7480 for the HTTP usage in the RDAP. Several questions (e. g., standardized access to non-public registration data, the establishment of the RDAP in place of the WHOIS protocol, the estimated costs for ICANN, registry operators and registrars for implementing the changing procedures of the WHOIS system) remain unanswered.495 Finally, the reduction of particular data fields in the public WHOIS database has definitely led to a severe decrease of more than 50% in global e-mail and spam volume, in the last year, based on the figures of Cisco Talos. According to the Anti-Phishing Working Group (APWG), the number of phishing sites has also declined.496 At least the end of 2019 will prove whether the (never-ending) story of the WHOIS modification process will finally come to a successful end. It will also show whether Phase 2 of the EPDP on the Temp Spec finalizes in time, as well as delivering a holistic solution for compliance with the GDPR that is respected by the wide range of stakeholder groups involved.

494 See Technical Study Group, ‘TSG01: Technical Model for Access to Non-Public Registration Data’ (n 493) 30. 495 Cf Andrew Lee Newton, Byron J. Ellacott and Ning Kong, ‘RFC 3912 - HTTP Usage in the Registration Data Access Protocol’, March 2015, available at accessed 30 April 2019. 496 Cf Cisco’s Talos, ‘Total Global Email & Spam Volume for March 2019’, available at accessed 30 April 2019. Cf also CircleID, ‘Phishers Increasingly Targeting SaaS and Webmail Services, APWG Reports’, available at accessed 30 April 2019. ______Matthias Markus Hudobnik 101 Bibliography The sources are considered until 30 April 2019.

Primary Sources

Table of legal frameworks, agreements, resolutions, and recommendations

ICANN  ICANN Board of Directors, ‘Temporary Specification for gTLD Registration Data’, 17 May 2018, 1, available at accessed 30 April 2019.  ICANN Board of Directors, ‘Section 3.3.1.1-8 of the 2013 Registrar Accreditation Agreement’, 27 June 2013, 7, available at accessed 30 April 2019.  ICANN, ‘Section 4.6 (e) of the BYLAWS FOR INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | A California Nonprofit Public-Benefit Corporation’, 18 June 2018, available at accessed 30 April 2019.  ICANN, ‘Section 4.6 (d) of the BYLAWS FOR INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | A California Nonprofit Public-Benefit Corporation’, 18 June 2018, available at accessed 30 April 2019.  ICANN Board of Directors, ‘Thick WHOIS Transition Policy for .COM, .NET and .JOBS’, 01 February 2017, available at accessed 30 April 2019.  ICANN, ‘Specification 2, Part B) lit. 4) of the Registry Agreement’, 31 July 2017, pp. 50- 51, available at accessed 30 April 2019.  ICANN Board of Directors, ‘Retention Specification lit. 1.1) of the 2013 Registrar Accreditation Agreement’, 27 June 2013, 61, available at accessed 30 April 2019.  ICANN Board of Directors, ‘Registration Data Directory Service (WHOIS) Specification of the 2013 Registrar Accreditation Agreement’, 27 June 2013, 51, available at accessed 30 April 2019.

______i  ICANN, ‘Specification 4 lit. 1) of the Registry Agreement’, 31 July 2017, 63, available at accessed 30 April 2019.  ICANN Board of Directors, ‘Section 4.4.1 of the Temporary Specification for gTLD Registration Data’, 17 May 2018, pp. 7-8, available at accessed 30 April 2019.  ICANN Board of Directors, ‘Specification 3.18.2 of the 2013 Registrar Accreditation Agreement’, 27 June 2013, pp. 21-22, available at accessed 30 April 2019.  ICANN, ‘Specification 6 lit. 4.1) of the Registry Agreement’, 31 July 2017, 80, available at accessed 30 April 2019.

EU  Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), available at accessed 30 April 2019.  Charta of Fundamental Rights of the European Union (2000/C 364/01), 18.12.2000, 10, available at accessed 30 April 2019.

Germany  § 242 of the Performance in good faith in the Civil Code, Bürgerliches Gesetzbuch (BGB), available at accessed 30 April 2019.

Table of cases

Germany  Germany: Regional Court of Bonn (Landesgericht LG) 10 O 171/18, 29 May 2018.  Germany: Regional Court of Bonn (Landesgericht LG) 10 O 171/18, 16 July 2018.  Germany: Higher Regional Court of Cologne (Oberlandesgericht OLG) 19 W 32/18, 01 August 2018.  Germany: Higher Regional Court of Cologne (Oberlandesgericht OLG) 19 W 32/18, 03 September 2018.

______ii  Germany: Federal Court of Justice (Bundesgerichtshof BGH), I ZR 150/09, 09 November 2011.

European Court of Justice (ECJ) • Case C-203/15 Tele2 Sverige [2016] (ECJ, 21 December 2016).

Secondary Sources

Books  Hornung G, ‘Räumlicher Anwendungsbereich’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 265-266.  Zerdick T, ‘Räumlicher Anwendungsbereich’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 159-167.  Schumacher P, ‘Scope of application of the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 37-41.  Karg M, ‘Begriffsbestimmung „Personenbezogenes Datum“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 282-293.  Klabunde A, ‘Begriffsbestimmungen’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 172-175.  Rücker D, ‘Scope of application of the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 12-21.  Roßnagel A, ‘Begriffsbestimmung „Verarbeitung“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 298-304.  Petri T, ‘Begriffsbestimmung „Auftragsverarbeiter“’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 330-331.  Heberlein H, ‘Grundsätze für die Verarbeitung personenbezogener Daten’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 192-193.  Dienst S, ‘Lawful processing of personal data in companies under the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 50-53.

______iii  Schanz P, ‘Rechtmäßigkeit der Verarbeitung’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 404-407.  Klement J H, ‘Bedingungen für die Einwilligung’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 555-563.  Heckmann D and Paschke A, ‘Bedingungen für die Einwilligung’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 250-251.  Caspar J, ‘Allgemeines Widerspruchsrecht’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 696-699.  Kamann H-G and Braun M, ‘Widerspruchsrecht’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 446-453.  Schrey J, ‘General conditions for data processing in companies under the GDPR’ in Daniel Rücker and Tobias Kugler, New European General Data Protection Regulation (1st edn, C.H.Beck, Hart, Nomos 2018) pp. 147-149.  Schiedermair S, ‘Europäischer Datenschutzausschuss’ in Spiros Simitis, Gerrit Hornung and Indra Spiecker gen. Döhmann (eds), Datenschutzrecht (1st edn, Nomos 2019) pp. 1157-1161.  Albrecht J P, ‘Europäischer Datenschutzausschuss’ in Eugen Ehmann and Martin Selmayr (eds), Datenschutz-Grundverordnung Kommentar (2st edn, C.H.Beck, LexisNexis 2018) pp. 867-877.  Voigt P and von dem Bussche A, EU-Datenschutz-Grundverordnung (Springer Berlin Heidelberg 2018).

Background papers, research papers, and working papers  ICANN organization, ‘Interim Model for Compliance with ICANN Agreements and Policies in Relation to the European Union’s General Data Protection Regulation – WORKING DRAFT FOR CONTINUED DISCUSSION’, The “Cookbook”, 08 March 2018, 6, available at accessed 30 April 2019.  Sheng S, Piscitello D, Gasster L, ‘Inventory of WHOIS Service Requirements - Final Report’, 29 July 2010, 5, available at accessed 30 April 2019.

______iv  ICANN, ‘WHOIS High-Level Technical Brief’, 20 April 2018, available at accessed 30 April 2019.  Nygren T and Stenbeck P, ‘gTLD Registration Directory Services and the GDPR - Part 1’, Memorandum of Hamilton Advokatbyrå, 16 October 2017, 3, available at accessed 30 April 2019.  Article 29 Data Protection Working Party, ‘Letter from Isabelle Falque-Pierrotin to Cherine Chalaby and Göran Marby regarding GDPR’, 06 December 2017, pp. 1-3, available at accessed 30 April 2019.  European Data Protection Board, ‘Letter from Andrea Jelinek to Göran Marby in reply to his 10 May 2018 letter’, 05 July 2018, pp.- 2-3, available at accessed 30 April 2019.  Rickert T and others, ‘GDPR Domain Industry Playbook’, V. 1.0, Eco Internet Industry Association, 11 January 2018, available at accessed 30 April 2019.  Konings M, ‘Final Report on the Thick Whois Policy Development Process’, 21 October 2013, 3, available at accessed 30 April 2019.  International Working Group on Data Protection in Telecommunications, ‘Working Paper on Privacy and Data Protection Issues with Regard to Registrant data and the WHOIS Directory at ICANN’, 27-28 November 2017, 4, available at accessed 30 April 2019.  Internet Society, ‘Global Internet Report 2019’, 13, available at accessed 30 April 2019.  Technical Study Group on Access to Non-Public Registration Data, ‘TSG01: Technical Model for Access to Non-Public Registration Data’, 30 April 2019, available at accessed 30 April 2019.

______v Genty C, ‘Gouvernance de l’Internet et Économie Mondiale : Proposition d’un Modèle d’Évaluation de la Valeur d’un Nom de Domaine en tant qu’Actif Immatériel’, 23 April 2019, 81, available at accessed 30 April 2019. Websites  ICANN, ‘Welcome to ICANN!’, available at accessed 30 April 2019.  ICANN Archive, ‘ICANN | Archives’, available at accessed 30 April 2019.  ICANN Wiki, ‘ICANN’, available at accessed 30 April 2019.  NTIA Office of Public Affairs, ‘NTIA Announces Intent to Transition Key Internet Domain Name Functions’, available at accessed 30 April 2019.  ICANN Wiki, ‘Internet Assigned Numbers Authority’, available at accessed 30 April 2019.  ICANN Wiki, ‘Regional Internet Registry’, available at accessed 30 April 2019.  ICANN, ‘Stewardship of IANA Functions Transitions to Global Internet Community as Contract with U.S. Government Ends’, available at accessed 30 April 2019.  ICANN WHOIS, ‘WHOIS Search’, available at accessed 30 April 2019.  ICANN WHOIS, ‘Technical Overview’, available at accessed 30 April 2019.  Daigle L, ‘RFC 3912 - WHOIS Protocol Specification’, September 2004, available at accessed 30 April 2019.  ICANN WHOIS, ‘About WHOIS’, available at accessed 30 April 2019.  ICANN WHOIS, ‘WHOIS Primer’, available at accessed 30 April 2019.  ICANN, ‘Data Protection/Privacy Issues’, available at accessed 30 April 2019.

______vi  ICANN, ‘ICANN Board Reaffirms Temporary Specification for gTLD Registration Data’, available at accessed 30 April 2019.  Scientific American, ‘Early sketch of ARPANET’s first four nodes’, available at accessed 30 April 2019.  Verisign, ‘The Verisign Domain Name Industry Brief’, Q1 2019, available at accessed 30 April 2019.  ICANN WHOIS ‘DNS and WHOIS - How it Works’, available at accessed 30 April 2019.  ICANN WHOIS, ‘What are thick and thin entries?’, available at accessed 30 April 2019.  ICANN, ‘Keep Up with EPDP on the Temporary Specification for gTLD Registration Data’, available at accessed 30 April 2019.  ICANN Wiki, ‘Registry Agreement’, available at accessed 30 April 2019.  ICANN WHOIS, ‘Domain Name Registration Process’, available at accessed 30 April 2019.  ICANN, ‘Welcome Registry Operators’, available at accessed 30 April 2019.  ICANN, ‘Information for Registrars’, available at accessed 30 April 2019.  ICANN, ‘Information for Domain Name Registrants’, available at accessed 30 April 2019.  ICANN, ‘About Resellers’, available at accessed 30 April 2019.  ICANN New gTLDs, ‘Registry Data Escrow’, available at accessed 30 April 2019.  ICANN, ‘Registrar Data Escrow Program’, available at accessed 30 April 2019.

______vii  ICANN Wiki, ‘Data Escrow’, available at accessed 30 April 2019.  ICANN, ‘FAQ About Emergency Back-end Registry Operators’, available at accessed 30 April 2019.  Klekovic I, ‘EU GDPR vs. European data protection directive’, Advisera, EUGDPR Academy, 30 October 2017, available at accessed 30 April 2019.  ICANN, ‘Proposed Interim GDPR Compliance Models and Selected Community Input (Working Draft)’, 01 February 2018, available at accessed 30 April 2019.  ICANN, ‘ICANN Board Approves Temporary Specification for gTLD Registration Data’, 17 May 2018, available at accessed 30 April 2019.  ICANN, ‘How to Get Involved: Launch of the EPDP on the Temporary Specification for gTLD Registration Data’, available at accessed 30 April 2019.  ICANN, ‘ICANN v. EPAG Domainservices, GmbH’, 25 May 2018, available at accessed 30 April 2019.  ICANN, ‘ICANN Files Legal Action in Germany to Preserve WHOIS‘, 25 May 2018, available at accessed 30 April 2019.  ICANN, ‘ICANN’s Technical Study Group on Access to Non-Public Registration Data’, available at accessed 30 April 2019.  ICANN, ‘RDAP FAQs’, available at accessed 30 April 2019.  Fibel, ‘ARPANET’, available at accessed 30 April 2019.  Computerhope, ‘ARPANET LOGICAL MAP, March 1977’, available at accesses 30 April 2019.

______viii  Cisco’s Talos, ‘Total Global Email & Spam Volume for March 2019’, available at accessed 30 April 2019.  Wikipedia, ‘Internet Protocol Suite’, available at accessed 30 April 2019.  Nic.at, ‘DNS & DNSSEC’, available at accessed 30 April 2019.  CircleID, ‘Phishers Increasingly Targeting SaaS and Webmail Services, APWG Reports’, available at accessed 30 April 2019.  ICANN, ‘GNSO Council Adopts EPDP Final Report on the Temporary Specification for gTLD Registration Data’, 04 March 2019, available at accessed 30 April 2019.  Wentworth S S, ‘Can We Expand the Multistakeholder Model for Internet Governance? A Feasibility Report’, 27 October 2017, available at accessed 30 April 2019.  DiploFoundation, ‘Multistakeholderism in IGF Language’, available at accessed 30 April 2019.

Other sources and documents  Conrad D, ‘What is Whois’, GAC: Technical Seminar on WHOIS and Data Protection/Privacy Issues, ICANN63 meeting, 21 October 2018, pp. 5-6, available at accessed 30 April 2019.  Harrenstien K and White V, ‘RFC 812 - NICNAME/WHOIS’, 1 March 1982, available at accessed 30 April 2019.  Marby G, ‘What is Whois’, GAC: Technical Seminar on WHOIS and Data Protection/Privacy Issues, ICANN63 meeting, 21 October 2018, 4, available at accessed 30 April 2019.

______ix  European Data Protection Board, ‘THE EUROPEAN DATA PROTECTION BOARD’, Endorsement 1/2018, available at accessed 30 April 2019.  ICANN, ‘Working Draft Non-Paper - Selected Interim GDPR Compliance Models & Comments’, 01 February 2018, available at accessed 30 April 2019.  ICANN, ‘Summary of the Temporary Specification for gTLD Registration Data’, Webinar, Global Domains Division & Contractual Compliance, 06 June 2018, pp. 4-6, available at accessed 30 April 2019.  ICANN, ‘Comparison of Calzone Model and Temporary Specification Requirements’, 17 May 2018, available at accessed 30 April 2019.  ICANN GNSO, ‘Initial Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’, Executive Summary, 21 November 2018, available at accessed 30 April 2019.  GNSO Council, ‘Motion to Approve the Charter for the Temporary Specification for gTLD Registration Data EPDP Team’, 19 July 2018, available at accessed 30 April 2019.  GNSO Council, ‘Expedited Policy Development Process Initiation Request’, 19 July 2018, available at accessed 30 April 2019.  Guhn J, ‘Motion for the issuance of a preliminary injunction’, JONES DAY Rechtsanwälte, 25 May 2018, pp. 1-2, available at accessed 30 April 2019.  Rickert T, ‘EPAG Protective Letter’, Rickert Rechtsanwaltsgesellschaft mbH, 28 May 2018, 5, available at accessed 30 April 2019.

______x  Article 29 Data Protection Working Party, ‘Letter from Peter Schaar to Vinton G. Cerf regarding WHOIS’, 22 June 2006, pp. 1-2, available at accessed 30 April 2019.  Guhn J, ‘Immediate Appeal’, JONES DAY Rechtsanwälte, 13 June 2018, 18, available at accessed 30 April 2019.  Rickert T, ‘EPAG’s Comment’s on ICANN’s Immediate Appeal’, Rickert Rechtsanwaltsgesellschaft mbH, 10 July 2018, 2, available at accessed 30 April 2019.  Guhn J, ‘Supplemental Submission’, JONES DAY Rechtsanwälte, 27 July 2018, 2, available at accessed 30 April 2019.  Rickert T, ‘EPAG’s Comments on ICANN’s Supplemental Submission’, Rickert Rechtsanwaltsgesellschaft mbH, 01 August 2018, 1, available at accessed 30 April 2019.  Guhn J, ‘Plea of Remonstrance’, JONES DAY Rechtsanwälte, 17 August 2018, pp. 1-2, available at accessed 30 April 2019.  Rickert T, ‘EPAG’s Comments on ICANN’s Plea of Remonstrance’, Rickert Rechtsanwaltsgesellschaft mbH, 30 August 2018, 2, available at accessed 30 April 2019.  ICANN GNSO, ‘Final Report of the Temporary Specification for gTLD Registration Data Expedited Policy Development Process’, 20 February 2019, available at accessed 30 April 2019.  Crepin-Leblond O, Pritz K and Drazek K, ‘ICANN, the GDPR and WHOIS’, Notes of Nigel Hickson, WSIS Forum, 11 April 2019, available at accessed 30 April 2019.

______xi  ICANN, ‘Panel on ICANN and Data Privacy issuess’, Cross-Community Discussion with Data Protection Commissioners, ICANN58 meeting, 13 March 2017, available at accessed 30 April 2019.  Mueller M, ‘Whois Reform, at Last’, 05 March 2019, available at accessed 30 April 2019.  Harrenstien K, Feinler J E and Stahl M, ‘RFC 954 - NICNAME/WHOIS’, October 1985, available at accessed 30 April 2019.  Newton L A, Ellacott J B and Kong N, ‘RFC 3912 - HTTP Usage in the Registration Data Access Protocol’, March 2015, available at accessed 30 April 2019.  NTIA Office of Public Affairs, ‘NTIA letter to ICANN regarding WHOIS’, 04 April 2019, 1, available at accessed 30 April 2019.  ICANN, ‘Letter of 04 April 2019 regarding ICANN Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data’, 22 April 2019, pp. 1-2, available at accessed 30 April 2019.  European Commission, ‘Comments on the Temporary Specification for gTLD Registration Data Policy Recommendations’, 17 April 2019, pp. 1-5, available at accessed 30 April 2019.  Badii F, ‘European Commission Weighs in on the Side of Privacy in WHOIS’, 22 April 2019, available at accessed 30 April 2019.  Ismail M, ‘Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data’, 24 April 2019, pp. 1-2, available at accessed 30 April 2019.  GAC, ‘GAC Kobe Communiqué Advice’, 14 April 2019, available at accessed 30 April 2019.

______xii