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 email@example.com 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. 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.
 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.