ICANN ver. 2.0 and 'Mission Creep'
Date: Thursday February 28 2002, @02:45AM
Topic: ICANN Staff and Structure

First, the good news: Stuart Lynn's Reform Proposal recognizes that ICANN, ver. 1.0, is broken. I agree - and, personally and for what its worth, I think Lynn deserves some credit and even some thanks from those of us who've been in the critics' camp for a long time for having stated that as clearly as he has.

But there's some (very) bad news here, too. ICANN's Board, under Lynn's proposal, is, quite literally, out of control.

ICANN's Mission.

Lynn writes:

"ICANN's mission is effective management and coordination of those few, higher-level elements of the Internet's naming and address allocation systems that require or benefit from global management and coordination, while abstaining from actions that might interfere with the creativity and innovation that has made the Internet such a dynamic resource. ICANN's mission is stewardship and operational stability, . . ."1

Fair enough - I might quibble with the precise wording, but let's start here. Even if we take this as the institution's core mission, two separate questions have to be answered:

First, how can we be reasonably sure that the institution will in fact make the "right" decisions about "management and coordination of those few, higher-level elements of the Internet's naming and address allocation systems that require or benefit from global management and coordination"? [We can call this the "effective co-ordination" issue.]

Second, how can we be reasonably sure that ICANN will stay within this scope, i.e., that it will not make any decisions, "right" or "wrong," about matters that are not directly related to "management and coordination of those few, higher-level elements of the Internet's naming and address allocation systems that require or benefit from global management and coordination"? [This is the "mission creep" issue.]

Mission Creep

I want to focus my comments on the second, "mission creep," issue. I do this for a couple of reasons. First, there is the simple division of labor; others will have lots to say about the "effective co-ordination" questions, and I'm content to leave that to them for now. Second, I happen to think the mission creep issue is in many ways far more important than the first. However ICANN is constituted, it is bound to make some good, and some bad, decisions within its scope; the net will, in either case, survive. What is truly dangerous about ICANN is not that it might make stupid decisions about the location of root servers, or the administration of particular ccTLDs, or the introduction of new generic TLDs; what is truly dangerous about ICANN is that it might use its power over the DNS chokepoint to enforce global policy on the use of anonymous remailers, on trademark law, on the exchange of pornographic information or copyrighted music files, or the rest of the policy issues that it has the power (if not, currently, the inclination) to address.

Lynn, presumably, would agree: "It is essential," he writes, "to state unambiguously what falls outside of ICANN's scope. The core ICANN mission includes no mandate to innovate new institutions of global democracy, nor to achieve mathematically equal representation of all affected individuals and organizations, nor to regulate content, nor to solve the problems of the digital divide, nor to embody some idealized (and never-before-realized) model of process or procedure. However important those ideals may be, they are for other, better-suited organizations to address."

The central problem, though, is easily identified: it is necessary, but it is not sufficient, to "state unambiguously" the things that fall outside of ICANN's scope. The Soviet Constitution "stated unambiguously" the things the Soviet government could never do. The government then went and did them. Power corrupts, and absolute power corrupts absolutely. The ICANN Board will reach beyond whatever its mission statement says, irrespective of how unambiguous that mission statement might be, if it is permitted to do so. There is virtually nothing on earth more certain than this.

What is there, in Lynn's plan, that can reassure us that ICANN will not stray beyond its core mission? In a word: nothing. Or nothing much. An Ombudsman with no power to keep the Board in line.2 A Manager of Public Participation with no power to keep the Board in line.3 Three Policy Councils, and two [possibly four] Standing Advisory Committees, and several Self-Organized Forums, each of which individually, and all of which in the aggregate, have no power to keep the Board in line.4

It's not enough. Even assuming that ICANN ver. 2.0 is able to constitute "an international Board of Trustees composed of serious, competent people," they will act as even serious and competent people have always acted throughout history and will always act: if they are in positions of power, they will seize that power unless something stops them from doing so.

Two features of ICANN version 1.0 - an At-Large membership, and an Independent Review Board - were designed with precisely this task in mind. Both have been eliminated in the Lynn proposal, and nothing has been put in their place.

We will have, not to put too fine a point on it, a monster on our hands.

Keeping the Board in its Place

A few words about the At-Large membership and Independent Review Boards. As those who have read my various rants over the past 5 years, at icannwatch.org and elsewhere, are aware, I have never felt that an At-Large membership with the power to elect representatives to the Board was, in and of itself, a sufficient guarantor against the tendency towards Mission Creep. Not that this was necessarily a bad idea; just that it wasn't enough. James Madison showed us why, 200 years ago. The Framers of the US Constitution were genuinely, and deeply, puzzled by developments after the War of Independence; the 13 State governments were not only ineffective, they were oppressive, trampling regularly on individual rights that were "unambiguously" protected in the various State constitutions. How could this be? The State governments were all on sound "representational" footing, run by elected representatives chosen by the people at large. And if the people were in control, instead of an arbitrary, hereditary monarch, why weren't individual rights secure?

The answer, Madison realized, was this: "framing a government," he wrote, requires solving two great problems: "You must first enable the government to control the governed" [effectiveness], "and in the next place oblige it to control itself" [mission creep]. As to mission creep, "no man should be allowed to be a judge in his own cause"; if the elected representatives were themselves the judges of the extent of their own power, they would, you could be sure, take an expansive view of that power, to the detriment of their subjects.

The solution? "Ambition must be made to counteract ambition." There have to be other institutions that are themselves trying to expand their power, competing, as it were, with the elected representatives; only through this dynamic balance of competing interests, each seeking to expand its sphere of influence at the expense of the others, can a "gradual concentration of power in one hands" be avoided.

What does this have to do with ICANN version 2.0? Everything. Whatever words we use to describe the ICANN mission, and however the Board is constituted, and whatever good faith and competence Board members bring to the task, without someone or some thing pushing back against them, the limitations on the scope of their activities will vanish.

The ICANN By-Laws call for the creation of a body (the Independent Review Panel) to conduct "independent third-party review of Board actions alleged by an affected party to have violated the Corporation's articles of incorporation or bylaws." Though the I.R.P. has not even yet been formed, Lynn is already persuaded that it will only get in the way:

"There is no justification, and no necessity, for any process that would allow some other body . . to override a Board of Trustees decision. There is no assurance that body would always act appropriately, and thus it is likely we would eventually hear calls to review the IRP decisions in some way . . . For ICANN to function effectively, there should be a clear and final decisional authority. That should be the Board of Trustees."

That's true: there is no assurance that the IRP will act appropriately, just as there is no assurance that the Board will act appropriately. With all due respect, that is precisely the point. The Board itself will serve to keep the IRP within the scope of its activities (by refusing, say, to implement an IRP decision it feels is "inappropriate") and the IRP will serve to keep the Board within the scope of its activities (by overturning Board decisions that are not consistent with a clearly-stated ICANN mission). No, this is not a formula for the most "effective" or "efficient" Board; that too is the point.

I'm not eternally wedded to the idea of an IRP; there may indeed be other ways to solve this problem. But the problem is that Lynn doesn't offer any. "With a properly funded and independent Ombudsman in place," he writes, "there is neither a need or justification for some independent review mechanism process that creates a 'super-Board' for some purposes." While reasonable people can disagree about many things in the Lynn proposal, this one seems to me to be incontrovertibly incorrect. Without any truly independent power base, no true personal stake in seeing that the Board is reigned in, the Ombudsman will fail. The outcome is entirely predictable: the Ombudsman will yell and scream about something the Board has done; the Board will ignore the yelling and screaming; there will be some measure of public outrage; it will die down; the Board, annoyed at the Ombudsman's increasingly shrill public comments, will reduce funding and support for the Ombudsman's activities; the Ombudsman will resign in frustration and go back to doing something useful with his/her life.

It's a recipe for disaster, and we should not let it happen.



1 Elsewhere Lynn writes: "It is now time to recognize that effectiveness in the management and coordination of name and addressing policies is the primary objective of ICANN," which I take to be a restatement of the same point.
2 Not only will the Ombudsman have no actual power to reverse or revise Board decisions, but it will be entirely dependent on the Board for the "support staff and other resources" that Lynn himself recognizes will be "necessary to carry out its responsibilities effectively." Not a recipe for the exercise of any serious control over Board actions.
3 As with the Ombudsman, see note 2, the Manager of Public Participation will be completely dependent on the Board for resources, staff, etc.
4 Lynn writes that these "Policy Councils should clearly be identified as advisory bodies, and their advice to the Board of Trustees should be given strong weight based on its persuasive merits, but not presumptive validity." This does not mean, he assures us, that "the ICANN Board of Trustees will be able simply to ignore advice from its Policy Councils." Actually, that's precisely what it means. Even if, as he proposes, the Board is "required to carefully consider any recommendations from its Policy Councils, and to clearly set forth its reasons in the event it chooses to not accept those recommendations," what good will that be when it is the Board itself that will decide whether it has, or has not, "carefully considered" the recommendations, and whether it has, or has not, "clearly set forth" its reasons for not following the Councils' advice?

This discussion has been archived. No new comments can be posted.
ICANN ver. 2.0 and 'Mission Creep' | Log in/Create an Account | Top | Search Discussion
Click this button to post a comment to this story
The options below will change how the comments display
Threshold:
Check box to change your default comment view
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.




This article comes from ICANNWatch
http://www.icannwatch.org/

The URL for this story is:
http://www.icannwatch.org/article.pl?sid=02/02/28/064529