[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