<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 10, 2014, at 12:25 PM, Nick Ashton-Hart wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><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><div><br></div></div></blockquote><div><br></div>+1 it is all about compromise and getting the work done. </div><div><br></div><div>--Alain<br><blockquote type="cite"><div>
<br><br><div class="gmail_quote">Stephen Farrell <<a href="mailto:stephen.farrell@cs.tcd.ie">stephen.farrell@cs.tcd.ie</a>> 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, <<a href="mailto:discuss-request@1net.org">discuss-request@1net.org</a>> 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> <a href="mailto:discuss@1net.org">discuss@1net.org</a><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> <a href="mailto:discuss-request@1net.org">discuss-request@1net.org</a><br><br> You can reach the person managing the list at<br> <a href="mailto:discuss-owner@1net.org">discuss-owner@1net.org</a><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 <<a href="mailto:nigel.hickson@icann.org">nigel.hickson@icann.org</a>><br> To: Patrik F?ltstr?m <<a href="mailto:paf@frobbit.se">paf@frobbit.se</a>><br> Cc: "<a href="mailto:discuss@1net.org">discuss@1net.org</a>" <<a href="mailto:discuss@1net.org">discuss@1net.org</a>><br> Subject: Re: [discuss] Fwd: [] Speaking of accountability<br> Message-ID: <<a href="mailto:B240C1C8-0D12-41F1-9C98-EF775BFE25EF@icann.org">B240C1C8-0D12-41F1-9C98-EF775BFE25EF@icann.org</a>><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"
<<a href="mailto:paf@frobbit.se">paf@frobbit.se</a>> 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> <a href="mailto:discuss@1net.org">discuss@1net.org</a><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 <<a href="mailto:george.sadowsky@gmail.com">george.sadowsky@gmail.com</a>><br> To: "<a href="mailto:discuss@1net.org">discuss@1net.org</a> List" <<a href="mailto:discuss@1net.org">discuss@1net.org</a>><br> Cc: Jovan Kurbalija <<a href="mailto:jovank@diplomacy.edu">jovank@diplomacy.edu</a>><br> Subject: [discuss] Possible approaches to solving "problem no. 1"<br> Message-ID: <<a href="mailto:CAE8CF1D-31D3-4110-B470-2E63D8515912@gmail.com">CAE8CF1D-31D3-4110-B470-2E63D8515912@gmail.com</a>><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> <a href="mailto:discuss@1net.org">discuss@1net.org</a><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> <a href="mailto:discuss@1net.org">discuss@1net.org</a><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><a href="mailto:discuss@1net.org">discuss@1net.org</a><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.</div>_______________________________________________<br>discuss mailing list<br><a href="mailto:discuss@1net.org">discuss@1net.org</a><br><a href="http://1net-mail.1net.org/mailman/listinfo/discuss">http://1net-mail.1net.org/mailman/listinfo/discuss</a></blockquote></div><br></body></html>