<div dir="ltr"><p class="MsoNormal">Milton,</p><p class="MsoNormal"><br></p><p class="MsoNormal">[Note: Sorry for coming late in this conversation and yet not reading all the previous comments and answers due to limited connection. So I am posting the following after reading the paper and drafting this off line. Apologies for any unintentional repetition.] </p>
<p class="MsoNormal"><br></p>
<p class="MsoNormal">Thank you and Brenden for putting together this innovative
attempt to solving the challenges of the evolving institutional field for
Internet governance, and for sharing it. I have two points about your proposal.</p><p class="MsoNormal"><br></p>
<p class="MsoNormal">First, it is not clear to me how combining the IANA
functions (which your proposal define as clerical) with the Root Zone Maintainer
functions (which I would think are technical, with no more decision making
power than the IANA functions) in a new entity provides that entity with the
authority you seem to be giving it. </p>
<p class="MsoNormal">Indeed, it sounds like you’re proposing to end the
_political_ oversight from USG by replacing it with the industry (DNSA) oversight. You
say the existence of a contract between ICANN and the DNSA provides check and
balance to ICANN and that other entities may even compete to replace ICANN if
that contract were to (as it could) be made renewable every 5 years for instance, etc. In
other words, this contract doesn’t seem like a contract between peer
organizations with each just having specific different roles toward the other,
but a contract between a principal and an agent, or in any case between an
entity that has (a higher) authority over the other since the former can put an
end to the raison d’etre of the latter and give it away to a competitor.</p><p class="MsoNormal"><br></p>
<p class="MsoNormal">While I understand the incentive-based rationale for the
membership of the DNSA, I fail to see where you make the case for such larger authority as you attribute to it, again merely by combining the IANA functions
with the Root Zone Maintainer functions. What is the source of the DNSA
authority which makes it competent to exercise an oversight that matches the
previous political oversight (since removing the term “political” from "oversight" doesn’t seem
to narrow it to only the clerical and technical roles DNSA is supposed to carry
out in the new governance structure) and competent to decide to grant or not to
grant ICANN its contract?</p><p class="MsoNormal"><br></p>
<p class="MsoNormal">I think clarifying this will also help resolve the question
as to whether political considerations (in the larger sense of political) need
to be brought to bear in deciding who should be part of the DNSA – which can be
a decisive factor for the success or failure of this proposal.</p><p class="MsoNormal"><br></p>
<p class="MsoNormal">My second point is much shorter and concerns your reference
to a treaty, at last twice. I don’t seem to find anywhere in the text an
explanation about what the purpose of a treaty would be within the framework of
this proposal. Would you mind elaborate on that? </p><p class="MsoNormal"><br></p>
<p class="MsoNormal">Thanks,</p><p class="MsoNormal"><br></p><p class="MsoNormal">Mawaki</p><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><span style="border-collapse:separate;border-spacing:0px"><div><span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:collapse"><div>
<div><span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:collapse"><div style="font-family:arial,sans-serif;font-size:13px;color:rgb(80,0,80)">
=====================================</div>Mawaki Chango, PhD</span></span></span></div><div><span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:collapse">Founder and CEO</span></span></span></div>
<div><span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:collapse">DIGILEXIS Consulting</span></span></span></div><div><br><span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:separate;border-spacing:0px"><span style="border-collapse:collapse"><div style="font-family:arial,sans-serif;font-size:13px;color:rgb(34,34,34)">
<a href="mailto:m.chango@digilexis.com" style="color:rgb(17,85,204)" target="_blank">m.chango@digilexis.com</a> | <a href="http://www.digilexis.com/" style="color:rgb(17,85,204)" target="_blank">http://www.digilexis.com</a> <br>
Twitter: @digilexis | @dig_mawaki | Skype: digilexis</div></span></span></span></div><div style="color:rgb(80,0,80)">======================================</div></div><div><br></div></span></span></span></div></span></div>
</div>
<br><br><div class="gmail_quote">On Wed, Mar 5, 2014 at 6:52 AM, Adam Peake <span dir="ltr"><<a href="mailto:ajp@glocom.ac.jp" target="_blank">ajp@glocom.ac.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
On Mar 5, 2014, at 2:57 AM, Shatan, Gregory S. wrote:<br>
<br>
> Adam:<br>
><br>
> Don't worry, I haven't dismissed the proposal out of hand. I'm still chewing on it.<br>
><br>
> You mention the concern about "predictable and reliable service" -- do you know of any instances where the current set-up has failed to provide that?<br>
><br>
<br>
<br>
</div>For a period of about 12 months before David Conrad joined as IANA General Manager in 2005 I understand IANA was not working well. David fixed things. David or ccTLD managers on this list could explain and clarify/correct my clumsy words. IANA now has another very capable manager, Elise Gerich. But yes, I believe highly unreliable service for a while. Not quite the current set-up but within the general current arrangement.<br>
<div class=""><br>
<br>
> I think the point about diversity of registries is an important one. In addition to those you mention, there are the ".brand" registries as well, who would provide yet another voice. (I assume these would be included, even though they are not mentioned specifically in the proposal. To the extent these are "single registrant" gTLDs, the "weighting" issue is interesting. (Of course, there may be non-.brand single registrant TLDs as well (I think I saw a couple of applications where the users were not really "registrants" of SLDs ).)<br>
><br>
<br>
<br>
</div>Diversity can be a great protector: interests and motivations may not align, etc.<br>
<span class="HOEnZb"><font color="#888888"><br>
Adam<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
> Greg<br>
><br>
> -----Original Message-----<br>
> From: Adam Peake [mailto:<a href="mailto:ajp@glocom.ac.jp">ajp@glocom.ac.jp</a>]<br>
> Sent: Tuesday, March 04, 2014 12:32 PM<br>
> To: Shatan, Gregory S.<br>
> Cc: 'joseph alhadeff'; <a href="mailto:discuss@1net.org">discuss@1net.org</a><br>
> Subject: Re: [discuss] Roadmap for globalizing IANA<br>
><br>
><br>
> Hi Greg,<br>
><br>
> On Mar 5, 2014, at 1:49 AM, Shatan, Gregory S. wrote:<br>
><br>
>><br>
>> The popular term for this might be "the fox guarding the henhouse." Of course, if it is merely "operational," then perhaps the concern is overblown. But if these functions are merely operational, why not just leave them at ICANN?<br>
>><br>
><br>
><br>
> Not sure about "fox guarding the henhouse"... These functions are essential to the registries' business. As Milton keeps reminding us, it's operational, they need predictable and reliable service.<br>
><br>
> The diversity of registries is quite positive, very different business models (from com to new community tlds), different stakeholders and particularly sponsoring entities (for profit, ccTLD, government, IGO, NGO), geographic diversity (though even with around 25% ccTLD not as balanced as we'd hope), even language.<br>
><br>
> I think it's worth looking at the merits of the proposal.<br>
><br>
> Best,<br>
><br>
> Adam<br>
><br>
><br>
>> Greg Shatan<br>
>><br>
>> From: <a href="mailto:discuss-bounces@1net.org">discuss-bounces@1net.org</a> [mailto:<a href="mailto:discuss-bounces@1net.org">discuss-bounces@1net.org</a>] On<br>
>> Behalf Of joseph alhadeff<br>
>> Sent: Tuesday, March 04, 2014 9:55 AM<br>
>> To: <a href="mailto:discuss@1net.org">discuss@1net.org</a><br>
>> Subject: Re: [discuss] Roadmap for globalizing IANA<br>
>><br>
>> While I am not as well versed in these issues and their history of some of the more frequent commentators, it would seem that accountability is often benefited by and predicated on a separation of duties in oversight. The new organization seems to rely on self-interested parties having an alignment of interest with the public good as opposed to the more traditional concept of separation of duties/interest in oversight. Am I missing the checks and balances?<br>
>><br>
>> Best-<br>
>><br>
>> Joe<br>
>> WOn 3/3/2014 9:43 PM, Milton L Mueller wrote:<br>
>> Nii, thanks for your questions. Most of them are actually answered in the paper itself, but I will answer your questions directly.<br>
>><br>
>>> Why is removing USG not mean just that? End of contract<br>
>><br>
>> First, it would be the end of 2 contracts, not one. ICANN and Verisign. You cannot just end the IANA functions contract.<br>
>><br>
>> Second, both contracts contain serious accountability measures. However wrongly conceived the idea of unilateral U.S. oversight is, how do we ensure that the root zone is managed properly and what is the recourse if the root zone managers are either negligent, incompetent or corrupt? What do you replace the IANA contract with?<br>
>><br>
>> The reason for a DNSA is that registries have the strongest incentive to get root zone management right. It is their data that the root zone contains. To ensure impartial administration we create a nondiscriminatory right to own DNSA to all registries?<br>
>><br>
>>> What problem is being solved by combining functions from other<br>
>>> organizations to create another entity dnsa?<br>
>><br>
>> As noted above: 1) accountability problem; 2) incentives problem. To which we can add: not letting ICANN get too powerful.<br>
>><br>
>>> The proposed Dnsa is potentially a consortium of 1000+ registries and how would this work.<br>
>><br>
>> Not that many companies involved. More like a few hundred; lots of companies have multiple TLDs. Ownership shares might be based on some metric of size, such as names under registration, etc.<br>
>><br>
>> How does GNSO work? How does ccNSO work? How did Intelsat work? (consortium of ~200 national telecom operators). How did Nominet work? (shared ownership by many registrars) How does IEEE work? (hundreds of thousands of members).<br>
>><br>
>>> Is this different from creating another ICANN<br>
>><br>
>> Very different. ICANN is for making policy. It involves representation<br>
>> of diverse stakeholders and a complicated process for developing<br>
>> consensus on policy and approval by the board. DNSA is for operations.<br>
>> Most people I have talked to agree that we need to keep those things<br>
>> separate. So, we separate them<br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<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" target="_blank">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br>
>><br>
>><br>
>><br>
>> * * *<br>
>><br>
>> This E-mail, along with any attachments, is considered confidential and may well be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. Thank you for your cooperation.<br>
>><br>
>> * * *<br>
>><br>
>> To ensure compliance with Treasury Department regulations, we inform you that, unless otherwise indicated in writing, any U.S. Federal tax advice contained in this communication (including any attachments) is not intended or written to be used, and cannot be used, for the purpose of (1) avoiding penalties under the Internal Revenue Code or applicable state and local provisions or (2) promoting, marketing or recommending to another party any tax-related matters addressed herein.<br>
>><br>
>> Disclaimer Version RS.US.20.10.00<br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<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" target="_blank">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br>
><br>
<br>
<br>
_______________________________________________<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" target="_blank">http://1net-mail.1net.org/mailman/listinfo/discuss</a><br>
</div></div></blockquote></div><br></div></div>