[discuss] discuss Digest, Vol 3, Issue 26

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.
>
>S.
>
>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.
>>>
>>>> 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.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
>> 
>
>_______________________________________________
>discuss mailing list
>discuss at 1net.org
>http://1net-mail.1net.org/mailman/listinfo/discuss

-- 
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>