ICANN has concluded its call for public input concerning its proposed IANA transition draft process and scoping document. The main takeaway from this input? ICANN’s proposed draft process and scoping document have been thoroughly beaten up by the community.
The call for input and feedback was facilitated by the creation of a special mailing list. Over 1000 emails were posted to the list (much of it relevant, some not so much) between March 24 and May 9 when the list was abruptly shut down. What exactly will be considered on record and included in ICANN’s summary is somewhat unclear. It strikes us as problematic that ICANN seemingly spent considerable effort framing the discussion and fostering interaction among the community, when it probably should not have presumed anything and simply run the process like a boring administrative proceeding.
By our count, ICANN received 49 self-identified submissions, which arrived in a flurry leading up to the May 8 deadline. Comments were received from wide array of actors, including ICANN contracted and noncontracted parties, its advisory committees, the I* organizations, a handful of governments, and others. A table with a complete list of the commenting parties, links to their submissions, and an analysis of their response to key questions can be found here.
An initial analysis of the comments clearly indicates there is much to be revised concerning the development of an IANA transition proposal. More specifically, there is:
- Widespread support for linking accountability concerns to the IANA transition. Twenty organizations, including both contracted parties (registries and registrars) and non-contracted user constituencies (noncommercial, business, intellectual property) from ICANN’s GNSO, as well as the ccTLD registries, identified this issue. The operative word here is “linking”. Many of the aforementioned organizations identified either the dependency of the IANA functions proposal on successfully completing a concurrent process to improve ICANN accountability, or the necessity of specifically addressing the later in development of the former. Only Google said it did not “support any efforts to conflate broader ICANN accountability or transparency concerns with these technical functions.”
- Strong support for allowing structural separation to be in scope. Twelve organizations explicitly called for examining this option, with support for it spread across TLD registries, civil society and business. The Registry Stakeholder Group probably used some of the clearest language saying “that the premise that ICANN will de facto absorb all of the IANA functions should not be assumed at the outset.” That dovetailed with statements by American business lobby USCIB and others, which endorsed “robust discussion of the relationship between IANA implementation and policy development.” Two organizations (NRO and Google) were ambiguous, dancing around support for the idea, and only a single respondent (auDA) stated that the process should not examine structural separation.
- Support for the IAB’s proposal to divide the functions into different processes. Eight organizations, representing each area of the IANA functions, voiced support for the idea that the respective names, numbers, and protocol parameters communities should develop their own components of the transition proposal. Even the Root Server System Advisory Committee (RSSAC), which nominally presents views of the independent root server operators, chimed in supporting the IAB approach and expanded it, identifying the “primary importance of…their [root server operator] participation in defining the requirements for any changes to these operations.”
- Near unanimous reservations about the composition and role of ICANN’s proposed “steering group.” Thirty-five respondents voiced a variety of concerns. Many identified the proposed group as unbalanced or unrepresentative of “affected parties”. Concerns were also voiced about the ICANN Board and GAC Chairs appointing people to the group instead of letting stakeholders pick their own representatives. Moreover, several comments correctly identified the tension between a concept of the steering group as an authoritative body which perfectly represents ‘the entire world’ and a lightweight coordinating body. Only ICANN’s At Large Advisory Committee (ALAC) was out of step with these comments, agreeing with “the creation of a Steering Group with the membership of the Steering group as described.”
- Rejection of the idea that the ICANN Board should make the final decision as to what proposal is submitted to NTIA. Comments noted that the final proposal should be considered as agreed by the broader multistakeholder community, and should not be subject to change by the ICANN Board. Instead, the board should only certify the process of the proposal preparation. Related to the certification role, Google noted that the Board should refrain from being in a position where it may influence the scoping document, which should be determined by the community.
6 thoughts on “ICANN’s proposed IANA transition process and scope rebuffed”
A question on the ‘table with analysis’: On the submissions from Chinese individual/orgs/gov, how could there be all sorts of conclusions ‘yes’,’no’ and ‘–‘ in the last column drown from similar language in these submissions?
Regarding the table, I do support the IAB proposal to separate the various parts of the IANA function. Please correct the table accordingly.
Thanks and best,
Mr Mueller, pretty good summary above (albeit with some clarifications needed). I find that you are very critical of the ICANN processes in many of your blogs. Is there any place in your website where you talk about how the ICANN should handle this transition of the stewardship of the Internet? I mean where can I find your view of how it should be done? Please advise.
Our proposal for handling the transition is posted here: Roadmap for globalizing IANA: Four principles and a proposal for reform
Comments are closed.