INDIAN PERSPECTIVE ON THE IANA STEWARDSHIP TRANSITION

Transcription

1 A STUDY ON THE INDIAN PERSPECTIVE ON THE IANA STEWARDSHIP TRANSITION Supported by: Conducted by CCAOI

2 ACKNOWLEDGEMENTS This report was made possible through the help and generous support from many stakeholders of internet governance India. We wish to especially acknowledge the contributions and assistance of Dr. Govind, CEO- National Internet Exchange of India, ex-senior Director Department of Electronics and Information Technology; Mr. K.B. Narayanan, Advisor, National Internet Exchange of India, Mr. Rajesh Chharia, President Internet Service Providers Association of India, the entire National Internet Exchange of India team, for providing support and encouragement, without which this study would have been impossible. We are grateful for the valuable inputs, cooperation, important perspectives and support provided, Mr. Sunil Abraham, Executive Director, Centre for Internet and Society, India; Mr. Rishabh Bailey Vice President,Free Software Movement of India; Ms. Pallavi Bedi and Mr. Chaitanya Ramachandran, Associate, Amarchand & Mangaldas & Suresh A.Shroff & Co.; Mr.Thanglura.Darlong, Joint Secretary, Counter Terrorism Policy Planning & Research, Ministry of External Affairs; Mr. Samiran Gupta, Head of India, Internet Corporation for Assigned Names and Numbers; Dr. Rekha Jain, Executive Chair, IIMA-IDEA Telecom Centre of Excellence; Dr. Ajay Kumar, Joint Secretary, Department of Electronics and Information Technology; Mr. Sivasubramanian Muthusamy, President, ISOC Chennai Chapter; Mr. Ram Narain, Deputy Director General,Security & Access Services-II, Department of Telecommunication; Mr. Parminder Singh, Executive Director, IT for Change; Mr. Arun Mohan Sukumar, Senior Fellow, Centre for Communication Governance; Mr. Vikram Tiwathia, Associate Director General, Cellular Operators Association of India; CCAOI Confidential Report, 21 st March 2015 Page 3

3 CONTENTS INTRODUCTION...5 METHODOLOGY...13 STRENGTH AND WEAKNESS IN THE CURRENT EXECUTION OF IANA FUNCTIONS...14 AN OVERVIEW OF PROPOSALS FOR THE IANA TRANSITION...18 SUMMARY OF FEEDBACK FROM INDIAN STAKEHOLDERS...29 DISCUSSIONS AND RECOMMENDATIONS...47 ANNEXURE...53 ABBREVIATIONS...53 KEY INTERNET GOVERNANCE ORGANIZATIONS...54 MEMBERS OF IANA STEWARDSHIP TRANSITION COORDINATION GROUP (ICG)...66 QUESTIONNAIRE...68 ABOUT CCAOI...73 CCAOI Confidential Report, 21 st March 2015 Page 4

4 INTRODUCTION Each device connected over the internet is assigned a unique numeric address called Internet Protocol number (IP) by which it can be identified. Since IP numbers (like ) are difficult to remember, for easy recall, they are assigned a corresponding distinct domain name (like Domain names are alphanumeric strings, divided into sections and organized from right to left with each level separated by dots. In a domain name (like the Top level domain name is the right most portion of the domain name (i.e.,".com") and is the highest level of the domain name, the specific description to its left (i.e., "google") is called the Second-Level Domain, while the machine name ( i.e., www ) is at the extreme left. DNS has three types of top level domain names, namely, Generic Top Level Domain Name (gtld), Country code Top Level Domain Name (cctld) and Sponsored Top Level Domain Name (stld). Generic Top Level Domain Name (gtld) normally has three or more characters such as.com,.net,.org, etc. and are managed by a Registry (like Verisign in the case of.com). The two letter domain names representing countries are called Country code Top Level Domain Name (cctld). For example, the.in is the cctld for India. There are some specialized gtlds representing a specific community such as.aero,.cat,.coop,.jobs,.mobi, are called Sponsored Top Level Domain Name (stld). The new gtld policy allows an entity to register a TLD with a name of their choice such as.tata or.airtel. Also, with more and more non English users being added, having non- English domain names such as Chinese, Arabic, Devnagri (Indian) scripts is possible under Internationalized Domain names (IDNs). One such IDN available in India is. (.Bharat). Domain Name System In order to ensure that each networked device gets the requested information correctly, the records of all IP addresses and their corresponding domain names are managed and maintained by a directory called the Domain name system (DNS). On receiving a domain name request (like the DNS translates this information into the right IP address (like ), so that the requested information (the Google webpage) can be correctly provided to the requestor. The DNS is fundamentally a shared name space having root servers (name servers) that implement the name space; and resolvers (or caching servers) in the middle, connected to end systems that send queries about the name space to the name servers. At the top of the DNS tree sits the root zone, which is implemented in the root servers (or name servers) for users. The DNS is hierarchical in nature, allowing parts of the name space to be distributed and delegated to other authoritative name servers in the Internet. It also has caching servers (or DNS resolvers) that cache responses from authoritative servers, on receiving queries from their client end systems. The hierarchal nature and use of resolvers have helped in the growth and scalability of internet. CCAOI Confidential Report, 21 st March 2015 Page 5

5 The DNS name space database has been divided into zones and each zone is served by one or more name servers which are synchronized to contain identical sets of data. The zones are hierarchically organized like an inverted tree, zones containing DNS information belonging to the corresponding name domains in the tree. The root zone constitutes the top of the inverted tree (level 0) and its name is an empty string (not root ) denoted with a single. (period or dot ). The DNS data in a zone are usually stored in the zone file and servers through the process called zone transfer synchronize the contents of the master server (the server at which changes to the zone in question are entered) with slave servers. Example of how the DNS works Fig: Domain Name System Hierarchy 1 When a query for a website like is sent by a networked device, it is sent to one of the caching servers which keeps a list of root servers and their addresses. In case the cache is newly installed and has no prior information, it will ask the root server. The root server in turn will answer with a referral containing the list of all servers for com. The caching server will then send the request to one of the authoritative servers and get the information on 'google.com'. The next time any one sends a query for the address to the caching server can itself answer the request without consulting any server. In case the caching server 1 CCAOI Confidential Report, 21 st March 2015 Page 6

6 receives a query for anything.google.com, it will send the query directly to the google.com server and send any question for another name ending in.com directly to a server s authoritative for com. In case the query is different example for.org and it had previously not received any such query, it will ask the root server. In this way the cache will contain lists of authoritative servers for all popular domains, especially for all popular TLDs. This design ensures that only a tiny fraction of all queries will have to be processed by the root servers or by authoritative servers for TLDs. Root Servers Figure: How DNS works 2 The DNS name servers (also called root name servers or root servers) carry and serve data from the root zone. There are 13 publicly accessible root servers, denoted by the letters A through M. Each server carries DNS hostnames in the form <letter>.root-servers.net (for example, a.root-servers.net). The root servers are updated by a distinct distribution master (also referred as the "hidden master") which is not visible in the DNS system and is operated by root zone administrator. To minimize the errors and attacks during updates, validation of digital signatures and error checking are in place between the distribution master and the respective slave systems. 2 An Introduction to Internet Governance, By Jovan Kurbalija, CCAOI Confidential Report, 21 st March 2015 Page 7

7 Out of the 13 root servers, 10 are located in the USA and one each in Sweden, the Netherlands, and Japan. The locations of the root servers were initially determined based on the network traffic flow and load analysis. However, with time, it was felt that the locations of the root servers were limited and it was important to have root servers distributed for providing a sufficient level of service to all users across the network. As a result, several satellite sites having copies of the root servers have been deployed by using a method called Anycast. Due to these deployments, the load balancing, and multiprocessing, through which a root server can comprise multiple processors; the number of computers at each root-server address has effectively increased. Root Zone File The Root zone file is a public file, containing the list of all the TLDs - their names and corresponding set of resource records that build up the pointer structures leading the clients onwards and downwards in the DNS hierarchy. Thus a TLD will only be visible to public in the internet if it is listed in the root zone. The actual and current root zone file is used by all the root server operators. However, the root server operators do not have the power to make any change in the file, as the right to modify or update and then publish the contents in the root zone database rests with the root zone management authority. As the root zone is the first level of the DNS system, listing all the public TLD s, it is very important from a network and political standpoint. For smooth operations/working of internet and the DNS, it is critical that the information stored and distributed by the root zone file is accurate and correct; the root servers are secure, efficient and reliable. Even the smallest error such as entering incorrect domain name or IP address in the root zone file will result in incorrect information. Also, if the error is updated in all copies of the root zone file, access would effectively be denied to all domain names in that TLD. Root Zone Management Process As the root domain and its corresponding zone is critical for the operation of DNS, the management of the root zone process is very important. Functions such as deciding what entries (new/revised) to be included in the root zone file, creating, updating and distributing the root zone file to all of the root name servers, selecting the locations and the operators of the root name servers; and establishing and continually and reliably operating the root name servers is very important. The Internet Assigned Numbers Authority (IANA) During the initial days of internet, for managing and distribution of IPs and top-level domains, the Internet Assigned Numbers Authority (IANA) was set up and was administered by the Information Sciences Institute (ISI) at the University of Southern California (USC) under a contract with the US Department of Defense. However, the task was performed by an individual, Jon Postel. CCAOI Confidential Report, 21 st March 2015 Page 8

8 However with time, the IANA activities have grown and, today, can be broadly classified into three categories: Management of Domain names including information contained in the DNS root, the.int and.arpa domains, and an IDN practices resource Coordinating Number resources by managing the global IP pool and AS numbers and providing them to Regional Internet Registries (RIRs). Autonomous system (AS) is a collection of connected Internet Protocol (IP) routing policies for one or more network operators that are controlled by a common administrator on behalf of a single administrative entity. AS are assigned a unique global number called Autonomous System Number (ASN) that are assigned in blocks to RIRs by IANA, who then assign them within their designated areas. Managing internet Protocol codes in conjunction with standards bodies. Since 2008, the IANA is operated by ICANN under a contract from the U.S. Department of Commerce and a Memorandum of Understanding (MOU) with the Internet Engineering Task Force (IETF). The agreement has been extended twice. The existing contract would be expiring in September Organisations and their roles DNS Root Zone Management There are various organisations involved in the DNS root zone management process. These include: ICANN, a California incorporated not for profit body managing the IANA operations, under a contract from the U.S. Department of Commerce since Extended twice, the existing contract would be expiring in September 2015; The National Telecommunications and Information Agency (NTIA) of the U.S. Governments, Department of Commerce, responsible for reviewing and approving function that authorizes any change to the root zone; Commercial entity VeriSign who is contracted by NTIA (Cooperative Agreement No. NCR ) to perform the role of root zone administrator; And an informal group comprising of commercial, non commercial and governmental root server operators. CCAOI Confidential Report, 21 st March 2015 Page 9

9 Figure: Root Zone Management Players 3 Out of the ten root servers in U.S., three are with the U.S. government (National Aeronautics and Space Administration (NASA), Department of Defense (DoD), and the U.S.Army), two are operated by universities (University of Maryland and University of Southern California), two by corporations (VeriSign, Inc. and Cogent Communications), and two are run by notfor-profits (Internet Systems Consortium, Inc. (ISC) and Internet Corporation for Assigned Names and Numbers (ICANN)). The root server in Sweden is operated by a not for profit corporation (Autonomica AB), the one in Netherlands by a co-operative body (The RIPE Network Coordination Centre of European Internet Service Providers), and the one in Japan by academics (WIDE Project). Coordination of Global Number Resources As a part of the IANA function, ICANN is responsible for allocating blocks of IPs, from the pool of unallocated IPs to the 5 Regional Internet Registries (RIRs) spread across the globe, in accordance with global Internet number policies. The RIR's in turn distribute IP numbers to the local Internet registries (LIRs) and national Internet registries (RIRs), who in turn distribute IP numbers to smaller ISPs, companies, and individuals further down the ladder... for example, if someone wants an IP address in India, they can purchase it from an Indian ISP (like Airtel), who in turn might purchase it from the National Internet registry of India (called IRINN), who in turn gets the same from RIR (called Asia Pacific Network Information Centre (APNIC)), who in turn gets it from ICANN. Since each RIR represents a geographical area, they have their own processes and interests, that is why single body called Number Resource Organization (NRO) has been set up for coordinating between them and ICANN. Each RIR appoints 2 members through their regional policy forums, and another member comes from each RIR's executive board and they constitute the ASO Address Council (ASO AC). The Address Supporting Organization (ASO) is one of three ICANN Supporting Organizations, whose main objective is to review and develop Internet Protocol recommendations, address policy, and advise the ICANN Board 4. Under an agreement between ICANN and NRO called The ICANN Address Supporting Organization (ASO) 3 Scaling the Root, CCAOI Confidential Report, 21 st March 2015 Page 10

10 MoU 5, NRO is to liaise with ICANN about Internet number resources on behalf of the RIRs 6. Growth in internet users has led to a shortage of IP addresses, since the 32 bit IPv4 address space offered only around 4 billion unique address options. This led to the introduction of the 128 bit IPv6 version, allowing huge numbers of unique IP addresses. Today, both the versions of IPs, IPv4 and IPv6. are operational and need to be managed. Management of Protocols To ensure that each requestor on the internet gets the correct information, all networked devices need to follow the same set of rules or protocol parameters and the commonly used protocol is Transmission Control Protocol/Internet Protocol (TCP/IP). The TCP/IP ensures that messages can pass between two hosts, back and forth over a period of time. Currently the Internet Engineering Task Force (IETF), under MoU with ICANN (MoU RFC2860), is responsible for setting TCP/IP standards and managing internet standards processes. The type of oversight, policy formulation and process of implementation and maintenance is important. The management group of IETF is called the Internet Engineering Steering Group (IESG).The Internet Architecture Board (IAB), a committee of IETF and also an advisory body in ISOC, is responsible for providing architectural oversight of IETF activities. It also provides Internet Standards Process oversight and appeal, and the appointment of the RFC Editor. The IAB is also responsible for the management of the IETF protocol parameter registries. The Internet Society (ISOC), a non-profit organization, is the home to IETF and IAB. The World Wide Web Consortium (W3C) is an international community working to develop Web standards. Current Status National Telecommunications and Information Administration (NTIA), an agency of the US government, which supervises the IANA functions through a contract, plans to relinquish its oversight. It announced in March , its intention of shifting key Internet domain name functions to the global multistakeholder community when the IANA contact expires in September 30, NTIA has mandated ICANN to coordinate a process for interested stakeholders to develop a transition proposal. It wants that the proposal must: support and enhance the multistakeholder model NTIA Announces Intent to Transition Key Internet Domain Name Functions, March 14th, 2014, CCAOI Confidential Report, 21 st March 2015 Page 11

11 maintain the security, stability, and resiliency of the Internet DNS meet the needs and expectations of the global customers and partners of the IANA services, and maintain the openness of the Internet. Crucially, the NTIA has also made it clear that it will not accept a proposal that replaces the NTIA role with a government-led or an inter-governmental organization solution. It is important to underline that The NTIA declaration 8 called for a transition of NTIA stewardship over IANA functions and not for transition of IANA functions. As the effects of the domain name functions have a far reaching impact on communities both connected or unconnected to the internet, the transition process has gained immense interest of governments, business houses, academics, civil societies, etc. The discussion on the transition, addressing the concerns pertaining to the existing DNS process, has enlarged to the accountability of ICANN as well. 8 CCAOI Confidential Report, 21 st March 2015 Page 12

12 METHODOLOGY CCAOI staff conducted this study under the guidance of Dr. Mahesh Uppal a telecom and internet consultant. Ms. Amrita Choudhury led the research effort from CCAOI. The aim of this study is to identify the issues related to the NTIA stewardship transition from the IANA operations, the different strains of thoughts, along with their convergence and divergence, review the central issues from India perspective after extensive consultation with stakeholders, highlighting their importance and make recommendations on what should be the most appropriate position for India The study was conducted over a period of three months. It involved: Identifying and studying the relevant issues from secondary data. In-depth study of key issues through study and critique of relevant secondary data. Interviews with key players and experts based on fine-tuned questionnaires, and interviews. The questionnaire, list of people sent the questionnaire or interview invite are provided in the annexure. Attending workshops and round tables of experts and stakeholders from civil societies, government, academics, corporate, students, users, etc. Validation and consolidation of results. This study has limitations. It is time bound, and relies on secondary sources and oftenunstructured interviews. It must be distinguished from rigorous and exhaustive academic or legal research. The report quotes freely from existing documents. We have made every effort to attribute sources as far as possible. We do not imply that the quotes refer to the official positions of those quoted or their organizations. We accept responsibility for any errors in this report. We propose, as a next step, to do an in-depth study on the subject of accountability of the IANA operator and their impact on different stakeholder groups in India. CCAOI Confidential Report, 21 st March 2015 Page 13

13 STRENGTH AND WEAKNESS IN THE CURRENT EXECUTION OF IANA FUNCTIONS The execution of IANA functions has been frequently lauded for its professionalism and speed. Others have expressed their concerns on issues such as equity. This section highlights some of these views below: ICANN as an Organization Many, e.g. ISOC 9 considers the self regulatory model of internet and the role played by ICANN in coordinating certain aspects of the collaborative internet model, a strength, Operationally, ICANN is known 10 to be well positioned in managing the IANA function. The organization has also been delivering, 11 basis its role as per its IANA contract. Lawrence Strickling 12, Assistant Secretary for Communications and Information and Administrator of the National Telecommunications and Information Administration (NTIA) under the U.S. Department of Commerce (DOC), argued in 2011 that ICANN s achievements include introduction of 27 Internationalized country code top level domain names (IDN cctlds), the implementation of a review team process as stipulated in the Affirmation and the effort made by the ICANN Board and the Governmental Advisory Committee (GAC) to work together to increase the number of generic top level domain names (gtlds). ICANN has frequently faced criticism for its policymaking role and for deriving excessive profits from its functions 13. Senator Wyden 14 raised ethical concerns about senior ICANN controversially moving to and from industry and conflicts of interest in the IANA function. Strickling shared concern 15 over some of ICANN's decisions to remove the cross-ownership restriction and the Board s decision to reverse its commitment to conduct further economic studies regarding the impact of new gtlds. Root server System ISOC believes that the existing single root server system reduces the risk that some governments might misuse the DNS for censorship. This minimizes chances of fragmentation of the internet [discuss] The NTIA/ICANN transitioning Process, By Seun Ojedeji, 29th March 2014, discuss@1net.org 11 [discuss] The NTIA/ICANN transitioning Process, By Seun Ojedeji, 29th March 2014, discuss@1net.org Milton Mueller book on Nations and internet CCAOI Confidential Report, 21 st March 2015 Page 14

14 There is concern that the existing root server process provides the US government the power to make unilateral changes in the entire DNS. Louis Pouzin, believes that in the current single root server system there are chances of misuse of data by a single country vis a vis creating multiple roots. 17 Root Server Model The non-hierarchical distributed arrangements within the root name server system, and the diversity of software, hardware and operational procedures used by each of the servers, are key elements that contribute to a stable and secure root system. ISOC believes that this distributed and redundant root server model as operated by a dozen independent organizations provides maximum stability and security. They therefore see no benefit in centralizing management of the root name server operators. 18 The current agreement between NTIA and ICANN obliges the latter to seek operational authority over the DNS root name server system. This is done through formal arrangements with root name server operators. ISOC 19 is concerned, as they fear that it will eventually introduce risks in times to come. Oversight There is almost a universal concern 20 regarding the unilateral oversight of U.S. government on how ICANN operates administratively. Such a system is believed 21 to restrict ICANN from fully serving the global ICANN community. Role of Governments ISOC is concerned over the increasing role of governments in ICANN than what is necessary for the security and stability of internet. 22. Others have argued that its role in functions e.g. gtlds and cctlds cannot be carried out without significant role for governments. Names and Accountability of ICANN Accountability of ICANN, Milton Mueller suggests, is a concern for most cctlds and gtlds. 23 He further adds that as gtld s are under contractual license with ICANN, the latter has the authority to levy expensive and burdensome contractual obligations on registries and ICANN s powers need to be limited [discuss] The NTIA/ICANN transitioning Process, By Seun Ojedeji, 29th March 2014, discuss@1net.org 21 [discuss] The NTIA/ICANN transitioning Process, By Seun Ojedeji, 29th March 2014, discuss@1net.org Cauldron part2: Is the names IANA compatible with the others? By Milton Mueller, 19th Oct 2014, 24 Cauldron part2: Is the names IANA compatible with the others? By Milton Mueller, 19 th Oct 2014, CCAOI Confidential Report, 21 st March 2015 Page 15

15 David Johnson expresses concern 25 that there may be abuse of IANA function (using the power over the root zone to impose top down rules) if ICANN staff imposes rules on new gtld registries, in the absence of consensus. Further stating various legal issues are cropping up due to the new gtld policy and that ICANN may need a police force, an anti-trust enforcer, or a general purpose internet governance body. 26 Jovan Kurbalija 27 shares, the new gtld process also faces concern due to cultural, geographic and linguistic issues. For example,.amazon request, which had been submitted by online retailer Amazon was stopped amidst strong criticism from the Latin American countries, represented in ICANN's Government Advisory Committee (GAC). There is a similar concern with the application of.wine/.vin. There are concerns how ICANN would manage collision between non-dns domain names and real domain names (such as.onion,.local etc.). 28 Also, as any organization can apply for a new gtld registry, there are concerns 29 w.r.t protection of trademarks and increasing cases of cyber squatting in the new gtld process. According to Mueller 30, since cctld s only rely on ICANN for updating their data on the global root zone, there are concerns on how ICANN handles re-delegation requests, as cctlds would not want ICANN to have any more centralized power over them. Human Rights Council of Europe 31 raises concerns relating to human rights and the right to freedom of expressions while deciding new gtlds. They fear a balance between economic interests and other objectives of common interest, such as pluralism, cultural and linguistic diversity is not being maintained. Rebalancing of human rights and the right to private life pertaining to processing and retention of data and public access to personal data in the WHOIS database is also one of their concerns. 32 Number Related Developing countries have concerns 33 on how ICANN allocates IP blocks. In the early days when IPs were allocated on first come first basis, nearly 80% of the existing IPs were 25 David Johnson, 24 th March 2014, An introduction to Internet Governance, By Jovan Kurbalija ark+issues+the+trademark+clearinghouse+can+help 30 Cauldron part2: Is the names IANA compatible with the others? By Milton Mueller, 19th Oct 2014, 31 Council of Europe 's Report: ICANN s procedures and policies in the light of human rights, fundamental freedoms and democratic values, 32 Council of Europe 's Report: ICANN s procedures and policies in the light of human rights, fundamental freedoms and democratic values, CCAOI Confidential Report, 21 st March 2015 Page 16

16 allocated in North America. Currently, when the IPs are allocated to RIR's based on demonstrable need, there are still concerns that inequality persist in the allocation process. While the demand for IPs is still higher for developed countries, in a few years, the requirement for IPs would be more from areas which are still not connected and lesser developed. Current IP allocation and management process should ensure that numbers are uniquely and uniformly available across the globe, without any regional or community biases. The creation and management of orderly secondary IPv4 market is seen as a controversial issue in the RIR space. According to David Conrad, CTO ICANN 34 this issue is too big for RIRs to manage independently. According to Mueller, 35 regarding the approach taken by RIR s in formulating a proposal, while it seems to be a bottom-up approach, however the whole process is under the tight control of the RIRs secretariats. Each RIR has their own processes and interests and lack sufficient interest in formulating any process. Mueller 36 is concerned over the slow decision making and the multiple steps involved. Thus, decision making once at regional level and then at global level, duplicates work. He also believes, the current numbers regime is imperfectly integrated with the ICANN regime. NRO is neither truly incorporated entity and lacks any global oversight or appeals mechanism, 37 He is concerned that RIR s and ICANN share a very informal relationship. 38 Protocol Mueller expresses concerns 39 over the relationship between ICANN and IETF (RFC2860) stating that firstly, as this relationship is based on a MoU, it is not considered a formal contract. Secondly, the status of IETF as a principal in the IANA contract should be strengthened in order to have a balanced relationship, which would also make ICANN more accountable. Just Net Coalition 40 is concerned that the Internet technical standards system does not have any overarching public oversight and is dominated by US and global business interests The cauldron begins to bubble: Update on the IANA, By Milton Mueller, Dated Oct 12, 2014, 36 The cauldron begins to bubble: Update on the IANA, By Milton Mueller, Dated Oct 12, 2014, 37 The cauldron begins to bubble: Update on the IANA, By Milton Mueller, Dated Oct 12, 2014, 38 The cauldron begins to bubble: Update on the IANA, By Milton Mueller, Dated Oct 12, 2014, 39 The cauldron begins to bubble: Update on the IANA, By Milton Mueller, Dated Oct 12, 2014, 40 Governing the global Internet is the status quo the only option? 28th Oct, 2014, CCAOI Confidential Report, 21 st March 2015 Page 17

17 AN OVERVIEW OF PROPOSALS FOR THE IANA TRANSITION As mentioned in the introduction, the NTIA announced 41 in March 2014, its intent to transition key Internet domain name functions to the global multistakeholder community. It entrusted ICANN with the responsibility to convene stakeholders to develop a transition plan to replace the NTIA role in the IANA functions. Soon after, ICANN initiated a discussion process and called for public inputs to develop a transition process. The feedbacks also referred to the necessity of ensuring accountability of ICANN in reference to the transition. The IANA Stewardship Transition coordinating group (ICG) was set up with responsibility of preparing the transition proposals. It asked the "operational communities" of IANA to undertake consultations and recommend a transition proposal. The final proposal was to be developed on broad consensus. It would be based on proposals prepared by the Names, Numbers and Protocol communities, with subsequent comments from the larger community. A Cross-Community Working group (CWG) was set up to develop the proposals on Naming Related Functions. The protocol and number communities, viz The Internet Engineering Task Force ( IETF) working group called IANA PLAN and Consolidated RIR IANA Stewardship Proposal Team ( CRISP), were operational and have submitted their final proposals 4243 to ICG. The IETF proposal argues that no new organisation or structures are required since the current system has been working well. The CRISP team similarly recommends continuing with ICANN as IANA Functions Operator for the numbering services. The CWG is yet to submit their final proposal and community members are discussing various options. Moreover, they would depend on the CCWG- Accountability team s proposal on improving ICANN accountability. CWG in the initial draft proposal 44 recommends that ICANN should continue managing naming functions post the IANA stewardship transition. It proposes the separation of ICANN as a policy body from the IANA Functions Operator. It also suggests putting in place ICANN accountability mechanisms and other improvements, before the actual transition. The proposal includes replacement of NTIA oversight by creating four structures: Cross Community Working Group (CWG) on Naming Related Functions Draft Transition Proposal, Refer Summary of the transition proposal, 1 st December, 2014, Link: 01-en CCAOI Confidential Report, 21 st March 2015 Page 18

18 Contract Co.- a non profit body which would contract with ICANN to carry out the IANA function; Multistakeholder Review Team (MRT)- comprising of selected representatives from the community; Customer Standing Committee (CSC) having representatives from all communities and individuals; and an Independent Appeals Panel (IAP). Subsequently based on inputs received on the draft proposal, a discussion document 45 was released which discusses two types of transition models viz. the External to ICANN (Contract Co, and External Trust) and the Internal to ICANN (Internal Bylaw and Internal Trust) models. The internal to ICANN model envisages that ICANN permanently manage the IANA functions on the basis of undergoing reforms developed by the CCWG on accountability to provide checks on the ICANN board and detail a process to remove the IANA functions if needed. The external to ICANN model on the other hand proposes to create a shell Contract Co which will replace NTIA and will enter into a contract with the IANA functions operator viz. ICANN. The Contract Co. will be guided by MRT. Both the models however include mechanisms to ensure that the IANA functions can be separated from ICANN through the intervention of the above-mentioned MRT, and CSC and IAP. A Hybrid Proposal is also currently being discussed, 46 by the CWG naming community. In this model, post the transition, the ICANN IANA functions will be transferred to Post Transition IANA (PTI) and a community board comprising of representatives from the three communities will oversee the PTI operations. This model proposes- in lieu of MRT- a PTI board having representatives from RIRs and IETF. The IAP and CSC of the earlier model remains while CSC ensures that the SLA/MoU between ICANN and Post Transition IANA are met. This model adds no new architectural considerations. There are three variations of this model, which are being debated:- Hybrid ICANN subsidiary model- IETF and RIR have increased accountability and seats on community board, oversight by all operational communities at the operational level. Hybrid shared services arrangement between ICANN, IETF and RIR: Here each of the communities has shared community oversight, to make the structure less susceptible to capture. There is separation between policy development and policy 45 Cross Community Working Group (CWG) To Develop An IANA Stewardship Proposal On Naming Related Functions Discussion Document for ICANN52 Singapore February 2015, Link: Final.pdf?version=1&modificationDate= &api=v CCAOI Confidential Report, 21 st March 2015 Page 19

19 implementation; all three parties must agree for substantive changes in PTI governance. Figure: ICANN Subsidiary Model 47 Figure: Shared Services Arrangement model 48 Free standing model: Here, ICANN, RIRs and IETF have separate agreements with PTIA and have equal accountability. This is intended to create a higher degree of separation between policy development and implementation CCAOI Confidential Report, 21 st March 2015 Page 20

20 Figure: Free Standing model 49 Analysis of the models being discussed at CWG Currently the proposals being debated by the CWG naming community include the internal model, trust model (where a trust would be created in place of Contract Co. to enter into contract for managing the IANA functions), external model, hybrid ICANN subsidiary model, hybrid shared services arrangement model and free standing model. The policy-making community in all the proposals remain unchanged (ICANN, RIRs, IETF). However, the models differ in terms of the contracting organizations. The internal-to-icann proposal envisages contracts with existing bodies like RIRs and IETF while the internal trust model suggests a board of Trustees, however it is still unclear on specifics of its Board of Trustees its composition, selection process etc. The external-to-icann model suggests contracts with Contract Co. RIRs and IETF, The three hybrid models suggest contracts with GNSO, ccnso; RIRs and IETF. Similarities and differences amongst the different proposals being discussed by CWG Community: IANA operator: IANA department is the operator, in the internal, trust and external models. While the IANA department is operationally separated in the hybrid subsidiary model, it is functionally separated in the hybrid shared services arrangement while structurally separated in the freestanding model. IANA Functions: While ICANN is proposed to manage the IANA functions in the internal, trust as external model, the hybrid models propose IANA (termed as Post Transition IANA) to manage it CCAOI Confidential Report, 21 st March 2015 Page 21

21 Jurisdiction: It is still unclear of the hybrid models, the other models propose jurisdiction under Californian law. Structure of the entity: All the models except the free standing model propose a non-profit structure. Ownership: The internal and external models do not address ownership. However, in the hybrid subsidiary model, it will be with ICANN and in hybrid shared model, it will be Partially-owned by contracting organization. IETF in its proposal 50 to ICG on the IANA protocol parameters registries, suggests continuing with the same organisations/or structures post the stewardship change of NTIA. It points out, however, that, in absence of the NTIA contract, new arrangements may be needed to realize the IETF community's expectations. The CRISP team, of the Internet Number Community, in their proposal 51 to ICG, suggests that ICANN could continue as the IANA functions operator for the numbering services post signing a new agreement with the five RIRs and be referred as the IANA Numbering services operator. Any IPR related to the IANA services would remain with the community. CRISP team suggests establishing a service level agreement with IANA numbering services operator. It also proposes setting up a review committee, with representatives from all RIRs. Such a committee would appraise the Executive Council of the Number Resource Organisation 52 (NRO) on the IANA functions operator s performance and meeting of identified service levels. In their proposal the number community suggest that the IANA trademark and IANA.org should be transferred to an independent entity prior to the transition. However the protocol community has not suggested anything of that nature. Post evaluating the proposals of the number and protocol community, the ICG sought clarification 53 from both on the issue of IANA trademark and iana.org domain name. It has asked if the proposals could be modified and reconciled. The number community has responded 54 to ICG stating that they do not observe any incompatibilities between the two proposals. Their proposal does not regard it as mandatory to transfer the trademark and domain of iana.org to IETF trust or any other specific entity and the protocol proposal does not explicitly oppose it NRO is Number Resource Organization which coordinates between RIRs and ICANN. 53 : Alissa Cooper on behalf of the ICG, IANA Stewardship Transition Coordination Group Responds to Submitted Proposals, 9th February 2015, Link: Re: [NRO-IANAXFER] Question from the ICG, from Izumi Okutani on behalf of the CRISP Team to ICG, February 21st, 2015 CCAOI Confidential Report, 21 st March 2015 Page 22

22 The initial community feedback reiterated the need of improving the transparency and accountability of ICANN before the transition. ICANN then published a proposed process on Enhancing ICANN Accountability. 55, Based on community feedback, originally ICANN had proposed two groups on Accountability and Governance. 56 However, it was later modified 57 into a single Cross Community Working Group (CCWG) with two work steams. The first one is responsible for drafting a mechanism for enhancing ICANN accountability, which must be in place before the IANA stewardship transition. The other is addressing accountability topics for which a timeline may extend beyond the IANA Stewardship Transition. Work is currently underway on the same. The CCWG Accountability group is deliberating on a wide array of corporate governance changes to make ICANN, especially its policy making process more accountable. These include, changes in the bylaws, restricting ICANNs mission and scope, improving the appeals mechanism, etc. However, the timelines for approving and implementing these changes are yet to be decided. However, for any change to be implemented, it needs the approval of ICANN board. Figure: A high-level overview of the IANA Stewardship Transition and Enhancing ICANN Accountability Processes CCAOI Confidential Report, 21 st March 2015 Page 23

23 The community members proposed several alternative proposals and approaches for the IANA transition. For example: Internet Governance Project (IGP) 59 suggests the following underlying principles for the transition, o separating the root zone file modification from policy-making, o not internationalizing political oversight, o aligning incentives to ensure the accuracy and security of root zone maintenance, and o de-linking IANA globalization from broader ICANN reforms. IGP proposes, creating a new entity, DNS Authority (DNSA), to manage the IANA functions related to the DNS root zone and associated databases, moving IANA functions related to protocol parameters to the IETF and retaining IP address-related functions with ICANN. The DNSA would be a non-profit body, with no policy authority, controlled by a consortium of TLD registries and root server operators. It would have a contract with ICANN. The proposal also calls for MoU between multiple principles, ICANN & DNSA. Just Net Coalition (JNC) suggests 60 dividing the IANA functions such that: IETF secretariat manage the protocol parameters, NRO manage the IP addresses, a new entity (which could be a Swiss non- profit association) having members from the gtld and cctld community, manage the root zone file management, ICANN manage the gtlds while ICANN or new entity manages the cctlds. Association for Proper Internet Governance supports 61 a proposal of the International Ad Hoc Committee (IAHC) (a bottom up multistakeholder group which ISOC and others sponsored for discussions) for a Memorandum of Understanding (MoU) that would allow for the creation of an organisation called INROOTS Which will be a non-profit intergovernmental treaty based organization, Where private sector will manage technical and operational matters, Governments will provide supervisory function, 59 Roadmap for globalizing IANA: Four principles and a proposal for reform, By Milton L Mueller, 60 Just Net Coalition: Comments on the IANA transition and ICANN accountability [Revised] (July 2014); 61 Roadmaps for further evolution of Internet governance, By: Richard Hill, rnance.pdf CCAOI Confidential Report, 21 st March 2015 Page 24

24 Civil society will be able to provide inputs to government or INROOTS, Will preferably outsource root server management to ICANN, The policy decisions for number will be managed by RIRs, with IAB & IETF in liaison with ITU-T. InternetNZ 62 offers the diagrammatic representation below of the existing IANA functions, organisations managing the functions, to facilitate discussion on what aspects is not part of the transition and share the wide range of solutions available for the institutional aspect of the new settlement. Figure Diagrammatic representation of Proposed ICANN model by InternetNZ 62 ICANN/IANA:'Role'and'Structural'Considerations, March 24th, 2014, CCAOI Confidential Report, 21 st March 2015 Page 25

25 Figure Diagrammatic representation of Proposed IGP model by InternetNZ Figure Diagrammatic representation of new oversight entity and structural separation by InternetNZ CCAOI Confidential Report, 21 st March 2015 Page 26

26 Figure Diagrammatic representation of new policy entity and structural separation by InternetNZ Figure: Diagrammatic representation of new policy entity(2) & structural separation by InternetNZ CCAOI Confidential Report, 21 st March 2015 Page 27

27 Figure Diagrammatic representation of multiple policy entities and structural separation by InternetNZ The diagram highlights: The ICANN proposal to SO/AC chair (ICANN to manage the IANA operations and oversight); The IGP proposal, mentioned above; Option to create a new oversight entity (ICANN to manage the policy formulations and RIRs, IETF the protocols and a second entity the Root Zone management and IANA functions); Option of a new policy entity (i) with structural separation (having ICANN oversight, new entity to manage the policy formulations(common to all gtld contacts and policies), RIRs and cctlds; IETF the protocols and second entity the Root Zone management and IANA functions); Option of new policy entity (2) with structural separation (oversight by ICANN, new entity to manage the policy formulation (common to all gtld contacts and policies), RIRs and cctld and two entities within the RIRs for addressing local issues and global issues respectively); Option for multiple policy entities and structural separation (ICANN to manage oversight, new entity to manage policy formulation common to all gtld contacts and policies, RIRs and cctlds to each have two entities one for setting and managing local issues and the other global and a separate entity to manage the RZM and IANA functions CCAOI Confidential Report, 21 st March 2015 Page 28