[discuss] Roadmap for globalizing IANA

Milton L Mueller mueller at syr.edu
Wed Mar 5 16:52:06 UTC 2014


-----Original Message-----
From: Jeanette Hofmann [mailto:jeanette at wzb.eu] 
>Milton, I have a perhaps naive question. If the DNSA has no policy role 
>but only carries out policy decisions that have already been made elsewhere 
>what exactly is the difference between the newly formed DNSA and Verisign? 
>In other words, what is the specific improvement that DNSA would provide 
>compared to Verisign?  I mean a Verisign no longer tied by a contract with NTIA.

A good question, actually. 

A Verisign-run DNSA without a cooperative agreement with NTIA? There are many differences. 

First, a DNSA with co-ownership by many other registries would ensure that VRSN did not do anything discriminatory in its implementation, and also that it would be as attentive to the needs of other registries as to its own needs. Second, DNSA as a form of "collective bargaining" with ICANN regarding the substance of the implementation contract would allow the contract to be a better check and balance against overbearing exercises of contractual power by ICANN in its registry agreements. Third, a broader DNSA might decide to incorporate outside of the USA, although it should not be allowed to incorporate anywhere without strong antitrust institutions and free expression guarantees, which may limit it to North America or Europe in practice. Fourth, if one registry (Verisign or anyone else) provides the function they will eventually demand to get paid for it; if it is VRSN alone, they might overstate the costs and get paid via ICANN which is known to be flush with cash. If it is a group of registries taxing themselves, I suspect cost-minimization would be the order of the day.  
 



Personally I have no clear opinion on the number of organizations necessary or desirable to produce a reliable and fully accountable IANA function. Following the discussions here I ask myself whether we are slowly moving towards a constitutionalization of the entire CIR area, including all I* orgs.

jeanette



Am 05.03.2014 04:52, schrieb Milton L Mueller:
> These charges of fox guarding henhouse are just uninformed, I think they are knee-jerk reactions based on the false perception that DNSA makes policy. It doesn't. I've talked with a lot of people about this and have learned that lots of them are so used to the combination of policy making and IANA DNS functions in ICANN that they find it difficult not to conflate root zone implementation and operation with the policy process.
>
> But that is exactly the conflation we are trying to eliminate institutionally -- and mentally.
>
> Please tell me how 100+ registries collectively manage to eat the chickens when they have a binding contract with ICANN to do nothing but implement policy, when their ambitions check each other, and when, as an organization of incumbent registries, they are subject to huge antitrust liability if they manipulate the functions to exploit monopoly power to enlarge their profits. Those are not serious threats.
>
> The real difficulties here are working out the governance structure among the registries. There might be intelligent concerns about that, and how long it would take. But I think those problems can be overcome if people support the basic model.
>
> The idea that the DNSA needs "multistakeholder oversight" is mostly recursive nonsense. One could just as well call for multistakeholder oversight of the overseers. And so on. Are not hundreds of registries, from all countries of the world, from private and public sector, from profit and nonprofit, from various business models, enough stakeholders? Anyway, multistakeholder representation makes sense as a policy development method, not as a way of controlling technical operations.
>
> Of course, nothing stops a multistakeholder review process from deciding that the DNSA was derelict in its duty, and calling for breach of contract. But that's policy, isn't it?
>
>
> -----Original Message-----
> From: discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] On Behalf Of Shatan, Gregory S.
> Sent: Tuesday, March 4, 2014 12:58 PM
> To: 'Adam Peake'
> Cc: discuss at 1net.org
> Subject: Re: [discuss] Roadmap for globalizing IANA
>
> Adam:
>
> Don't worry, I haven't dismissed the proposal out of hand.  I'm still chewing on it.
>
> 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?
>
> 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 ).)
>
> Greg
>
> -----Original Message-----
> From: Adam Peake [mailto:ajp at glocom.ac.jp]
> Sent: Tuesday, March 04, 2014 12:32 PM
> To: Shatan, Gregory S.
> Cc: 'joseph alhadeff'; discuss at 1net.org
> Subject: Re: [discuss] Roadmap for globalizing IANA
>
>
> Hi Greg,
>
> On Mar 5, 2014, at 1:49 AM, Shatan, Gregory S. wrote:
>
>>
>> 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?
>>
>
>
> 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.
>
> 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.
>
> I think it's worth looking at the merits of the proposal.
>
> Best,
>
> Adam
>
>
>> Greg Shatan
>>
>> From: discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] On 
>> Behalf Of joseph alhadeff
>> Sent: Tuesday, March 04, 2014 9:55 AM
>> To: discuss at 1net.org
>> Subject: Re: [discuss] Roadmap for globalizing IANA
>>
>> 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?
>>
>> Best-
>>
>> Joe
>> WOn 3/3/2014 9:43 PM, Milton L Mueller wrote:
>> Nii, thanks for your questions. Most of them are actually answered in the paper itself, but I will answer your questions directly.
>>
>>> Why is removing USG not mean just that? End of contract
>>
>> First, it would be the end of 2 contracts, not one. ICANN and Verisign. You cannot just end the IANA functions contract.
>>
>> 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?
>>
>> 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?
>>
>>> What problem is being solved by combining functions from other 
>>> organizations to create another entity dnsa?
>>
>> As noted above: 1) accountability problem; 2) incentives problem. To which we can add: not letting ICANN get too powerful.
>>
>>> The proposed Dnsa is potentially a consortium of 1000+ registries and how would this work.
>>
>> 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.
>>
>> 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).
>>
>>> Is this different from creating another ICANN
>>
>> Very different. ICANN is for making policy. It involves 
>> representation of diverse stakeholders and a complicated process for 
>> developing consensus on policy and approval by the board. DNSA is for operations.
>> Most people I have talked to agree that we need to keep those things 
>> separate. So, we separate them
>>
>>
>>
>>
>> _______________________________________________
>> discuss mailing list
>> discuss at 1net.org
>> http://1net-mail.1net.org/mailman/listinfo/discuss
>>
>>
>>
>> * * *
>>
>> 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.
>>
>> * * *
>>
>> 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.
>>
>> Disclaimer Version RS.US.20.10.00
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss
>



More information about the discuss mailing list