[discuss] Thoughts welcome on proposed Netmundial submission

Milton L Mueller mueller at syr.edu
Sun Mar 2 15:36:40 UTC 2014

Thanks for a thoughtful contribution.

My view is that everyone is assuming, almost without thinking, that if the USG is no longer involved in contracting for the IANA functions that they would simply move into ICANN. Indeed, that is how I started thinking about it, too.

But that is an assumption that needs to be scrutinized very carefully. Ultimately it is an assumption that does not make a lot of sense. There are three major reasons why ICANN should not simply inherit the IANA functions.

1)      Accountability

2)      Operational responsibility

3)      The need to separate ICANN as policy development authority from IANA as operational implementor of policy.
ICANN’s accountability shortcomings are well known. As it currently stands, the IANA functions contract is the only major check in ICANN running amok. Of course, oversight by the USG is a terrible solution to this problem. But before you hand those functions to ICANN think about what one would do if it messed them operationally or abused them policy-wise. How would one hold them accountable or take the functions away and give them to someone else?
The current IANA contract makes an effort (somewhat flawed) to erect a wall between ICANN as policy authority and ICANN as IANA functions executor. But if you really want those things to be separate, why put them in the same organization?
Also, from an operational standpoint I am sorry to say that despite many highly competent people in ICANN, and IANA especially, ICANN’s operational record is not so good. Mere mention of words like “digital archery” may make the point for me. So who do we trust with the critical operational functions of updating and maintaining the root?

IGP will be releasing a paper on this tomorrow with a more detailed proposal and rationale, but let’s just say for now that after giving this a lot of thought we think globalization of IANA should involve separation of that function from ICANN, not integration of it. If you want to keep ICANN accountable and IANA neutral, the IANA functions should be completely removed from the policy development organization. We think that registries are the most responsible entities to actually edit and maintain the root zone, since it is their data and their service at stake.

So let’s pull the IANA functions _out_ of ICANN, and the root zone maintainer functions out of the USG-Verisign Cooperative Agreement, and put them into a new entity. That structure has a lot of advantages, as you’ll see.


From: discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] On Behalf Of Ian Peter
Sent: Thursday, February 27, 2014 7:32 PM
To: discuss at 1net.org
Subject: [discuss] Thoughts welcome on proposed Netmundial submission

Below are some words I have prepared to submit to NetMundial (acting purely as an individual) before the March 8 deadline. I have copied them to a couple of lists because I know others think similarly – and I am more than prepared to amend this and transform it into a sign-on statement if there is interest.
I acknowledge firstly inputs from others on various lists discussing this which I have adopted. If people are interested in contributing and signing on, happy to take that on board on list or off list. But I do want a pragmatic proposal which has a good chance of being adopted, and will not include suggestions that would be counter to getting some immediate action on this.
 I appreciate there are many other thoughts on this and encourage others to make submissions direct to Netmundial outlining other solutions if they feel so inclined. But any inputs to refine this particular widely discussed suggestion are very welcome.
 This will have to be finalised for sign on, if that direction is taken, by about March 4.
Ian Peter
 Roadmap (and principles) for internalisation of the former  IANA functions within the multistakeholder ICANN model.
 This roadmap concentrates on one internet governance issue only – the future of the IANA functions which have been the subject of much past discussion because current arrangements are seen by many to be outside of the preferred multistakeholder model.
 Indeed, IANA itself was established  in an era before current internet governance models (multistakeholder) and governance institutions (eg ICANN) were in existence.

 This roadmap suggests that the IANA functions, though necessary processes in the secure and authoritative functioning of the Internet, no longer need a separate entity and would more productively merged with similar functions under the auspices of ICANN. Subject of course to many concerns about details, this direction appears to have widespread support from governments, civil society, technical community, and private sector.
 In order to achieve this desired change efficiently and productively, the following roadmap is proposed.

1.       ICANN should be requested to prepare a proposal for management of the previous IANA functions within the ICANN multistakeholder model, bearing in mind the following criteria:

(a) protection of the root zone from political or other improper interference;

(b) integrity, stability, continuity, security and robustness of the administration of the root zone;

(c) widespread [international] trust by Internet users in the administration of this function; (d) support of a single unified root zone; and

(e) agreement regarding an accountability mechanism for this function that is broadly accepted as being in the global public interest."
2. Preparation of the proposal should involve discussion with all major stakeholder groups, with a completion timetable for a first draft for discussion at the Internet Governance Forum in Turkey in September 2014.
3. To expedite completion in a timely manner, it is suggested that outside consultants be engaged to prepare the discussion paper (proposal) in consultation with major stakeholders.
4. The solution must have the following characteristics

(a) offers a legal structure that is robust against rogue litigation attacks

(b) is aligned with the Internet technical infrastructure in a way that supports innovative, technology based evolution of the DNS .

(c) is an inclusive model
(d) is a demonstrable improvement on current processes in this area


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140302/ff1ac457/attachment-0001.html>

More information about the discuss mailing list