[discuss] discuss Digest, Vol 3, Issue 26

Stephen Farrell stephen.farrell at cs.tcd.ie
Sun Feb 9 21:16:10 UTC 2014

FWIW, yet another pointless web account with yet
another pointless password means I will not be
taking part in that forum. Seems like a bad plan
to me, though I'm sure there are others who prefer
that mode of interaction.


On 02/09/2014 07:21 PM, Boubakar Barry wrote:
> George, All,
> On the mailing list/web-based forum issue, the Steering Committee has
> discussed this. The SC agreed that it's fair that people who want to
> contribute and are more comfortable with using email only should be given
> the opportunity to do so.
> However, at least for now, everyone who wishes to use email only has to
> sign up on the website (once only) and adjusts her/his settings. This way,
> posts can be received as emails and replies via emails are possible too;
> the latter will also appear on the forum page.
> I think this is a good compromise.
> Boubakar
> On Sun, Feb 9, 2014 at 6:50 PM, <discuss-request at 1net.org> wrote:
>> Send discuss mailing list submissions to
>>         discuss at 1net.org
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         http://1net-mail.1net.org/mailman/listinfo/discuss
>> or, via email, send a message with subject or body 'help' to
>>         discuss-request at 1net.org
>> You can reach the person managing the list at
>>         discuss-owner at 1net.org
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of discuss digest..."
>> Today's Topics:
>>    1. Re: Fwd: [] Speaking of accountability (Nigel Hickson)
>>    2. Possible approaches to solving "problem no. 1" (George Sadowsky)
>> ----------------------------------------------------------------------
>> Message: 1
>> Date: Sun, 9 Feb 2014 08:48:42 -0800
>> From: Nigel Hickson <nigel.hickson at icann.org>
>> To: Patrik F?ltstr?m <paf at frobbit.se>
>> Cc: "discuss at 1net.org" <discuss at 1net.org>
>> Subject: Re: [discuss] Fwd: [] Speaking of accountability
>> Message-ID: <B240C1C8-0D12-41F1-9C98-EF775BFE25EF at icann.org>
>> Content-Type: text/plain; charset="utf-8"
>> Avri
>> And thanks for me too. Most things in life could have been done better but
>> events on the ground confirm how it is important for us to seize the moment.
>> Nigel
>> Sent from my iPhone
>>> On 09 Feb 2014, at 11:40, "Patrik F?ltstr?m" <paf at frobbit.se> wrote:
>>>> On 2014-02-08 12:56, Avri Doria wrote:
>>>> Sometimes lots of people chipping away day after day, year
>>>> after year does make a difference.
>>>> And yes, there is still a long long way to go.
>>> Thanks for sharing this mail Avri.
>>> This is why I get so sad when the discussions about an event "that could
>>> have been managed better" turns more into "finding the scape goat"
>>> instead of "how do we improve so this does not happen again".
>>> With emphasize on "we".
>>> Once again thanks!
>>>   Patrik
>>> <signature.asc>
>>> _______________________________________________
>>> discuss mailing list
>>> discuss at 1net.org
>>> http://1net-mail.1net.org/mailman/listinfo/discuss
>> ------------------------------
>> Message: 2
>> Date: Sun, 9 Feb 2014 13:50:27 -0500
>> From: George Sadowsky <george.sadowsky at gmail.com>
>> To: "discuss at 1net.org List" <discuss at 1net.org>
>> Cc: Jovan Kurbalija <jovank at diplomacy.edu>
>> Subject: [discuss] Possible approaches to solving "problem no. 1"
>> Message-ID: <CAE8CF1D-31D3-4110-B470-2E63D8515912 at gmail.com>
>> Content-Type: text/plain; charset="windows-1252"
>> 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.
>>> 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:
>>> 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.
>>> 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.html
>> ------------------------------
>> _______________________________________________
>> discuss mailing list
>> discuss at 1net.org
>> http://1net-mail1net.org/mailman/listinfo/discuss
>> End of discuss Digest, Vol 3, Issue 26
>> **************************************
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss

More information about the discuss mailing list