The director general of regional internet registry APNIC, Paul Wilson, has called for a staggered transition of the critical IANA contract away from the US government.
Rather than be forced to wait until the controversial and complex issue of domain names is decided, Wilson proposes that the two other key elements of the contract – the allocation of IP numbers and internet protocols – be allowed to move to a new arrangement sooner.
"The question arises as to whether the transition plans for each of those sets need to be implemented at the same time; or whether they can instead be sequenced, as steps within a single coherent transition plan," he argued at a Thursday morning meeting of the group that will make the formal proposal. "A staged transition would allow the transition of protocols and numbers services on the original planned transition date… it would then allow the Names services to be transitioned later."
Following a request from the US government in March 2014 for the internet community to develop a transition plan for the IANA contract, the community quickly split the task up into the three key elements – names, number and protocols – and asked the group responsible for each to come up with their own proposal. Those proposals would then be combined in a single proposal and sent, via the ICANN board, to the US government.
IANA: What's at stake?
The US government contracts non-profit ICANN to run the so-called IANA functions – a body that runs the highest level of the world's DNS, allocates IP addresses, and ensures developers can agree on the same numbers and protocols when writing software that communicates over the 'net. It's what keeps the internet as we know it glued together.
That crucial contract is coming to an end, and because the US wants to step away from ruling the internet like an unelected king.
The IANA contract itself comprises three main functions: names, numbers and protocols. Transition plans for the later two are largely agreed but the most complex issue of names is being explored by a panel of experts called the Community Working Group (CWG). ICANN, of course, would love to run IANA all by itself, simply put.
But while both the numbers community – made up largely of the regional internet registries (RIRs) – and the protocols community (effectively the IETF) have drawn up, reviewed, finalized and approved their final proposals, the names community, which is larger and more diverse, is still embroiled in controversy, and is unlikely to come up with a proposal for several more months.
Wilson originally proposed a cut-off date of 30 September, the day the current IANA contract ends, but talking to us from his home in Australia, he said: "It's clear that the timetable has now drifted so we're not going to make 30 September."
However, he noted, "people do like the idea of a staged plan – just later on. It can be a single plan but with several steps. If the two communities [numbers and protocols] are ready then we might as well do it."
Wilson's plan could also come with some benefits to the internet community and the US government. "A staged transition will demonstrate concrete progress in the transition process, and the concrete commitment of all parties to the transition," he argued to the group. "A failure to implement any transition steps on 30 September may be otherwise taken (or characterized) as a failure of the community process or of the US Government’s commitment to the IANA stewardship transition."
A good transition of the number and protocols would also lend "more confidence in the subsequent transition of the Names services."
Wilson may have a point: as discussions have dragged over the names component of the contract, people have started questioning the process itself. In large part, the names component of the contract is most complex because it also involves contracts that are controlled and awarded by the company that will take over the IANA contract – domain-overseer ICANN.
ICANN approves and updates contracts with both internet registries – like the people who run the .com structure – and internet registrars, such as GoDaddy. Decisions that ICANN makes directly impact dozens of domain-name companies.
As a result, many are concerned, especially given ICANN's long history of opaque and questionable decision-making, that if the organization is given control of the IANA contract without adequate safeguards, it would become more powerful and less accountable. To date, the US government has repeatedly served as an effective backstop to the worst excesses of the non-profit organization.
Leave us out of it
However, neither the RIRs nor the IETF have much concern with respect to ICANN, at least not in terms of how it impacts how their jobs.
The RIRs have proposed they draw up a service-level agreement with ICANN over its IANA contract role. If for any reason ICANN failed to perform up to that standard, the RIRs would be able to simply move their business elsewhere.
The IETF is even less attached to ICANN. It shares a "supplemental agreement" with IANA/ICANN that it can walk away with at any time with 30 days' notice.
Neither the IETF nor the RIRs have much of a financial stake in ICANN, and almost all their business done outside the organization, so concerns over the organization's functioning are academic at best (in truth, many in the numbers and protocols world avoid ICANN and its palace of intrigue as much as possible.)
There are advantages to the technical communities of getting out of the IANA transition process early. For one, it would stop ICANN's staff from trying to pressure them into handing over perpetual control of IANA as a way of trying to undermine the names community's efforts to introduce greater accountability.
It would also save the RIR and IETF communities hundreds of hours of meetings and months of ICANN politics on a topic that has little or nothing to do with them so they could get on with their jobs.
So far, Wilson's plan for a staggered IANA transition has, somewhat expectedly, been warmly welcomed by the numbers and protocols community, and resisted by the names community. ®