Filter by topic and date
ICANN and Transition of NTIA’s Stewardship
- Jari Arkko IETF Chair
2 Jul 2014
Last week, I visited the ICANN50 meeting in London. The meeting was held at a location well known to us at the IETF – the Hilton London Metropole.
![IANA being discussed at ICANN50](../../media/images/levy.original.jpg)
The meeting drew a record 3100 attendees on site, ranging from governments to businesses, civil society, and technical community. The hot topic of the week was the transition of NTIA’s stewardship of the IANA functions to the global multi-stakeholder community. This topic was discussed at almost very meeting during the week.
On the last day of the meeting, Patrik Fältström and I moderated a session that focused on the transition. The NTIA made its announcement in March, and there has been a lot of discussion about how to go about the process in the months that followed. In late April, the IAB made a widely recognised contribution on the topic. In June, ICANN published an outline of the process that will be used for the transition, known as “the plan for the plan”. Among other things, the process calls for the establishment of a Coordination Group to assemble a proposal from components provided by respective communities. The final proposed plan should be delivered to the NTIA by September 2015.
Patrik and I believe that the real work in moving forward with planning IANA stewardship without NTIA should now begin. A big part of this work rests on the individual communities (e.g., IETF, RIRs, gTLD and ccTLD communities) that are the IANA functions customers. Our session discussed expectations both for the communities and the community’s expectations of the Coordination Group moving forward.
The session was organised as a set of invited introductory talks around a number of topics, followed by open discussion with the community. The introductory talks were given by members from various constituencies, Alissa Cooper from IETF, Heather Dryden from the Government Advisory Committee (GAC) of ICANN, Olaf Kolkman from NLnet Labs (for ISOC), and Marilia Maciel from At-Large Advisory Committee (ALAC) of ICANN. All introductory slides are available here and the transcript here.
Patrik and I talked about how IANA works and lessons learned so far in the three-month process. We also pointed out that the transition is not rocket science: for instance, we at the IETF are likely pretty close to what is required for the transition, with our agreements, role definitions, groups that track the relationship, and so on. Alissa talked about the role of the communities vs. the coordination group, which is an important topic for us at the IETF, as the IAB’s model for evolution of IANA is that the IETF can control its own destiny.
https://www.ietf.org/blog/wp-content/uploads/2014/07/lessons.jpg
![Lessons learned about IANA as shown at ICANN50.](../../media/images/lessons.original.jpg)
The session ended with with an hour of community discussion in the room and from multiple remote hubs. My summary of the input that we heard was as follows:
- There is a need for continuity in the transition, as the Internet and the registry and other systems are operational. The transition needs to be an adjustment of the existing mechanisms, rather than replacing them with new organizations and mechanisms.
- Accountability has been a big topic for debate at ICANN. But for the purposes of the transition, what matters are those aspects of accountability that relate to the IANA functions. And those aspects need to be addressed in the transition. There are other aspects of accountability in the ICANN system that may require a different and longer process.
- We should strive for diverse participation in the Coordination Group, but not employ strict geographic assignment.
- The role of the communities is key in the process, and the coordination group is only for coordination. It is not the centralised place for designing the transition solution.
The room supported this summary. Interestingly, this support was measured with the first-ever ICANN consensus hum :-) (see RFC 7282).
Photo credits: Martin Levy and Olaf Kolkman