[discuss] Possible approaches to solving "problem no. 1"

[George Sadowsky]

All,

I have been preoccupied for several weeks with a non-trivial computer and operating system migration and a variety of other interruptions.  Real life has a way of intruding upon the most well-meaning of intentions.

I want to repeat that I am a member of the ICANN Board of Directors, but that the opinions I express here are  strictly my own, and not necessarily consistent with any of the organizations with which I am affiliated.


Mailing list or web site thread?

If there is sufficient interest, I’d like to propose a discussion of possible solutions to what is often referred to as the IANA issue that I introduced several weeks ago,   Since then, the 1net web site has developed to the point of containing threads for separate discussions, and eventually this discussion  —  if it continues  —  should be housed there.  On the other hand, I’ve been told that there are a lot of people on the list who use it as a window into Internet governance discussions, and who are more likely to want the list messages pushed out to them than to have to actively log onto a web site to follow specific threads.  For the moment I’m going to finesse this problem and post to both, hoping that an equally useful non-duplicative solution will become available in the future.  Opinions are welcome. 

Here is where I think the discussion was:


Problem statement no. 1 (version 6)

Several suggestions have been made to further refine the problem statement,  I'm including them, but I'm bracketing them so that you can easily see what has been proposed.  If there is no pushback on the changes, I'll remove the brackets and adjust the text properly a couple of versions later.

1. The Internet Assigned Names and Numbers Authority (IANA) has as one of its functions the [vetting] [administration] of [changes] [change requests] in the Internet root zone file.  The members of the team that performs the IANA functions are employed by ICANN, the Internet Corporation for Assigned Names and Numbers.

2. ICANN has a zero-cost contract with the US government to perform the IANA functions. [The US government authorizes changes made to the root zone by verifying that ICANN abides by publicly documented policies prior to the changes being submitted for implementation.[  ["After IANA verifies that ICANN has conformed to publicly documented review policies, the US government authorizes that changes be made to the root zone.]

3. It has been a requirement for the contractor providing the IANA function to be a US organization, resulting in the provision of the IANA function being subject to US law and the decisions of the US judiciary.

4. Objections have been raised to US government involvement in this process on several grounds, including exclusivity and concerns of trust. Objections have equally been raised to movement of the function to several international organizations.

5. Acceptable solutions for assignment of the IANA root zone function should meet several criteria: (1) protection of the root zone from political or other improper interference; (2) integrity, stability, continuity, security and robustness of the administration of the root zone; (3) widespread [international] trust by Internet users in the administration of this function; (4) support of a single unified root zone; and (5) agreement regarding an accountability mechanism for this function that is broadly accepted as being in the global public interest. 

6. A number of potential solutions have been proposed; however, there has been no consensus that any of them are broadly acceptable.


What I believe that we are not discussing

The IANA function is really three functions, and concerns the administration of (1) Internet protocol parameters, (2)  the IP address space, and (3) the root zone file.  I believe that the major focus of the discussion should be on the root zone file, with possible interest in the IP address space.  Both are important for Internet navigation.  The administration of Internet protocol parameters is an administrative function performed for the IETF, and I believe that controversy, if any, over this function, is insignificant compared to the other functions.

The IANA functions are currently performed by ICANN under contract to the US government, so that discussing changes to the location, governance regime and operational functions that comprise IANA are intimately linked with changes to the location, governance regime and operational functions of ICANN.  Now there is of course an option that removes the IANA functions from ICANN and establishes them elsewhere, and some suggestions in this direction have been made by several governments.  

My sense is that (1) in the short run, and perhaps for a very long time, such a transfer of control would not be capable of meeting the conditions of at least requirement 5 above, and (2) would be politically unacceptable to the great majority of the actors in the Internet ecosystem.  I’m therefore going to assume that any acceptable solution retains the IANA function within ICANN, and we really need to focus upon future possibilities for ICANN as a whole.   


A first rough cut into the  solution space

Earlier, I think it was Milton Mueller who wrote that there were three approaches to alternative arrangements for ICANN: (1) a pure multilateral approach, (2) a multistakeholder approach, and (3) an approach that does not include governments.  (Milton will correct me if I have misrepresented his views)

The pure multilateral approach is a descendant of regulatory regimes for PTTs of the 19th and first half of the 20th century. I believe that it is accepted opinion now that  they have been shown to be inefficient, non-innovative, financially inefficient, and exclusionary.  Pressure for such an approach is weak and is politically unacceptable.  I believe that we can discard it.

The third approach is in my view equally unrealistic.  Governments are a part of our world.  They have useful and essential functions  We depend upon the creation and evolution of legal structures along with the administrative and judicial mechanisms that institutes and implement them.  We may be concerned with their inappropriate use of power, but we can’t deny that they have a place at the table.  We are likely, however, to differ about what that place is and what limitations might be put upon them.

The second approach, one based upon multistakeholderism, seems like the only viable and significantly acceptable one.  While that choice may be comforting in terms of its inclusive orientation, the space of solutions that could be called multistakeholder is vast and multidimensional, with the only necessary condition for being in the set is that all relevant stakeholder groups, however defined, have some degree of inclusion into the process and that no one group has an absolute veto over the activities of the group.  Distributions of power, representation, and decision making authority all vary, possibly enormously among stakeholder groups.  The very choice of what groups are included and who they include contributes to the diversity among solutions.  (For example, while ICANN correctly claims to be organized according to a multistakeholder model, in fact it is organized in accordance with a very specific and well-defined instantiation of the multistakeholder model.)

So if we are going to talk about multi-stakeholder approaches to the problem, we will need to differentiate between a variety of them that might be suggested.  Saying that an approach is a multi-stakeholder approach is not sufficient; it will need to be characterized in a more definite manner.

Finally, any approach that will be successful must make the great majority of us comfortable with its ability to maintain security, stability, and independence of the Internet’s fundamental naming and addressing systems, and with its ability to withstand takeover by any special interests.  Governments, including the US government, must be an integral part of that majority if any transition is to be feasible and ultimately successful.  Solutions that do not meet this criterion, and are not demonstrably better than what we have now, should not and will not be adopted.


Incremental approaches

Assuming that there are continuity and stability virtues in minimizing the amount of change that is made, I ask myself: are there acceptable solutions to the problem that minimize the account of change needed?  In which direction would they go?  I personally don’t have a good answer for that.  Perhaps others do.


Diplomatic approaches, from Jovan Kurbalija

In a recent provocative article,  Jovan Kurbalija has outlined a number of scenarios that find their rationale in established diplomatic behavior.  The article, at:

		http://www.diplomacy.edu/blog/international-inviolability-root-zone

contains the following scenarios.  I include them here because I think they represent serious approaches to the issue we’re discussing.  They may or may not be practical.

> USE DIPLOMATIC LAW APPROACH TO SOLVE THE POLICY PROBLEM OF THE ROOT ZONE
> 
> The predominantly symbolic relevance of the root zone issue has created the basis for an analogy with diplomatic law, which deals with another highly symbolic issue: representation  of countries. It includes diplomatic precedence, the protection of diplomatic buildings, and the main functions of representation.[3] How can the regulation of symbolic aspects of diplomatic relations help in regulating the symbolic aspects of Internet politics? Here are two possibilities:
> 
> The first possibility could be described as a ‘physical’ one, making the server and root database inviolable, in particular from any national jurisdiction. This possibility opens the question of where the root server will be located.  It could be located at the UN premises in New York and Geneva, which would simplify matters, since those entities already enjoy inviolability, including immunity from any national jurisdiction. Another option, such as continuing to use the current location would require changes in the US national law, in order to ensure international inviolability of the root database.  One could also consider assigning root zone file immunity as part of an ICANN+ arrangement (making ICANN a quasi-international organisation – discussed further down in the text). [4]
> 
> The second possibility, which is a ‘virtual’ one: the root database should be assigned inviolabilityper se, wherever it is located. This solution is based on the analogy with diplomatic law which specifies that ‘[t]he archives and documents of the mission shall be inviolable at any time and wherever they may be.’ (i.e. article 24 of the Vienna Convention on Diplomatic  Relations).
> 
> In this way, the root database can enjoy inviolability according to international law. Neither the USA,  nor any other authority, can interfere with the root database without necessary authorization. This could be the first phase in the policy process, which could build trust, and prepare for the second phase, which has to deal with the more difficult question:
> 
> WHO WILL HAVE THE RIGHT TO AMEND THE ROOT DATABASE?
> 
> Here we get back to the question of decision-making process and  the status of ICANN. This has been exhaustively discussed, and it is clear that a workable solution should be based on a high level of inclusion, transparency, and checks and balances. As a practical solution for the root zone file, one could think of a double key system, involving a strengthened ICANN, with a stronger role for the GAC (to some extent codifying and formalizing what has been happening through the growing relevance of the GAC). A possible role for a reformed UN Trusteeship council could also be considered, as one of the actors in this checks and balances system.
> 
> ICANN’s new quasi-international status, for example, following Swiss laws, could address most of the above-mentioned points. Shifting ICANN from the national to the international level, would require ensuring ICANN’s accountability towards consumers, users, and the Internet industry. Immunity should not be impunity.  Again, here we could have a solution through the interplay between international public law and private law options.
> 
> HOW TO ACHIEVE THE NEW ROOT ZONE ARRANGEMENT?
> 
> The closest analogy is the governance of the Red Cross system. Analogous to the Geneva conventions in the humanitarian field, ‘a root convention’ would minimally grant immunity to the root database, and maximally specify how the root database would be managed. If the adoption of a root zone file convention would be too complex, one could consider an advisory opinion of the International Court of Justice, which could recognize the ‘instant’ customary law (practice of the US government of not interfering in countries' domain names without the consent of these countries). Either a convention or instant customary law would provide a functional basis for ICANN, which could be a quasi-international organisation, with a carefully balanced checks and balances approach, and a prominent role for the GAC. Such an ICANN+ would both host the root server, and manage the root database.
> 
> There are some other solutions and possibilities. The bottom line is that there is a solution that could be both practical and legal. The symbolic issue of the root zone, at least, could be put to rest, and allow us to spend ‘policy energy’ on more practical and relevant issues. It could be also be a reasonable compromise.


Conclusion

It’s quite possible that all of the above is a product of too limited thinking, and that an alternative, more comprehensive and high level approach looking at the entire Internet ecosystem as a whole might be more fruitful.  If so, what might such an approach be based upon, and why might it look like?  Perhaps on further reflection, and considering possible approaches to it, we may find that the problem definition is lacking, and needs modification or amplification.  If so, that represented profess of a certain kind.

I present the above as my thoughts regarding possible approaches, with a large contribution from Jovan.  I admit to not having good answers to the problem, but I hope that the above material is helpful to starting a serious discussion.  If there is any appetite on the list to continue this discussion, I, and possibly others, would be interested in your comments.

Regards,

George



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140209/b200a859/attachment-0001.html>