[discuss] discuss Digest, Vol 3, Issue 26
Seun Ojedeji
seun.ojedeji at gmail.com
Mon Feb 10 11:48:41 UTC 2014
On Mon, Feb 10, 2014 at 10:08 AM, ALAIN AINA <aalain at trstech.net> wrote:
>
> 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.
>
> Yeah IF the work gets done ;) I hope this new approach can be evaluated
after some time
Cheers!
> --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
>
>
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss
>
--
------------------------------------------------------------------------
*Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>seun.ojedeji at fuoye.edu.ng
<seun.ojedeji at fuoye.edu.ng>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140210/2d78377f/attachment-0001.html>
More information about the discuss
mailing list