[discuss] discuss Digest, Vol 3, Issue 26

ALAIN AINA aalain at trstech.net
Mon Feb 10 10:19:44 UTC 2014


On Feb 10, 2014, at 12:25 PM, Nick Ashton-Hart wrote:

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

+1 it is all about compromise and getting the work done. 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140210/8ef0d90d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 495 bytes
Desc: This is a digitally signed message part
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140210/8ef0d90d/PGP-0001.sig>


More information about the discuss mailing list