Filter by topic and date
IANA Transition Update
- Jari Arkko IETF Chair
10 Sep 2014
The transition of NTIA’s stewardship of IANA has been discussed extensively. Just last week there was a meeting of the IANA Stewardship Transition Coordination Group or ICG.
At the IETF we made the final decision to create the IANAPLAN working group. And IANA transition was also an important topic in the last week’s Internet Governance (IGF) meeting.
And these are just examples of the many discussions taking place on this topic. With so many interested people, many opinions, a role for the NTIA that is difficult to understand even in the current system, it can all be very confusing. What is the real story, and what is happening? And how far is the Internet community in this process? What are the challenges? I wanted to provide my personal perspective on these questions.
The first thing that is important to understand is that the role of IANA is in bookkeeping, not setting the policy. They perform a very important role for the Internet, but the actual policy decisions – such as the assignment of new top-level domains or protocol numbers – are done elsewhere. For instance, these decisions take place through the multi-stakeholder gTLD process at ICANN, or at the IETF based on community consensus.
Secondly, the transition is focused on the role of the NTIA, to move their oversight or stewardship to the hands of the Internet community. It is not about who performs the IANA function. That is not changing. (But of course, the oversight role brings a responsibility to track the performance and make any corrective actions that might be needed.) Also, in the past 15 years, the community has already taken on much of the oversight role, so in my opinion the transition is not necessarily the abrupt change one might think it is.
So given the above background, what is happening and where? The primary responsibility for planning the transition lies with the operational communities that interact directly with IANA. Specifically, these communities are the IETF (the customer for IANA’s protocol parameter registry services), Regional Internet Registries or RIRs (the customers for IANA’s high-level address block registry services), and ICANN gTLD and ccTLD communities (the customers for IANA’s top-level domain name registry services). These communities are also expected to engage with the broader Internet community, to ensure that their plans work well also from the point of view of the business, civil society, government, and other angles.
At the IETF, this work is happening in the IANAPLAN working group. Leslie Daigle and Marc Blanchet chair the group, and there is already an early individual draft on what the IETF approach to the transition might be. If you are interested and would like to contribute, join the mailing list here! The work of the IANAPLAN working group builds on the well-established IETF processes. If you are new to the IETF, please consult the Tao for information on how to participate. As with everything else in IETF, participation is open to everyone, everyone participates as individuals rather than representing organisations, and decisions are made not through voting but through rough consensus and running code.
Similarly, the RIRs are already quite far along in setting up their organisations to develop the plan. And at ICANN, various communities are working through a newly founded Cross-Community Working Group to develop a plan. Links to the community efforts related to IANA transition can be found from the ICG’s web page.
All the above efforts are in their beginning stages, and only starting to gather input and participants. Much work remains, please join these efforts and ensure that everyone who cares about the transition is involved!
A coordination group, the ICG comprised of 32 individuals from the Internet community, has been set up to coordinate among these efforts. The group has approved a charter for its work, and sent a request for proposals (RFP) to the communities, along with a planned timeline to complete the work by September 2015. Plenty of work remains in the coordination group, but most of the initial effort in ensuring that the communities are working on the transition is done.
All in all, work is underway on these different fronts, and with very few exceptions, everyone believes the transition is a good thing for the Internet. However, there are also challenges.
The first challenge is the timeline. A year sounds like a long time to develop and find an agreement for a plan. However, the development of a plan requires a number of different steps and a lot of community discussion across the world. Some time needs to be reserved for the NTIA to determine if they find the plan acceptable, some time is needed to test drive any new mechanisms, some time is needed to ensure that the different communities have plans that work well together, and time is needed for the the community comment periods. I think the engineers and stakeholders in the IETF and RIRs are well positioned to meet the timeline, but the timeline remains a challenge even for them. The names community has more work to do, however, and for them the timeline is a real challenge. I remain optimistic, however, and I think of the timeline as an opportunity to stay focused on the key mission. There is nothing that prevents an extension to the timeline either, although on longer timescale the risk of changes in the direction of the participating organisations increases (in particular, at the NTIA).
The other challenge is accountability. Some have viewed the NTIA as a backstop in case something bad would have happened. While that view is not shared by everybody, everyone does want to ensure that after the transition there will be sufficient means to ensure reasonable safeguards against misbehaving organisations, capture, mistakes and other bad situations. ICANN has started an accountability improvement project to ensure this. Finding a solution that satisfies the concerns will not be easy, and it has to be done without reference to an external entity that the NTIA has been. However, I think the discussions so far have approached this problem too much in the abstract. The accountability that is needed is for the oversight of IANA.
The necessary solutions depend on which IANA registries are discussed. For instance, I believe the IETF has a reasonably good answer for accountability with regards to protocol parameters. A contract between the IETF and ICANN governs the duties and roles of the parties. Any difficulties are tracked on a daily basis and if there ever was a serious problem, could be raised up in the organisations. But of course, IANA protocol parameters service has been running very well from the IETF point of view. Ultimately, for the unlikely unresolvable problem, the contract has a termination clause. Similarly, if the policy decisions in the IETF are mismanaged, there are community last call, appeal, nominations committee, and recall mechanisms that enable the community to correct failures in actions, or, if serious, replace the leadership that has managed them. In conclusion, I think the IETF focus is on accountability through these existing arrangements. Accountability improvements at ICANN would be useful, but not absolutely required for the IETF part of the transition. This is probably not true for the names part of the IANA registries, however, and significant work is needed there.
The third challenge is reaching everyone who needs to be involved in the discussions, and finding an agreement. We all have to be able to discuss with a broader community than we have been used to – a broadly supported transition plan has to have buy in from different corners of the Internet community, from engineers to domain name experts to the businesses and governments. I am committed to ensuring that we at the IETF communicate our plan broadly, and draw in the interested participants to this work.
I hope this post is a useful reference for sharing the current state of the transition planning from an IETF perspective. I’d welcome thoughts and suggestions about other information that would be helpful.