[discuss] discuss Digest, Vol 3, Issue 26

Sun Feb 9 19:21:02 UTC 2014

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
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140209/1c97c6ad/attachment-0001.html>