By now it should be clear to everyone that the IANA functions have three distinct stakeholder communities. Sometimes called “the customers of the IANA,” they refer to 1) those directly affected by the management of the domain name system’s root zone file (mainly top level domain registries); 2) those who rely on the IANA for global coordination of IP address number allocations (primarily but not exclusively the five regional internet registries); and 3) those concerned with the registry for protocol parameters in IETF standards (developers, the IETF, ISOC and the IAB). Each of these communities asks ‘the IANA’ to do very different things. Although the management of these functions have been combined in the same organization for many years, it was never clear why they needed to be combined, other than that they always had been during the simpler, early days of the Internet – and perhaps also because the US government wanted to keep them together under its contractor ICANN to make the regime easier to control.
The IANA Stewardship Coordination Group (ICG) is an independent multistakeholder entity established in July 2014 to coordinate the transition. It simplified the IANA transition by decentralizing the process. The ICG asked each of the three operational communities (names, numbers and protocols) to develop proposals for those aspects of the IANA functions it relies on. But as the three operational communities begin to lurch into action, it is becoming increasingly clear how independent they are of each other, and how different are the requirements they place on the IANA. We should not be surprised if the final outcome of the transition are two or three different IANAs.
The rest of this 2-part blog brings the reader up to date on the progress the three communities have made and shows why a combined IANA is beginning to look more and more problematic from the standpoint of improved accountability for ICANN. It looks first at the deliberations in the IETF, then at developments in the numbers area, and finally at the domain names arena.
The IETF: So happy together…
The IETF seems to have been the best prepared of the three operational communities. It had by September already chartered a working group and set up an open mailing list called ianaplan to discuss the transition. On October 6, 2014, Eliot Lear and Russ Hounsley circulated a draft response to the ICG’s RFP.
For the most part, this document proposes a continuation of the status quo. The most significant aspect of the status quo for IANA stewardship after the NTIA’s exit, however, is its reference to the MoU between ICANN and the IETF known as RFC 2860. RFC 2860 documents a Memorandum of Understanding between the IETF and ICANN concerning the technical work of the IANA. Signed on March 1, 2000, the MoU provides an option for either party, ICANN or the IETF, to terminate the arrangement with six months’ notice. This may seem as if the IETF is in a position to ‘fire’ ICANN if its performance is bad or if it abuses its position. If that were true, the status quo would be adequate for ICANN accountability after NTIA oversight goes away.
Unfortunately, this is not quite the situation; the principal-agent relationship between ICANN and IETF is a very weak one. It is based on a MoU stated in an informational RFC, not a formal contract. In fact, neither the USG nor ICANN itself saw the IETF as the true principal of the IANA contract back in 2000. During the creation of ICANN in 1998-1999, there was an assumption that ICANN was the new IANA and the after-the-fact MoU in RFC 2826 was a retroactive attempt by the IETF to preserve and protect some of its historical prerogatives. During that period ICANN actually trademarked the IANA acronym and registered the domain name IANA.ORG as if it owned the IANA.
True accountability of ICANN to IETF could only come from strengthening the IETF’s role as the true principal in a contractual relationship with ICANN. In general, IETF-ers are happy with ICANN’s performance as the protocol parameters registry now, and seem content to continue to allow ICANN to perform that role. That’s fine, but not terribly relevant from an institutional standpoint. It would be the height of folly to fail to recognize the existence of any risk and to foreclose options forever. IETF should have the authority to take that function away from ICANN and move it somewhere else if it needs to. Such a check and balance is good for ICANN as well; knowing that they can lose the contract keeps them honest and provides an incentive for a balanced relationship with IETF and good performance.
Appropriately enough, most of the discussion on the ianaplan@ietf.org list is about the IETF – ICANN relationship, and specifically about whether its status as a principal should be strengthened by incorporating into its proposal a requirement that ICANN transfer its trademark to IETF and surrender the IANA.ORG domain should the IETF decide that it is no longer satisfied. Unfortunately, there are a few people in the IETF who cling to the idea that the relationship will always be good and there is no need to worry about how to get out of it if something goes wrong. That position is opposed by a larger number on the list who believe that IETF needs to assert more forcefully its right to be the principal in the IANA contract. As of now, the faction favoring tweaking the MoU is winning both the arguments and the greater amount of support. If indeed the IETF is to have true control over the performance of the IANA functions, its new relationship with an independent, non US government-supervised ICANN must make it clear that it can takes its authorized registry elsewhere if it needs to. To avoid confusion and conflict in the event of such a change it must regain control of the iana.org domain and associated trademark. This means that the draft currently circulating will have to be modified.
The RIRs: Your days are numbered….
The process for numbers is far behind the other two operational communities. Insofar as they have acted at all, we see even greater complacency than in the IETF. The essential problem is that the five Regional Internet Registries (RIRs) have insisted on handling the transition proposal development process on a region-by-region basis instead of a global basis, as the IETF is doing.
The RIRs want every region develop their own proposal individually and then give the Number Resource Organization (NRO) the authority to negotiate a final proposal to give to the ICG. Though seemingly bottom-up, in fact this model keeps the whole process under the tight control of the RIRs’ secretariats. The regional processes are driven entirely by strawman proposals drafted by the RIRs’ staff, and the synchronization of the final proposal will be entirely in the hands of the NRO, which is nothing more than the executives of the five RIRs. It is also a dangerously slow process, requiring two steps (a regional and then a global one) when there ought to be one, global process.
Because of this, I made a bit of a nuisance of myself at the ARIN 34 meeting. As an ARIN Advisory Council member, I was surprised and disappointed with ARIN’s inaction in the IANA transition process. For the past 6 months, ARIN’s management has done nothing to inform its community about the transition process and nothing to engage them in it, aside from some perfunctory descriptions of current events at its April meeting. Then suddenly, at its October 8 meeting – 7 months after the NTIA announcement, 3 months after the ICG defined a process that made each operational community responsible for developing proposals and only 3 months before the entire global numbers community is supposed to have a complete, consensus proposal – it scheduled a short, 30-minute segment of its agenda to discussing how to begin a process. ARIN’s Public Policy Mailing List (PPML), its announce list, and even its Advisory Council list had not a single message about preparing for the IANA transition from the staff, aside from a message I sent a month ago complaining about the lack of action.
Clearly, what was supposed to happen, absent my intervention, was that a busy, largely uninformed and barely engaged community would just ratify whatever process the CEO proposed. And what ARIN’s management proposed was little more than a way for their participants to proclaim how wonderful current arrangements are and how little they should be changed. So at ARIN 34, I challenged the regional model, arguing that the IANA transition is a global process, and asked the RIRs to put into place an open, global discussion list immediately. Though the unprepared meeting attendees did not support that idea, there was recognition that a global list should be set up to supplement regional processes and that the NRO should not be the final arbiter of the numbers proposal.
The current numbers regime has always been imperfectly integrated with the ICANN regime. The NRO is not even a truly incorporated entity, and has no global oversight or appeals mechanism. It is unclear how the regional system can make comprehensive reforms, because any global policy change has to be approved by regional authorities that may have vested interests in maintaining the existing institutional structure. A very loose, informal relationship exists between the RIRs and ICANN; the inability of the 5 RIRs and ICANN to agree on a common trust anchor for RPKI is an example of the autonomy of the system. And while that lack of a clear hierarchy is not necessarily a bad thing, we need to do some serious thinking about what should and should not change during the IANA transition.[1] That thinking needs to be done not just by the RIR secretariats – organizations with a very heavy self-interest in the outcome – but by other stakeholders as well, such as legacy address holders, Internet service providers and digital rights groups.
Domain names: stay tuned.
If you’ve made it this far into this overly long blog post, congratulations. I will focus on the domain names process in my next blog, which will also benefit from my presence at the ICANN 51 meeting where the Cross Community Working Group will meet and liaise with the ICG.
[1] A lot of questions are being asked, for example, about whether it make sense any more to break down numbers into 5 distinct regional entities with different policies. There are also questions about who should run the .arpa domain, which provides reverse mapping of IP addresses.
Milton –
An excellent blog (as usual) but you apparently are confused on some of the events and structures involved when it comes to the RIR activities in this area, and at ARIN in particular.
The most basic difference between the IETF and RIR efforts is that the Regional Internet Registries actually are five distinct member-based organizations with legally-defined governance structures. You seem alarmed that the IANA stewardship discussion isn’t starting out at global level, but fail to connect that to your own observation that NRO is a very lightweight body (for operational coordination between the RIRs) without any formal oversight or membership structure. It was a not a decision to “not use a global process”, but instead the simple fact that the NRO has no basis to preempt each RIR community and their governance processes in each region. To be truly be community-based, a proposal needs to come from actual communities in each region using number resources. Unlike IETF and ICANN, the RIR communities are organized and meet regionally… this is not just for Internet registry purposes but also in terms of related discussions such as network operator forums)
Note also that the RIR communities have a very successful global policy development process; one which produces clear global policies for IANA’s management of number resources. It is a process which is based on submissions from the individual regional communities, with an Advisory Council (the ASO AC) of community members (not RIR staff) to facilitate the process. It is not a particularly quick process, but does respect the right of each regional community to determine its own policy positions. We now have each RIR doing the same process with respect to the ICG submission, but in light of the timelines are going to have to figure out a faster process to get to a single overall RIR community submission (as the RIR global Policy Development Process involves many iterations and doesn’t always converge.) In terms of accountability to the community using number resources, you probably forgot that the RIRs have always had an advantage of being actual member-based organizations, and as such have actual boards elected by the community providing oversight to the system.
I welcome your “serious thinking” about the transition of the IANA stewardship (and what should or should not change), but suggest that you actually engage with those who rely on the IANA for global coordination of IP address number allocations – there is a list of upcoming meetings available online.
Thanks!
/John
John Curran
President and CEO
ARIN
A procedural issue has also bubbled up recently. Apparently the NTIA does not consider that, for the purposes of this exercise, the ICG is ICANN, or at least the organ to which ICANN delegated the task, see:
http://forum.icann.org/lists/icg-forum/msg00015.html
Best,
Richard
Milton,
Thanks for your update on this important topic. I look forward to seeing how this process will eventually work out. I hope that the RIR communities are able to come together after the 5 initial strawmen are drawn within the RIRs to actually have a global debate on what oversight is necessary of the IANA functions for the benefit of the Internet number resource community.