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

Patrik Fältström paf at frobbit.se
Fri Feb 14 17:08:16 UTC 2014


I must say I do not think we really can get into more details on
"problem no. 1" unless we define what we mean by "IANA root zone
function" because I see many different things IANA does. To make it
simple, they "add", "remove" and "update" information related to TLDs,
and maybe each one of the operations are such that they do need
different oversight?

For example, I think related to the "update" operation, the registry for
whatever the TLD the update is about is the authoritative source, and I
have no idea what, why or who should intervene in such an operation.

Regarding "add" and "remove" we have maybe other constraints, where
specifically "remove" is a very very destructive operation.

   Patrik

On 2014-02-13 15:20, Ian Peter wrote:
> George,
>  
> I must admit I was hoping for more than an interesting discussion here.
> I think we have been talking about this for well over a decade.
>  
> I think we would achieve broad consensus here for Option 3 – which is
> internalisation of the previous IANA processes within ICANN. That itself
> would be quite a milestone and a first achievement for 1net.
>  
> I also think that that direction would be supported by the EU  – it is
> multistakeholder – and by many other governments. I also think that USA
> which often indicates its support for multistakeholder would, under the
> weight of such a multistakholder consensus, eventually feel it necessary
> to support this direction.
>  
> If we could get to Brazil with a clear forward direction, I believe
> there is a strong chance that Brazil could actually have a useful
> outcome – acceptance of a direction for solution of the IANA oversight
> issue. That would be a good achievement.
>  
> So if we wanted to try and achieve that, I wouldn’t try to arrive at any
> firm solution as regards GAC involvement at this stage. Indeed, I would
> try to throw a statement of direction and principles back at ICANN to
> figure out the details. Yes, as you say, the devil is in the details, so
> I would leave the devil locked up there for a while until we get a clear
> consensus and agreement on a direction. And also discussions on the role
> of GAC would best involve GAC so are not so useful here.
>  
> Starting from the recent EU declaration, we would need to include
> security, stability and a timeframe. And I think your (5) below is a
> good start for a brief.
>  
> “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.”
>  
> I would like to see us aim towards a request, perhaps for adoption in
> Brazil, for ICANN to produce an internalised solution meeting the
> criteria in (5) (and any others we might like to add) with a timeframe .
> I would suggest IGF this September would be good for a report to be
> developed further. I could see implementation in that case within 12 months.
>  
> Then we are left with one related question – internationalisation of
> ICANN. But again the options here have been discussed for some time. But
> perhaps our consensus request could also ask ICANN (with a timeframe) to
> present a solution to this.
>  
> Ian Peter
>  
> PS I would also suggest that ICANN utilise an outside independent
> consultancy based outside of the USA to conduct this study and consult
> all stakeholders and prepare the directions paper, in the interests of
> expediency and efficiency.
>  
>  
> *From:* George Sadowsky <mailto:george.sadowsky at gmail.com>
> *Sent:* Friday, February 14, 2014 3:30 AM
> *To:* Milton L Mueller <mailto:mueller at syr.edu> ; mailto:discuss at 1net.org
> *Subject:* Re: [discuss] Possible approaches to solving "problem no. 1"
>  
> Milton,
>  
> Thanks for bringing up your original writing.  I looked for it in my own
> archives, couldn’t find it, and so depended upon memory.  That’s not
> always a good option for an aging brain.  I apologize for misstating
> your position.
>  
> I don’t think I’m avoiding coming to grips with any differences.  I’m
> glad that you were able to sharpen the options as you’ve done below.  My
> comments were an attempt to describe and delineate the space of possible
> solutions, and you have helped to do that.
>  
> I am not trying to discredit the denationalization option.  It’s clear
> that the GAC will stay. However, under your #3 option, will the GAC have
> any say whatsoever in any IANA (or son of IANA, or new-name) decisions
> regarding the root zone file, and if so, under what terms?  The devil is
> in such details.  
>  
> Milton, you may have thought I was waffling because I was just
> describing and delineating what I regarded as the space of
> alternatives.  I wasn’t waffling; I was trying to invoke discussion of
> those alternatives.  I can tell you that:
>  
> A. I am personally in favor of option 3, and have been for some time.
>  
> B. Given the current structure of ICANN, including the GAC, it will be
> really important to get any revised denationalized (your words)
> structure defined well with respect to the new interrelationships.
>  
> Others, however, may disagree, and I did not want to push the
> discussion, at that point in time, toward my own preferences.
>  
> Oh the other hand, so far most of the comments seem to favor option #3,
> so perhaps it’s worth concentrating some discussion on it.  I am not a
> lawyer, but it’s clear to me (assuming that IANA stays coupled to ICANN)
> that ICANN’s legal status changes.  Are there anti-trust or
> competitiveness law implications?  My guess is that there surely are,
> and from multiple countries.
>  
> What legal structure should such a born-again ICANN take.  Here’s where
> I was hoping that Jovan’s text below would be interesting to discuss; so
> far, no one has picked that up.  If #3 is the correct path to take, i.e.
> if we know where we want to go. and we know where we are now, what are
> the feasible paths that could get us there?    I refer back to item 5 in
> the problem statement.  It is not going to go away:
>  
>> 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. 
>  
> So, where do we go from here?  Milton, since you are clearly also in
> favor of this option, perhaps you would describe for us your proposed
> structure of the post-transition organizations and relationships between
> them, in sufficient detail to address the various conflicts and dangers
> that might arise, and what paths we might choose to arrive there.  That
> could be a basis for interesting further discussion on this list.
>  
> George
>  
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  
> On Feb 12, 2014, at 4:47 PM, Milton L Mueller <mueller at syr.edu
> <mailto:mueller at syr.edu>> wrote:
> 
>>  
>>
>> George. You did not quite get the 3 options right. They were:
>>
>> <!--[if !supportLists]-->1)      <!--[endif]-->Unilateral control by 1
>> govt (the status quo)
>>
>> <!--[if !supportLists]-->2)      <!--[endif]-->Multilateral control
>>
>> <!--[if !supportLists]-->3)      <!--[endif]-->De-nationalization of
>> the IANA function; ie., removal of USG control and delegation of it to
>> ICANN. Note well: this does NOT require exclusion of governments from
>> all involvement in ICANN.
>>
>>  
>>
>> What you propose as a solution, “one based upon multistkeholderism,”
>> is actually an attempt to avoid coming to grips with difference
>> between #2 and #3. By attempting to do this, you are seriously
>> muddying the waters at a time that we need absolutely clarity.
>>
>>  
>>
>> EITHER root zone changes are the responsibility of ICANN, in which
>> case you are advocating #3 (because ICANN is not an intergovernmental
>> organization) OR governments have some kind of special authority over
>> root zone changes, in which case your solution devolves to #2. Please
>> decide which one you are advocating. I will not let you waffle.
>>
>>  
>>
>> What you’ve done in an attempt to discredit the de-nationalization
>> option is to pretend that if we devolve control to ICANN, that
>> governments are excluded entirely from the process. This is obviously
>> false. Governments currently play a major role in ICANN, via GAC
>> advice. So one could easily cut the cord to the USG, vest the IANA
>> function in ICANN fully, and governments would still be involved. Even
>> if the GAC were dismantled, as some of us favor, it is still
>> completely possible and indeed desirable for individuals who work for
>> or are contracted by governments to participate in ICANN.
>>
>>  
>>
>> Some of us are proposing to reform the role of governments in ICANN to
>> make it consistent with a truly equal-status, multistakeholder
>> governance process. I am really getting tired of hearing, as a
>> response to these proposals, that “governments are a part of our world
>> and we can’t ignore or exclude then.” That is either a dishonest or a
>> completely clueless response. By eliminating special powers for
>> governments and avoiding intergovernmental control, we are not
>> proposing to completely exclude governments from the process. We are
>> simply proposing to adhere more consistently to the MS model and give
>> government agencies and employees the same status as everyone else.
>>
>>  
>>
>> Milton Mueller
>>
>> Professor, Syracuse University School of Information Studies
>>
>> http://faculty.ischool.syr.edu/mueller/
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>> >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
>>
>>
>  
> 
> ------------------------------------------------------------------------
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss
> 
> 
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 291 bytes
Desc: OpenPGP digital signature
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140214/081dce4e/signature-0001.asc>


More information about the discuss mailing list