<html><head></head><body><p dir="ltr">It seems excellent to me - it allows everyone to participate in whichever way they prefer, and only in those subjects which interest them. </p>
<p dir="ltr">My compliments and thanks to those who set it up.</p>
<br><br><div class="gmail_quote">Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><br />FWIW, yet another pointless web account with yet<br />another pointless password means I will not be<br />taking part in that forum. Seems like a bad plan<br />to me, though I'm sure there are others who prefer<br />that mode of interaction.<br /><br />S.<br /><br />On 02/09/2014 07:21 PM, Boubakar Barry wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> George, All,<br /> <br /> On the mailing list/web-based forum issue, the Steering Committee has<br /> discussed this. The SC agreed that it's fair that people who want to<br /> contribute and are more comfortable with using email only should be given<br /> the opportunity to do so.<br /> However, at least for now, everyone who wishes to use email only has to<br /> sign up on the website (once only) and adjusts her/his settings. This way,<br /> posts can be received as emails and replies via emails are possible too;<br /> the
latter will also appear on the forum page.<br /> <br /> I think this is a good compromise.<br /> <br /> Boubakar<br /> <br /> <br /> <br /> On Sun, Feb 9, 2014 at 6:50 PM, <discuss-request@1net.org> wrote:<br /> <br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Send discuss mailing list submissions to<br /> discuss@1net.org<br /><br /> To subscribe or unsubscribe via the World Wide Web, visit<br /> <a href="http://1net-mail.1net.org/mailman/listinfo/discuss">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br /> or, via email, send a message with subject or body 'help' to<br /> discuss-request@1net.org<br /><br /> You can reach the person managing the list at<br /> discuss-owner@1net.org<br /><br /> When replying, please edit your Subject line so it is more specific<br /> than "Re: Contents of discuss digest..."<br /><br /><br /> Today's Topics:<br /><br /> 1.
Re: Fwd: [] Speaking of accountability (Nigel Hickson)<br /> 2. Possible approaches to solving "problem no. 1" (George Sadowsky)<br /><br /><br /><hr /><br /><br /> Message: 1<br /> Date: Sun, 9 Feb 2014 08:48:42 -0800<br /> From: Nigel Hickson <nigel.hickson@icann.org><br /> To: Patrik F?ltstr?m <paf@frobbit.se><br /> Cc: "discuss@1net.org" <discuss@1net.org><br /> Subject: Re: [discuss] Fwd: [] Speaking of accountability<br /> Message-ID: <B240C1C8-0D12-41F1-9C98-EF775BFE25EF@icann.org><br /> Content-Type: text/plain; charset="utf-8"<br /><br /> Avri<br /><br /> And thanks for me too. Most things in life could have been done better but<br /> events on the ground confirm how it is important for us to seize the moment.<br /><br /> Nigel<br /><br /><br /> Sent from my iPhone<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> On 09 Feb 2014, at 11:40, "Patrik F?ltstr?m"
<paf@frobbit.se> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> On 2014-02-08 12:56, Avri Doria wrote:<br /> Sometimes lots of people chipping away day after day, year<br /> after year does make a difference.<br /><br /> And yes, there is still a long long way to go.<br /></blockquote><br /> Thanks for sharing this mail Avri.<br /><br /> This is why I get so sad when the discussions about an event "that could<br /> have been managed better" turns more into "finding the scape goat"<br /> instead of "how do we improve so this does not happen again".<br /><br /> With emphasize on "we".<br /><br /> Once again thanks!<br /><br /> Patrik<br /><br /><br /> <signature.asc><br /><hr /><br /> discuss mailing list<br /> discuss@1net.org<br /> <a href="http://1net-mail.1net.org/mailman/listinfo/discuss">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br /></blockquote><br /><hr /><br
/><br /> Message: 2<br /> Date: Sun, 9 Feb 2014 13:50:27 -0500<br /> From: George Sadowsky <george.sadowsky@gmail.com><br /> To: "discuss@1net.org List" <discuss@1net.org><br /> Cc: Jovan Kurbalija <jovank@diplomacy.edu><br /> Subject: [discuss] Possible approaches to solving "problem no. 1"<br /> Message-ID: <CAE8CF1D-31D3-4110-B470-2E63D8515912@gmail.com><br /> Content-Type: text/plain; charset="windows-1252"<br /><br /> All,<br /><br /> I have been preoccupied for several weeks with a non-trivial computer and<br /> operating system migration and a variety of other interruptions. Real life<br /> has a way of intruding upon the most well-meaning of intentions.<br /><br /> I want to repeat that I am a member of the ICANN Board of Directors, but<br /> that the opinions I express here are strictly my own, and not necessarily<br /> consistent with any of the organizations with which I am affiliated.<br /><br /><br /> Mailing list or web site thread?<br /><br
/> If there is sufficient interest, I?d like to propose a discussion of<br /> possible solutions to what is often referred to as the IANA issue that I<br /> introduced several weeks ago, Since then, the 1net web site has developed<br /> to the point of containing threads for separate discussions, and eventually<br /> this discussion ? if it continues ? should be housed there. On the<br /> other hand, I?ve been told that there are a lot of people on the list who<br /> use it as a window into Internet governance discussions, and who are more<br /> likely to want the list messages pushed out to them than to have to<br /> actively log onto a web site to follow specific threads. For the moment<br /> I?m going to finesse this problem and post to both, hoping that an equally<br /> useful non-duplicative solution will become available in the future.<br /> Opinions are welcome.<br /><br /> Here is where I think the discussion was:<br /><br /><br /> Problem statement no. 1 (version
6)<br /><br /> Several suggestions have been made to further refine the problem<br /> statement, I'm including them, but I'm bracketing them so that you can<br /> easily see what has been proposed. If there is no pushback on the changes,<br /> I'll remove the brackets and adjust the text properly a couple of versions<br /> later.<br /><br /> 1. The Internet Assigned Names and Numbers Authority (IANA) has as one of<br /> its functions the [vetting] [administration] of [changes] [change requests]<br /> in the Internet root zone file. The members of the team that performs the<br /> IANA functions are employed by ICANN, the Internet Corporation for Assigned<br /> Names and Numbers.<br /><br /> 2. ICANN has a zero-cost contract with the US government to perform the<br /> IANA functions. [The US government authorizes changes made to the root zone<br /> by verifying that ICANN abides by publicly documented policies prior to the<br /> changes being submitted for implementation.[ ["After
IANA verifies that<br /> ICANN has conformed to publicly documented review policies, the US<br /> government authorizes that changes be made to the root zone.]<br /><br /> 3. It has been a requirement for the contractor providing the IANA<br /> function to be a US organization, resulting in the provision of the IANA<br /> function being subject to US law and the decisions of the US judiciary.<br /><br /> 4. Objections have been raised to US government involvement in this<br /> process on several grounds, including exclusivity and concerns of trust.<br /> Objections have equally been raised to movement of the function to several<br /> international organizations.<br /><br /> 5. Acceptable solutions for assignment of the IANA root zone function<br /> should meet several criteria: (1) protection of the root zone from<br /> political or other improper interference; (2) integrity, stability,<br /> continuity, security and robustness of the administration of the root zone;<br /> (3)
widespread [international] trust by Internet users in the<br /> administration of this function; (4) support of a single unified root zone;<br /> and (5) agreement regarding an accountability mechanism for this function<br /> that is broadly accepted as being in the global public interest.<br /><br /> 6. A number of potential solutions have been proposed; however, there has<br /> been no consensus that any of them are broadly acceptable.<br /><br /><br /> What I believe that we are not discussing<br /><br /> The IANA function is really three functions, and concerns the<br /> administration of (1) Internet protocol parameters, (2) the IP address<br /> space, and (3) the root zone file. I believe that the major focus of the<br /> discussion should be on the root zone file, with possible interest in the<br /> IP address space. Both are important for Internet navigation. The<br /> administration of Internet protocol parameters is an administrative<br /> function performed for the
IETF, and I believe that controversy, if any,<br /> over this function, is insignificant compared to the other functions.<br /><br /> The IANA functions are currently performed by ICANN under contract to the<br /> US government, so that discussing changes to the location, governance<br /> regime and operational functions that comprise IANA are intimately linked<br /> with changes to the location, governance regime and operational functions<br /> of ICANN. Now there is of course an option that removes the IANA functions<br /> from ICANN and establishes them elsewhere, and some suggestions in this<br /> direction have been made by several governments.<br /><br /> My sense is that (1) in the short run, and perhaps for a very long time,<br /> such a transfer of control would not be capable of meeting the conditions<br /> of at least requirement 5 above, and (2) would be politically unacceptable<br /> to the great majority of the actors in the Internet ecosystem. I?m<br /> therefore
going to assume that any acceptable solution retains the IANA<br /> function within ICANN, and we really need to focus upon future<br /> possibilities for ICANN as a whole.<br /><br /><br /> A first rough cut into the solution space<br /><br /> Earlier, I think it was Milton Mueller who wrote that there were three<br /> approaches to alternative arrangements for ICANN: (1) a pure multilateral<br /> approach, (2) a multistakeholder approach, and (3) an approach that does<br /> not include governments. (Milton will correct me if I have misrepresented<br /> his views)<br /><br /> The pure multilateral approach is a descendant of regulatory regimes for<br /> PTTs of the 19th and first half of the 20th century. I believe that it is<br /> accepted opinion now that they have been shown to be inefficient,<br /> non-innovative, financially inefficient, and exclusionary. Pressure for<br /> such an approach is weak and is politically unacceptable. I believe that<br /> we can discard
it.<br /><br /> The third approach is in my view equally unrealistic. Governments are a<br /> part of our world. They have useful and essential functions We depend<br /> upon the creation and evolution of legal structures along with the<br /> administrative and judicial mechanisms that institutes and implement them.<br /> We may be concerned with their inappropriate use of power, but we can?t<br /> deny that they have a place at the table. We are likely, however, to<br /> differ about what that place is and what limitations might be put upon them.<br /><br /> The second approach, one based upon multistakeholderism, seems like the<br /> only viable and significantly acceptable one. While that choice may be<br /> comforting in terms of its inclusive orientation, the space of solutions<br /> that could be called multistakeholder is vast and multidimensional, with<br /> the only necessary condition for being in the set is that all relevant<br /> stakeholder groups, however
defined, have some degree of inclusion into the<br /> process and that no one group has an absolute veto over the activities of<br /> the group. Distributions of power, representation, and decision making<br /> authority all vary, possibly enormously among stakeholder groups. The very<br /> choice of what groups are included and who they include contributes to the<br /> diversity among solutions. (For example, while ICANN correctly claims to<br /> be organized according to a multistakeholder model, in fact it is organized<br /> in accordance with a very specific and well-defined instantiation of the<br /> multistakeholder model.)<br /><br /> So if we are going to talk about multi-stakeholder approaches to the<br /> problem, we will need to differentiate between a variety of them that might<br /> be suggested. Saying that an approach is a multi-stakeholder approach is<br /> not sufficient; it will need to be characterized in a more definite manner.<br /><br /> Finally, any
approach that will be successful must make the great majority<br /> of us comfortable with its ability to maintain security, stability, and<br /> independence of the Internet?s fundamental naming and addressing systems,<br /> and with its ability to withstand takeover by any special interests.<br /> Governments, including the US government, must be an integral part of that<br /> majority if any transition is to be feasible and ultimately successful.<br /> Solutions that do not meet this criterion, and are not demonstrably better<br /> than what we have now, should not and will not be adopted.<br /><br /><br /> Incremental approaches<br /><br /> Assuming that there are continuity and stability virtues in minimizing the<br /> amount of change that is made, I ask myself: are there acceptable solutions<br /> to the problem that minimize the account of change needed? In which<br /> direction would they go? I personally don?t have a good answer for that.<br /> Perhaps others do.<br
/><br /><br /> Diplomatic approaches, from Jovan Kurbalija<br /><br /> In a recent provocative article, Jovan Kurbalija has outlined a number of<br /> scenarios that find their rationale in established diplomatic behavior.<br /> The article, at:<br /><br /><br /> <a href="http://www.diplomacy.edu/blog/international-inviolability-root-zone">http://www.diplomacy.edu/blog/international-inviolability-root-zone</a><br /><br /> contains the following scenarios. I include them here because I think<br /> they represent serious approaches to the issue we?re discussing. They may<br /> or may not be practical.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> USE DIPLOMATIC LAW APPROACH TO SOLVE THE POLICY PROBLEM OF THE ROOT ZONE<br /><br /> The predominantly symbolic relevance of the root zone issue has created<br /></blockquote> the basis for an analogy with diplomatic law, which deals with another<br />
highly symbolic issue: representation of countries. It includes diplomatic<br /> precedence, the protection of diplomatic buildings, and the main functions<br /> of representation.[3] How can the regulation of symbolic aspects of<br /> diplomatic relations help in regulating the symbolic aspects of Internet<br /> politics? Here are two possibilities:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br /> The first possibility could be described as a ?physical? one, making the<br /></blockquote> server and root database inviolable, in particular from any national<br /> jurisdiction. This possibility opens the question of where the root server<br /> will be located. It could be located at the UN premises in New York and<br /> Geneva, which would simplify matters, since those entities already enjoy<br /> inviolability, including immunity from any national jurisdiction. Another<br /> option, such as continuing
to use the current location would require<br /> changes in the US national law, in order to ensure international<br /> inviolability of the root database. One could also consider assigning root<br /> zone file immunity as part of an ICANN+ arrangement (making ICANN a<br /> quasi-international organisation ? discussed further down in the text). [4]<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br /> The second possibility, which is a ?virtual? one: the root database<br /></blockquote> should be assigned inviolabilityper se, wherever it is located. This<br /> solution is based on the analogy with diplomatic law which specifies that<br /> ?[t]he archives and documents of the mission shall be inviolable at any<br /> time and wherever they may be.? (i.e. article 24 of the Vienna Convention<br /> on Diplomatic Relations).<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px
solid #8ae234; padding-left: 1ex;"><br /> In this way, the root database can enjoy inviolability according to<br /></blockquote> international law. Neither the USA, nor any other authority, can interfere<br /> with the root database without necessary authorization. This could be the<br /> first phase in the policy process, which could build trust, and prepare for<br /> the second phase, which has to deal with the more difficult question:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br /> WHO WILL HAVE THE RIGHT TO AMEND THE ROOT DATABASE?<br /><br /> Here we get back to the question of decision-making process and the<br /></blockquote> status of ICANN. This has been exhaustively discussed, and it is clear that<br /> a workable solution should be based on a high level of inclusion,<br /> transparency, and checks and balances. As a practical solution for the root<br /> zone file, one could think of a
double key system, involving a strengthened<br /> ICANN, with a stronger role for the GAC (to some extent codifying and<br /> formalizing what has been happening through the growing relevance of the<br /> GAC). A possible role for a reformed UN Trusteeship council could also be<br /> considered, as one of the actors in this checks and balances system.<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br /> ICANN?s new quasi-international status, for example, following Swiss<br /></blockquote> laws, could address most of the above-mentioned points. Shifting ICANN from<br /> the national to the international level, would require ensuring ICANN?s<br /> accountability towards consumers, users, and the Internet industry.<br /> Immunity should not be impunity. Again, here we could have a solution<br /> through the interplay between international public law and private law<br /> options.<br /><blockquote
class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br /> HOW TO ACHIEVE THE NEW ROOT ZONE ARRANGEMENT?<br /><br /> The closest analogy is the governance of the Red Cross system. Analogous<br /></blockquote> to the Geneva conventions in the humanitarian field, ?a root convention?<br /> would minimally grant immunity to the root database, and maximally specify<br /> how the root database would be managed. If the adoption of a root zone file<br /> convention would be too complex, one could consider an advisory opinion of<br /> the International Court of Justice, which could recognize the ?instant?<br /> customary law (practice of the US government of not interfering in<br /> countries' domain names without the consent of these countries). Either a<br /> convention or instant customary law would provide a functional basis for<br /> ICANN, which could be a quasi-international organisation, with a carefully<br /> balanced checks and
balances approach, and a prominent role for the GAC.<br /> Such an ICANN+ would both host the root server, and manage the root<br /> database.<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br /> There are some other solutions and possibilities. The bottom line is<br /></blockquote> that there is a solution that could be both practical and legal. The<br /> symbolic issue of the root zone, at least, could be put to rest, and allow<br /> us to spend ?policy energy? on more practical and relevant issues. It could<br /> be also be a reasonable compromise.<br /><br /><br /> Conclusion<br /><br /> It?s quite possible that all of the above is a product of too limited<br /> thinking, and that an alternative, more comprehensive and high level<br /> approach looking at the entire Internet ecosystem as a whole might be more<br /> fruitful. If so, what might such an approach be based upon, and why might<br /> it look
like? Perhaps on further reflection, and considering possible<br /> approaches to it, we may find that the problem definition is lacking, and<br /> needs modification or amplification. If so, that represented profess of a<br /> certain kind.<br /><br /> I present the above as my thoughts regarding possible approaches, with a<br /> large contribution from Jovan. I admit to not having good answers to the<br /> problem, but I hope that the above material is helpful to starting a<br /> serious discussion. If there is any appetite on the list to continue this<br /> discussion, I, and possibly others, would be interested in your comments.<br /><br /> Regards,<br /><br /> George<br /><br /><br /><br /> -------------- next part --------------<br /> An HTML attachment was scrubbed...<br /> URL: <<br /> <a
href="http://1net-mail.1net.org/pipermail/discuss/attachments/20140209/b200a859/attachment.html">http://1net-mail.1net.org/pipermail/discuss/attachments/20140209/b200a859/attachment.html</a><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br /></blockquote><br /><hr /><br /><br /><hr /><br /> discuss mailing list<br /> discuss@1net.org<br /> <a href="http://1net-mail1net.org/mailman/listinfo/discuss">http://1net-mail1net.org/mailman/listinfo/discuss</a><br /><br /> End of discuss Digest, Vol 3, Issue 26<br /> **************************************</blockquote><br /> <br /> <br /> <br /><hr /><br /> discuss mailing list<br /> discuss@1net.org<br /> <a href="http://1net-mail.1net.org/mailman/listinfo/discuss">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br /> <br /></blockquote><br /><hr /><br />discuss mailing list<br />discuss@1net.org<br /><a
href="http://1net-mail.1net.org/mailman/listinfo/discuss">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.</body></html>