<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [ga] Motion asking for GA poll on rebid of ICANN contract
On May 3, 2002, James Love wrote:
> Right now there are many
> proposals floating around that are quite different from the
> ICANN/Board/Staff proposals, and I believe, have much more support in the
> Internet community. For the most part, the alternatives would have either
> more of a public/user role in electing the ICANN board members, or would
> dramatically reduce ICANN's centralized power making. In a new
> competition, we would go back first principles about DNS
> management, and not
> necessarily have to work around the edges of the Lynn proposal.
Personally, I think James Love is right here about going back to first
principles. But I would really like to hear what the GA in general thinks,
which is why a vote is necessary. (I do not believe that Alexander's
multi-question response idea will get a hearing at all, since it smacks of
the tail wagging the dog). James should lead a process of morphing the
proposed wording for the vote until there's broad consensus on the wording
of it, and then there should be a vote.
Part of the ICANN problem is that too often the bottom-up constituents of
ICANN don't get organised and thus let the staff set the direction. Over the
past year the situation has got even worse as the staff have specifically
tried to move things forward by releasing fairly prescriptive policy and
operational proposals just before the quarterly meeting. The result is a
slightly panicked half-response from the ICANN constituents at the physical
meetings and then ICANN staff railroading their proposals through in the 3
month post-meeting period. In June (Stockholm) it was the alt roots issue,
in September (Montevideo) it was the ccTLD communique, in March (Accra) it
was the Lynn reform "proposal".
I personally would welcome a rebid, and would like to see a proposal which
specifically made the point that the staff has no role in *directing*
policy, as they have done over the past year. If the current version of
ICANN were running properly, the majority of the staff action should be
post-the quarterly physical meetings, implementing the result of the
consensus reached. Instead, the reality is that the majority of the staff
action is pre-the quarterly meetings and is designed to push through
policies which the inner cabal like to say represent the "will of the
internet community".
One final point - there have been plenty of vastly different proposals put
forward by various constituents within the Internet community, including an
excellent one from Paul Hoffmann and a very radical one from New.net. But I
bet any one of you that come Bucharest, the response from the Committee on
reform will be "well, there has been lots of talk but no real good concrete
alternatives put forward. So we think it's best to use Dr Lynn's proposal as
the starting point."
That's the way it works at the moment, and that's what most people feel is
the problem with the current ICANN - that the structure of the current ICANN
allows a small staff make unilateral decisions in the name of "the will of
the Internet community" claiming to act on "public trust" - all that James
Love's proposed vote is asking is whether it would be better for solutions
to start from scratch rather than work from a currently broken starting
point (that's what a call for a rebid would be doing - saying to the
community - "let's have some from-scratch proposals for reform"). And please
don't say "but then we might get the big bad ITU" - there's many who feel
that would be greatly preferable to the current mess.
I would encourage you all to read Paul Hoffman's
http://www.proper.com/ICANN-notes/dns-root-admin-reform.html, which is the
kind of thinking that could only come from someone looking at ICANN from the
outside, not from within.
andy duff
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|