[discuss] discuss Digest, Vol 3, Issue 26

Nick Ashton-Hart nashton at ccianet.org
Mon Feb 10 08:25:17 UTC 2014

It seems excellent to me - it allows everyone to participate in whichever way they prefer, and only in those subjects which interest them. 

My compliments and thanks to those who set it up.

Stephen Farrell <stephen.farrell at cs.tcd.ie> wrote:
>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
>> the opportunity to do so.
>> However, at least for now, everyone who wishes to use email only has
>> sign up on the website (once only) and adjusts her/his settings. This
>> posts can be received as emails and replies via emails are possible
>> 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
>>> 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
>>> Nigel
>>> Sent from my iPhone
>>>> On 09 Feb 2014, at 11:40, "Patrik F?ltstr?m" <paf at frobbit.se>
>>>>> 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
>>>> 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,
>>> that the opinions I express here are  strictly my own, and not
>>> 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
>>> to the point of containing threads for separate discussions, and
>>> this discussion  ?  if it continues  ?  should be housed there.  On
>>> 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
>>> 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
>>> I?m going to finesse this problem and post to both, hoping that an
>>> 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
>>> easily see what has been proposed.  If there is no pushback on the
>>> I'll remove the brackets and adjust the text properly a couple of
>>> later.
>>> 1. The Internet Assigned Names and Numbers Authority (IANA) has as
>one of
>>> its functions the [vetting] [administration] of [changes] [change
>>> in the Internet root zone file.  The members of the team that
>performs the
>>> IANA functions are employed by ICANN, the Internet Corporation for
>>> Names and Numbers.
>>> 2. ICANN has a zero-cost contract with the US government to perform
>>> 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
>>> 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
>>> function being subject to US law and the decisions of the US
>>> 4. Objections have been raised to US government involvement in this
>>> process on several grounds, including exclusivity and concerns of
>>> Objections have equally been raised to movement of the function to
>>> international organizations.
>>> 5. Acceptable solutions for assignment of the IANA root zone
>>> 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
>>> 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
>>> 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
>>> over this function, is insignificant compared to the other
>>> The IANA functions are currently performed by ICANN under contract
>to the
>>> US government, so that discussing changes to the location,
>>> regime and operational functions that comprise IANA are intimately
>>> with changes to the location, governance regime and operational
>>> of ICANN.  Now there is of course an option that removes the IANA
>>> from ICANN and establishes them elsewhere, and some suggestions in
>>> direction have been made by several governments.
>>> My sense is that (1) in the short run, and perhaps for a very long
>>> such a transfer of control would not be capable of meeting the
>>> of at least requirement 5 above, and (2) would be politically
>>> to the great majority of the actors in the Internet ecosystem.  I?m
>>> therefore going to assume that any acceptable solution retains the
>>> 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
>>> approaches to alternative arrangements for ICANN: (1) a pure
>>> approach, (2) a multistakeholder approach, and (3) an approach that
>>> not include governments.  (Milton will correct me if I have
>>> his views)
>>> The pure multilateral approach is a descendant of regulatory regimes
>>> 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
>>> such an approach is weak and is politically unacceptable.  I believe
>>> 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
>>> upon the creation and evolution of legal structures along with the
>>> administrative and judicial mechanisms that institutes and implement
>>>  We may be concerned with their inappropriate use of power, but we
>>> deny that they have a place at the table.  We are likely, however,
>>> differ about what that place is and what limitations might be put
>upon them.
>>> The second approach, one based upon multistakeholderism, seems like
>>> only viable and significantly acceptable one.  While that choice may
>>> comforting in terms of its inclusive orientation, the space of
>>> that could be called multistakeholder is vast and multidimensional,
>>> the only necessary condition for being in the set is that all
>>> 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
>>> 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
>>> in accordance with a very specific and well-defined instantiation of
>>> 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
>>> Finally, any approach that will be successful must make the great
>>> of us comfortable with its ability to maintain security, stability,
>>> independence of the Internet?s fundamental naming and addressing
>>> 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
>>>  Solutions that do not meet this criterion, and are not demonstrably
>>> 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
>>> 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
>>>  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
>>>  The article, at:
>>> http://www.diplomacy.edu/blog/international-inviolability-root-zone
>>> contains the following scenarios.  I include them here because I
>>> 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
>>> the basis for an analogy with diplomatic law, which deals with
>>> highly symbolic issue: representation  of countries. It includes
>>> precedence, the protection of diplomatic buildings, and the main
>>> of representation.[3] How can the regulation of symbolic aspects of
>>> diplomatic relations help in regulating the symbolic aspects of
>>> 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
>>> will be located.  It could be located at the UN premises in New York
>>> Geneva, which would simplify matters, since those entities already
>>> inviolability, including immunity from any national jurisdiction.
>>> 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
>>> ?[t]he archives and documents of the mission shall be inviolable at
>>> time and wherever they may be.? (i.e. article 24 of the Vienna
>>> on Diplomatic  Relations).
>>>> In this way, the root database can enjoy inviolability according to
>>> international law. Neither the USA,  nor any other authority, can
>>> 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
>>>> Here we get back to the question of decision-making process and 
>>> 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
>>> ICANN, with a stronger role for the GAC (to some extent codifying
>>> formalizing what has been happening through the growing relevance of
>>> 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
>>> laws, could address most of the above-mentioned points. Shifting
>ICANN from
>>> the national to the international level, would require ensuring
>>> accountability towards consumers, users, and the Internet industry.
>>> Immunity should not be impunity.  Again, here we could have a
>>> through the interplay between international public law and private
>>> options.
>>>> The closest analogy is the governance of the Red Cross system.
>>> to the Geneva conventions in the humanitarian field, ?a root
>>> would minimally grant immunity to the root database, and maximally
>>> 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
>>> 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
>>> ICANN, which could be a quasi-international organisation, with a
>>> balanced checks and balances approach, and a prominent role for the
>>> Such an ICANN+ would both host the root server, and manage the root
>>> database.
>>>> There are some other solutions and possibilities. The bottom line
>>> 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
>>> 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
>>> 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
>>> it look like?  Perhaps on further reflection, and considering
>>> 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
>>> Regards,
>>> George
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> ------------------------------
>>> _______________________________________________
>>> 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
>discuss mailing list
>discuss at 1net.org

Sent from my Android phone with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140210/fe80a0c6/attachment-0001.html>

More information about the discuss mailing list