<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">All,<br><br>I have been preoccupied for several weeks with a non-trivial computer and operating system migration and&nbsp;a variety of other interruptions. &nbsp;Real life has a way of intruding upon the most well-meaning of&nbsp;intentions.<br><br>I want to repeat that I am a member of the ICANN Board of Directors, but that the opinions I express here&nbsp;are &nbsp;strictly my own, and not necessarily consistent with any of the organizations with which I am&nbsp;affiliated.<div><br></div><div><br></div><div><b><u>Mailing list or web site thread?</u></b><br><br>If there is sufficient interest, I�d like to propose a discussion of possible solutions to what is often&nbsp;referred to as the IANA issue that I introduced several weeks ago, &nbsp; Since then, the 1net web site has&nbsp;developed to the point of containing threads for separate discussions, and eventually this discussion &nbsp;� &nbsp;if it continues &nbsp;� &nbsp;should be housed there. &nbsp;On the other hand, I�ve been&nbsp;told that there are a lot of people on the list who use it as a window into Internet governance&nbsp;discussions, and who are more likely to want the list messages pushed out to them than to have to actively&nbsp;log onto a web site to follow specific threads. &nbsp;For the moment I�m going to finesse this problem and&nbsp;post to both, hoping that an equally useful non-duplicative solution will become available in the future. &nbsp;Opinions are welcome.&nbsp;<br><br>Here is where I think the discussion was:</div><div><br></div><div><br><b><u>Problem statement no. 1 (version 6)</u></b><br><br>Several suggestions have been made to further refine the problem statement, &nbsp;I'm including them,&nbsp;but I'm bracketing them so that you can easily see what has been proposed. &nbsp;If there is no pushback&nbsp;on the changes, I'll remove the brackets and adjust the text properly a couple of versions later.<br><br>1. The Internet Assigned Names and Numbers Authority (IANA) has as one of its functions the&nbsp;[vetting] [administration] of [changes] [change requests] in the Internet root zone file. &nbsp;The members&nbsp;of the team that performs the IANA functions are employed by ICANN, the Internet Corporation for&nbsp;Assigned Names and Numbers.<br><br>2. ICANN has a zero-cost contract with the US government to perform the IANA functions. [The US&nbsp;government authorizes changes made to the root zone by verifying that ICANN abides by publicly&nbsp;documented policies prior to the changes being submitted for implementation.[ &nbsp;["After IANA verifies&nbsp;that ICANN has conformed to publicly documented review policies, the US government authorizes&nbsp;that changes be made to the root zone.]<br><br>3. It has been a requirement for the contractor providing the IANA function to be a US organization,&nbsp;resulting in the provision of the IANA function being subject to US law and the decisions of the US&nbsp;judiciary.<br><br>4. Objections have been raised to US government involvement in this process on several grounds,&nbsp;including exclusivity and concerns of trust. Objections have equally been raised to movement of the&nbsp;function to several international organizations.<br><br>5. Acceptable solutions for assignment of the IANA root zone function should meet several criteria:&nbsp;(1) protection of the root zone from political or other improper interference; (2) integrity, stability,&nbsp;continuity, security and robustness of the administration of the root zone; (3) widespread&nbsp;[international] trust by Internet users in the administration of this function; (4) support of a single&nbsp;unified root zone; and (5) agreement regarding an accountability mechanism for this function that is&nbsp;broadly accepted as being in the global public interest.&nbsp;<br><br>6. A number of potential solutions have been proposed; however, there has been no consensus that&nbsp;any of them are broadly acceptable.</div><div><br></div><div><br><b><u>What I believe that we are not discussing</u></b><br><br>The IANA function is really three functions, and concerns the administration of (1) Internet protocol&nbsp;parameters, (2) &nbsp;the IP address space, and (3) the root zone file. &nbsp;I believe that the major focus of the&nbsp;discussion should be on the root zone file, with possible interest in the IP address space. &nbsp;Both&nbsp;are important for Internet navigation. &nbsp;The administration of Internet protocol parameters is an&nbsp;administrative function performed for the IETF, and I believe that controversy, if any, over this function,&nbsp;is insignificant compared to the other functions.<br><br>The IANA functions are currently performed by ICANN under contract to the US government, so that&nbsp;discussing changes to the location, governance regime and operational functions that comprise IANA&nbsp;are intimately linked with changes to the location, governance regime and operational functions of&nbsp;ICANN. &nbsp;Now there is of course an option that removes the IANA functions from ICANN and&nbsp;establishes them elsewhere, and some suggestions in this direction have been made by several&nbsp;governments.&nbsp;&nbsp;<br><br>My sense is that (1) in the short run, and perhaps for a very long time, such a transfer of control&nbsp;would not be capable of meeting the conditions of at least requirement 5 above, and (2) would be politically&nbsp;unacceptable to the great majority of the actors in the Internet ecosystem. &nbsp;I�m therefore going to&nbsp;assume that any acceptable solution retains the IANA function within ICANN, and we really need to&nbsp;focus upon future possibilities for ICANN as a whole. &nbsp;&nbsp;<br><br><br><b><u>A first rough cut into the &nbsp;solution space</u></b><br><br>Earlier, I think it was Milton Mueller who wrote that there were three approaches to alternative&nbsp;arrangements for ICANN: (1) a pure multilateral approach, (2) a multistakeholder approach, and (3)&nbsp;an approach that does not include governments. &nbsp;(Milton will correct me if I have misrepresented his&nbsp;views)<br><br>The pure multilateral approach is a descendant of regulatory regimes for PTTs of the 19th and first&nbsp;half of the 20th century. I believe that it is accepted opinion now that &nbsp;they have been shown to be inefficient, non-innovative,&nbsp;financially inefficient, and exclusionary. &nbsp;Pressure for such an approach is weak and is politically&nbsp;unacceptable. &nbsp;I believe that we can discard it.<br><br>The third approach is in my view equally unrealistic. &nbsp;Governments are a part of our world. &nbsp;They&nbsp;have useful and essential functions &nbsp;We depend upon the creation and evolution of legal structures&nbsp;along with the administrative and judicial mechanisms that institutes and implement them. &nbsp;We may be&nbsp;concerned with their inappropriate use of power, but we can�t deny that they have a place at the&nbsp;table. &nbsp;We are likely, however, to differ about what that place is and what limitations might be put&nbsp;upon them.<br><br>The second approach, one based upon multistakeholderism, seems like the only viable and&nbsp;significantly acceptable one. &nbsp;While that choice may be comforting in terms of its inclusive&nbsp;orientation, the space of solutions that could be called multistakeholder is vast and multidimensional,&nbsp;with the only necessary condition for being in the set is that all relevant stakeholder groups, however&nbsp;defined, have some degree of inclusion into the process and that no one group has an absolute veto&nbsp;over the activities of the group. &nbsp;Distributions of power, representation, and decision making authority all vary,&nbsp;possibly enormously among stakeholder groups. &nbsp;The very choice of what groups are included and&nbsp;who they include contributes to the diversity among solutions. &nbsp;(For example, while ICANN correctly claims to be&nbsp;organized according to a multistakeholder model, in fact it is organized in accordance with a very&nbsp;specific and well-defined instantiation of the multistakeholder model.)<br><br>So if we are going to talk about multi-stakeholder approaches to the problem, we will need to&nbsp;differentiate between a variety of them that might be suggested. &nbsp;Saying that an approach is a multi-stakeholder approach is not sufficient; it will need to be characterized in a more definite manner.<br><br>Finally, any approach that will be successful must make the great majority of us comfortable with its&nbsp;ability to maintain security, stability, and independence of the Internet�s fundamental naming and addressing&nbsp;systems, and with its ability to withstand takeover by any special interests. &nbsp;Governments, including&nbsp;the US government, must be an integral part of that majority if any transition is to be feasible and&nbsp;ultimately successful. &nbsp;Solutions that do not meet this criterion, and are not demonstrably better than&nbsp;what we have now, should not and will not be adopted.<br><br><br><b><u>Incremental approaches</u></b><br><br>Assuming that there are continuity and stability virtues in minimizing the amount of change that is&nbsp;made, I ask myself: are there acceptable solutions to the problem that minimize the account of&nbsp;change needed? &nbsp;In which direction would they go? &nbsp;I personally don�t have a good answer for that.&nbsp;&nbsp;Perhaps others do.<br><br><br><b><u>Diplomatic approaches, from Jovan Kurbalija</u></b><br><br>In a recent provocative article, &nbsp;Jovan Kurbalija has outlined a number of scenarios that find their&nbsp;rationale in established diplomatic behavior. &nbsp;The article, at:<br><br><span class="Apple-tab-span" style="white-space:pre">                </span><a href="http://www.diplomacy.edu/blog/international-inviolability-root-zone">http://www.diplomacy.edu/blog/international-inviolability-root-zone</a><br><br>contains the following scenarios. &nbsp;I include them here because I think they represent serious&nbsp;approaches to the issue we�re discussing. &nbsp;They may or may not be practical.<br><br><blockquote type="cite">USE DIPLOMATIC LAW APPROACH TO SOLVE THE POLICY PROBLEM OF THE ROOT ZONE<br><br>The predominantly symbolic relevance of the root zone issue has created the basis for an analogy&nbsp;with diplomatic law, which deals with another highly symbolic issue: representation &nbsp;of countries. It&nbsp;includes diplomatic precedence, the protection of diplomatic buildings, and the main functions of&nbsp;representation.[3]&nbsp;How can the regulation of symbolic aspects of diplomatic relations help in&nbsp;regulating the symbolic aspects of Internet politics? Here are two possibilities:<br><br>The first possibility could be described as&nbsp;a �physical� one, making the server and root database&nbsp;inviolable, in particular from any national jurisdiction. This possibility opens the question of where&nbsp;the root server will be located. &nbsp;It could be located at the UN premises in New York and Geneva,&nbsp;which would simplify matters, since those entities already enjoy inviolability, including immunity&nbsp;from any national jurisdiction. Another option, such as continuing to use the current location would&nbsp;require changes in the US national law, in order to ensure international inviolability of the root&nbsp;database. &nbsp;One could also consider assigning root zone file immunity as part of an ICANN+&nbsp;arrangement (making ICANN a quasi-international organisation � discussed further down in the&nbsp;text).&nbsp;[4]<br><br>The second possibility, which is&nbsp;a �virtual� one: the root database should be assigned inviolabilityper&nbsp;se, wherever it is located. This solution is based on the analogy with diplomatic law which specifies&nbsp;that �[t]he archives and documents of the mission shall be inviolable at any time and wherever they&nbsp;may be.� (i.e. article 24 of the Vienna Convention on Diplomatic &nbsp;Relations).<br><br>In this way, the root database can enjoy inviolability according to international law. Neither the USA,&nbsp;&nbsp;nor any other authority, can interfere with the root database without necessary authorization. This&nbsp;could be the first phase in the policy process, which could build trust, and prepare for the second&nbsp;phase, which has to deal with the more difficult question:<br><br>WHO WILL HAVE THE RIGHT TO AMEND THE ROOT DATABASE?<br><br>Here we get back to the question of decision-making process and &nbsp;the status of ICANN. This has&nbsp;been exhaustively discussed, and it is clear that a workable solution should be based on a high&nbsp;level of inclusion, transparency, and checks and balances. As a practical solution for the root zone&nbsp;file, one could think of a double key system, involving a strengthened ICANN, with a stronger role&nbsp;for the GAC (to some extent codifying and formalizing what has been happening through the&nbsp;growing relevance of the GAC). A possible role for a reformed UN Trusteeship council could also&nbsp;be considered, as one of the actors in this checks and balances system.<br><br>ICANN�s new quasi-international status, for example, following Swiss laws, could address most of&nbsp;the above-mentioned points. Shifting ICANN from the national to the international level, would&nbsp;require ensuring ICANN�s accountability towards consumers, users, and the Internet industry.&nbsp;Immunity should not be impunity. &nbsp;Again, here we could have a solution through the interplay&nbsp;between international public law and private law options.<br><br>HOW TO ACHIEVE THE NEW ROOT ZONE ARRANGEMENT?<br><br>The closest analogy is the governance of the Red Cross system. Analogous to the Geneva&nbsp;conventions in the humanitarian field, �a root convention� would minimally grant immunity to the root&nbsp;database, and maximally specify how the root database would be managed. If the adoption of a&nbsp;root zone file convention would be too complex, one could consider an advisory opinion of the&nbsp;International Court of Justice, which could recognize the �instant� customary law (practice of the US&nbsp;government of not interfering in countries' domain names without the consent of these countries).&nbsp;Either a convention or instant customary law would provide a functional basis for ICANN, which&nbsp;could be a quasi-international organisation, with a carefully balanced checks and balances&nbsp;approach, and a prominent role for the GAC. Such an ICANN+ would both host the root server, and&nbsp;manage the root database.<br><br>There are some other solutions and possibilities. The bottom line is that there&nbsp;is&nbsp;a solution that&nbsp;could be both practical and legal. The symbolic issue of the root zone, at least, could be put to rest,&nbsp;and allow us to spend �policy energy� on more practical and relevant issues. It could be also be a&nbsp;reasonable compromise.<br></blockquote><div><br></div><br><b><u>Conclusion</u></b><br><br>It�s quite possible that all of the above is a product of too limited thinking, and that an alternative,&nbsp;more comprehensive and high level approach looking at the entire Internet ecosystem as a whole&nbsp;might be more fruitful. &nbsp;If so, what might such an approach be based upon, and why might it look&nbsp;like? &nbsp;Perhaps on further reflection, and considering possible approaches to it, we may find that the&nbsp;problem definition is lacking, and needs modification or amplification. &nbsp;If so, that represented profess&nbsp;of a certain kind.<br><br>I present the above as my thoughts regarding possible approaches, with a large contribution from&nbsp;Jovan. &nbsp;I admit to not having good answers to the problem, but I hope that the above material is helpful to starting a serious discussion. &nbsp;If there is any appetite on the list to continue this discussion, I, and possibly others, would be interested in your&nbsp;comments.<br><br>Regards,<br><br>George<br><br><br><br></div></body></html>