[discuss] Roadmap for globalizing IANA

Milton L Mueller mueller at syr.edu
Tue Mar 11 17:08:39 UTC 2014


Gregory:
I appreciate your honesty: you are a defender of the status quo. You want to keep the U.S. in control and change nothing. I am glad that you make this argument clearly and honestly, rather than pretending that there is something wrong with the specific way we proposed to change things. I will make an attempt to answer your question, "what would be better" if IANA was globalized, below. 

But first, I have to chide you for inaccurate and pejorative terminology. You refer to a "registry cartel." Sorry, that's just wrong. A cartel is a formal agreement among firms to maintain specific prices or to restrict supply to maintain higher prices. The DNSA is the registries jointly managing a shared technical resource (the root zone). Managing the root zone does not by itself give them any control over prices or output. And as we have said repeatedly, as a collection of suppliers a DNSA would be a big, fat, highly visible target for antitrust action if it attempted to utilize its root zone management authority to restrict output or raise prices. Participants would be liable for treble damages in the U.S. and similar huge fines in the EU, not to mention other countries.  

As for what would be better, actually, lots. The current separation of responsibility between IANA, NTIA and Verisign has certain security holes. Although Verisign has done a splendid job overall, it could publish errors. Although progress has been made recently, the ccTLDs and other registries have for many years tried to directly control their root zone entries; the USG stood in the way because it would have undermined its control.  
There is political instability inherent in the system of US control - every three years, the US can intervene arbitrarily in the substance of the IANA contract - you are a US citizen and resident, I take it, but people in other countries may not feel so sanguine about the stability or trustworthiness of US politics and law. 

--MM

-----Original Message-----
From: discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] On Behalf Of Shatan, Gregory S.
One of the problems here is that "we" are trying to fix something that isn't actually broken.  As far as I can tell, there is nothing that is actually going to work better if any of the proposals to "globalize" the IANA function(s) and/or the oversight of the IANA functions actually comes to fruition.

As is generally the case when "fixing something that ain't broken," the danger is in screwing something up that actually works.  Since this movement isn't being driven from the technical community outward, proposals are being driven inward by political, policy, ideological and social interests for reasons that have nothing to do with functionality.  Many of these interests seem to come to the table with long-held points of view (or less charitably, axes to grind or agendas  to fulfill) that have been waiting for an opening.  Compounding this, there appears to be skimpy technology knowledge and/or skimpy knowledge of the IANA function(s) and how they are accomplished underlying many of the proposals.

On a policy level, greater control by governments or greater control by a registry cartel concerns me.  On a technical level (where my knowledge is relatively skimpy as well), putting something into place that doesn't work as well and/or is actually more vulnerable to meddling (by some agent other than big, bad Uncle Sam) concerns me as well.

I still find myself wondering what we gain if any sort of "globalization" takes place, while I find myself increasingly concerned about what we might lose or what Pandora's Box we might open.

Greg Shatan

P.S.  I am aware of the "globalization should have happened already"/White Paper justification, the mood-driven "loss of trust" justification, and the "past problems" justification (which seems to amount "things didn't work so well 10 years ago" plus an ill-advised remark by Pres. George "Shrub" Bush several years ago re .XXX that never went anywhere).  I'm still waiting for the "things are actually going to work better" justification and/or "there's a technical problem we have to solve" justification.

-----Original Message-----
From: discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] On Behalf Of Suzanne Woolf
Sent: Tuesday, March 11, 2014 8:45 AM
To: Don Blumenthal
Cc: discuss at 1net.org
Subject: Re: [discuss] Roadmap for globalizing IANA

Hi,

Not to speak for Andrew or anyone else, particularly as I have no formal role in the IETF that touches on governance, but:

The IGOVUPDATE session was intended to review and assess the protocol parameters function as part of the future of IANA, so started with a presentation of some of the history and of the principles attached. There was a lengthy and vigorous discussion; it's probably more interesting to listen to the archive or read the transcript than to have me try to paraphrase.

One prominent thread was that authority over the protocol parameters registries lies entirely with the IETF. There is no public policy component in the IANA protocol parameters function; there may be in the work of the IETF (separate thread someone is trying to start elsewhere), but if so, the place for it is not in the IANA, or in ICANN. Like root server operators, or the RIRs when they get new allocations from IANA, IANA performs these processes in a strictly mechanical way. IANA publishes the data it's given as the output of those other processes.

To me at least, the larger concern is the bias towards the DNS root policy function of ICANN in discussions of future governance of IANA. It's been true since before ICANN was founded that the RIRs and IETF are happy with looking after their own policy functions, and letting ICANN do DNS root policy. The danger in institutionalizing this as we're currently discussing, however, is that their concerns will be glossed over and we'll end up in a situation that can be inappropriately influenced through governance of IANA in the event that someone doesn't like those others bodies' governance processes or outcomes.

All of the proposals I've seen seem to assume that oversight of IANA requires wider (and, usually, more complex) multistakeholder representation from the DNS root policy function than from the RIRs and the IETF. This is probably true, but we need to make sure that we don't inadvertently create some new policy dependency we didn't have before.

I'd like to add that I can't really imagine a situation in which it would be in the interests of anyone in the proposed oversight bodies I've seen to challenge the outcome of IETF processes in maintenance of protocol parameters registries, although I haven't tried very hard yet. However, since almost all of the proposals I've seen speak interchangeably of "the IANA functions" and "the IANA DNS root functions," without appearing to notice or account for this particular asymmetry, I can support my colleagues in being a little nervous about what mechanisms will be put in place to support *their* authority over their relationship with IANA.

And yes, I'm familiar with RFC 2860, and with the ways it's been implemented over the years; but with the oversight body for the proposed contract being composed almost entirely of those with no conceivable relationship to the protocol parameters work, I am, at least, interested in hearing more.

best,
Suzanne



On Mar 10, 2014, at 11:37 AM, Don Blumenthal <dblumenthal at pir.org> wrote:

> My guess is that relatively few people on the list were at IETF. I 
> attend sometimes but couldn¹t do this one, but the minutes of the 
> IGOVUPDATE session are at 
> http://www.ietf.org/proceedings/89/minutes/minutes-89-igovupdate
>
>
> See also
> http://www.ietf.org/proceedings/89/slides/slides-89-igovupdate-0.pdf
> and
> https://mailarchive.ietf.org/arch/msg/ietf-announce/rRn3N89AuGFcarSE7d
> L4o-W
> vxao
>
> Don
>
>
> Can you post information that you are referring to from the IGOVUPDATE 
> session?
>
> Thanks,
>
> Don
>
> On 3/10/14, 11:14 AM, "Andrew Sullivan" <ajs at anvilwalrusden.com> wrote:
>
>> On Mon, Mar 10, 2014 at 09:45:10AM -0400, Marilyn Cade wrote:
>>> ICANN stakeholders
>>> Own this evolutionary discussion.
>>
>> To be clear, ICANN owns it to the extent you conflate "IANA" and 
>> "root DNS co-ordination".  If you're talking about all the IANA 
>> functions, then some other organizations have something to say, as I 
>> think was made clear in the IGOVUPDATE session at IETF89 last week.
>>
>> Best regards,
>>
>> Andrew
>>
>>
>> --
>> Andrew Sullivan
>> ajs at anvilwalrusden.com
>>
>> _______________________________________________
>> 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



                                                                * * *

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


More information about the discuss mailing list