[discuss] Roadmap for globalizing IANA

Shatan, Gregory S. GShatan at ReedSmith.com
Tue Mar 11 13:25:41 UTC 2014


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


More information about the discuss mailing list