[icann-eu] Some notes on the ALSC's questions

[Thomas Roessler <roessler@does-not-exist.org>]

Alexander Svensson and I had a long conversation this evening,
partially focussing on the ALSC's questions posted today.

I'll try to summarize some of the arguments we found.  Maybe we can
actually generate some kind of micro-study for Stockholm based on
this.

First, let me recall the questions:

	What are appropriate mechanisms for input by individual
	Internet users throughout the world into ICANN?
	
	How can individual Internet users' participation be
	structured to support ICANN's effective and efficient
	fulfillment of its specific technical and administrative
	missions?

The first actual questions to look at are these: "What's input?"
And: "What does ICANN need USER INPUT for?"

You can, of course, restrict input into ICANN to the kind of input
they get all the time on their public Web forums.  This input is
nice for being counted ("we had 4000 comments on this issue, we are
democratic"), and for being ignored.  It's pretty much useless.
There is a considerable danger that trying to generate structured
input from the At Large - which might be used as a basis for
decision-making - on complex topics such as the Verisign agreemnets
or the new TLDs would suffer from similar problems.

Note that this does not mean that I'm entirely dismissing public
discussions on topics, or the "public opinion".  They do have their
value, and they may even lead to results.  But they'll be there
anyway, they'll influence any decision-making process, and they
don't need extra input channels and structure.

As a consequence, we should look for more indirect input into the
process:  For instance, the kind of input we created last year when
we elected the members of the board of directors.

Thus,

	THE SINGLE MOST IMPORTANT INPUT INDIVIDUAL USERS CAN AND
	SHOULD GENERATE IS A CONTRIBUTION TO THE ACCOUNTABILITY OF
	ICANN TOWARDS THE INTERNET COMMUNITY AS A WHOLE.

Now, why does ICANN need this kind of input?  After all, the IETF
can do without, one may argue.

Of course, this argument is flawed, since the ICANN is not a rather
open standardization organization such as the IETF.  If the IETF
screws up with some proposed standard, it won't be used, it won't be
implemented, and it will be replaced by something which works.
Remember, the IETF believes in rough consensus AND RUNNING CODE.
Basically, the IETF gathers input from users all the time, as far as
they are acting as customers on the market, accepting (or not
accepting) implementations of protocols, in turn generating interest
of manufacturers into the standardization process.  And, of course,
you always have the feedback whether or not something works.  A
fortiori, one may also look for "technical" standardization bodies
which have built-in feedback links to society as a whole.

ICANN should be looked at differently: It is the de facto (and, one
may claim, natural) monopoly on the root zone market, and it is
unlikely that this monopoly will be broken any time soon, despite
all the hopes the alt.root folks may have (I'm not discussing the
question whether or not breaking that monopoly would be desirable at
all).  In part, this is because the network effects with the DNS
root zone are much stronger than the ones with certain kinds of
protocols.  Looking at the corporation this way, much of the
criticized behaviour becomes understandable, because ICANN actually
just behaves like about any monopoly.  Trivially, there is no actual
competition on the root zone market which can be used as an
easy-to-use channel for feedback, and generate natural
accountability.

Thus,

	ICANN IS LACKING ANY NATURAL FEEDBACK CHANNELS WHICH COULD
	BE ACCESSIBLE FOR ORDINARY USERS.

(Maybe Microsoft and AOL could team up to break the monopoly. But
that's really not the issue here.)


Summarizing, the question which should actually be asked and
answered is this one: How can ICANN be endowed with the necessary
feedback and control mechanisms?  Note that this is not a pure At
Large question: Most of the DNSO's constituencies have the very same
problem, and they have experienced it in a painful way with the
Verisign decision, when the board of directors probably decided in
the best interests of the corporation (and Verisign), but possibly
not in the best interests of Verisign's competition, and generally
ICANN's customers and Internet users (which include ISPs, individual
Internet users, governments, and TLD operators alike).


The feedback mechanism which was designed into ICANN's basic
construction (let me call it Plan A) was to create a board on which
the representatives of various stakeholders are balanced with user
representatives.  Actually implementing this plan would indeed endow
ICANN with a feedback mechanism, and may possibly help to further
balance interests. However, this plan has the problem (and the
feature!) that members of the board have to decide in the best
interests of the corporation, and not of their electorate.  Also,
with the process as it's currently applied, the board can easily
"take criticism into account" without asking whether the critics are
actually satisfied (unless the NC members get their proxies right,
but that's another issue).  

In particular, we have to conclude that even directly electing at
large members to the board will not, cannot, and must not guarantee
that these board members act in the best interests of their
electorate.

Thus, Plan B may be to put the feedback and control mechanisms into
an entity which is different from the board, and is _not_ forced to
decide in the corporation's best interest.  Such an entity would
need a veto right which can be applied AFTER the board has voted on
a resolution.  The parties present in such an entity could include
representatives of internet users, the GAC, and the SOs' councils,
each with a fixed number of votes. Once a certain quorum is reached
(e.g., two of the four parties vote for veto) a board decision would
have to be revoked and reconsidered by the board.

Please note that Plan A and Plan B are not mutually exclusive.  

Also note that I don't have the faintest idea whether or not Plan B
is at all compatible with the parts of the California Code
applicable to ICANN matters.


What do you people think about all this?  Does this sound to you
like directions of thought which should be pursued further, maybe
with the goal of producing a joint mini-study to be submitted to the
ALSC?  (Or is it all just nonsense and a direct consequence of the
fact that it's way too late now?)

Cheers,
-- 
Thomas Roessler			    <roessler@does-not-exist.org>