Re: [ALSC-Forum] Notes on At Large Options

[Jeff Williams]

Thomas and all stakeholders or interested parties,

Thomas Roessler wrote:

> I'll try to summarize some notes on the various at large options.
> Some of this is fall-out from discussions with Alexander Svensson,
> and some of the thoughts were actually prompted by reading Esther
> Dyson's Release 2.1.  (Which is, by the way, highly recommended
> reading since it gives some hints at the kind of mindset behind
> ICANN's current structure, I think.)
>
> First, let me list some things which just won't work:
>
> - Collecting money from individuals all over the world (like in
>    Option C).  As Alexander pointed out on this list already, it's
>    kind of hard to find the right amount of money.  Let's face it:
>    What some of us pay for Internet access may be sufficient for
>    supporting a family in other parts of the world.  Thus, a
>    representation scheme which is "pay to vote" would be perceived
>    as politically incorrect, and would draw considerable fire from
>    various sources.

  A "Pay to Vote" situation is not expectable if made mandatory.
A voluntary would or could be workable if the ICANN staff
would get off it's collective duffs.  This is not likely to happen
me thinks.

>
>
>    (Also, as Vittorio noted, customers are obviously the ones who
>    ultimately pay the domain name industry...)
>
> - Require a "willingness to serve" from at large members (once again
>    Option C).  While this may be intended to be some competence
>    test, it just doesn't work out.  Being willing to serve on the
>    board doesn't mean you're competent, and being competent doesn't
>    have to imply that you want to serve on the board, or even
>    consider yourself suitable for that job.

  We certainly have seen allot of gross incompetence on the ICANN
BoD, to be sure!  :(  We have also seen such imcompatance on the
"Interim Board" in the past as well.  Many people would shy away
from serving on a BoD of any kind if the perception of the currently
sitting members of that BoD are of questionable competency.
As a result, in some instances, poor policies and "Best Practices"
are imposed upon the effected.

>
>
> - Prevent SOs from nominating candidates (ups, Option C again), but
>    let individuals nominate them.  Obviously, individuals affiliated
>    with SOs could still nominate "SO candidates".  Thus, in order to
>    get "actual at large nominations", you'd have to perform global
>    primaries, which basically means that you shift the logistical and
>    organisatorial problems from the elections to the primaries.

  Yes.  But this is not that hard to accomplish with electronic media
formats and abilities...

>
>
> - Enforcing "issue-based" parties (Option A).  Just look at parties
>    in real life: The more successful ones are rarely issue-based -
>    and issue-based parties which turn successful lose their
>    issue-centric approach.  You just won't be able to prevent a party
>    "for the welfare of country X's industry/interests" from coming to
>    existence.

  I disagree.

>
>
> That is, I don't think that Option C will work at all (in
> particular, it won't produce adequate representation of "At Large
> Members"), I don't think that Option A will work as designed, and
> I'm not sure about Option B.
>
> Option D looks so complicated that I (1) don't want to look at it in
> detail, and (2) don't think it would ever be practicable.
>
> But anyway, before we start thinking about the individual options,
> some overall idea of the direction ICANN should take would be a nice
> thing to have - and this idea seems to be lacking.

  The direction that ICANN should be taking will or should be determined
by the stakeholders.  So in order to know ANY direction the At-Large
must be free forming.  The ICANN BoD and the past Interim BoD
in particular were against this type of formation.  It seems that this
is still true.  None of the "Options" allow for free forming of the
At-Large is stark evidence of that fact.

>
>
> There seem to be two extreme directions ICANN could take, and both
> don't look desirable:
>
> 1. Pure industry self-regulation.  This is not acceptable when we
> come to regulatory realms which traditionally belong to states -
> such as the legal framework for relations between customers (think
> UDRP), or anti-trust regulation (think NSI contracts).  In
> particular, ICANN does not play on any regulatory market, but is in
> fact acting as a monopoly on that market.

  Yes a monopoly that placates to big business interests predominantly.
Ergo, special interests.

>
>
> 2. Practically re-building a classical state, and trying to solve
> about everything by a "one man one vote" scheme.  This may be the
> classical solution to the representation problems we are facing, and
> it can certainly be helpful to look at this solution for direction.
> However, there is no reason to expect a "world government formerly
> called ICANN" to work more smoothly, more efficiently, or in a more
> integer or transparent manner than any existing government.  This
> approach would also be a direct contradiction to the privatization
> mantra behind ICANN's creation (keep the governments out of the
> Internet).

  One man one vote is not a predicator to a "World Government" with
respect to ICANN or the At-Large.  It is a predicator to self regulation
by the stakeholders or interested parties.

>
>
> I'd almost bet that both approaches would lead to a break-down of
> ICANN's authority, and of ICANN's support by usual governments.
> Both are options which, I believe, shouldn't be used.

  ICANN has no authority presently.  It just thinks it does.

>
>
> Maybe a look at the _functions_ of the various layers of ICANN's
> current structure can provide at least some guidance:
>
> The SOs are supposed to be the place where consensus is developed.
> This does, in particular, imply that the ICANN process can't
> currently yield any consensus which includes individual users -
> these aren't properly represented in the SO structure.  It does, in
> turn, imply that individual users will need representation within
> the SO structure if the current consensus and SO process is supposed
> to persist in some manner or another.  Note that this is independent
> of the question whether or not or how individual users are
> represented on the board.  Also, a perception that the SOs are less
> legitimate than the board may be damaging to ICANN's internal
> equilibrium (as far as it exists).
>
> The board is supposed to be a controlling and executive body, which
> partially balances the SOs, and in practice even absorbs some of
> their functions.  This body must be balanced internally. No group of
> stakeholders should be excluded from the board.  The idea that
> supply and customer sides should be balanced on the board is nice,
> but bears some problems - in particular, registrars are on both
> sides.
>
> Of course, this structure won't survive anyway: The ccSO is possibly
> about to shot the current consensus-building process on DNS matters
> to pieces (as far as it exists), and consensus-building is moving to
> the board level - which would make balanced representation of
> interests on the board even more crucial...
>
> Finally, let me point to one thing of Option C which I really like:
> The "non-blocking, paper-passing" body through which any policy
> proposal must pass before it comes to the board level.  This body,
> as I understand it, would examine a proposed policy, and state
> whether or not the proposal actually has the necessary consensus.
> The board could still accept a non-consensus policy, but would have
> to answer lots of questions, and possibly jeopardize its legitimacy.
>
> All these are really just thought fragments.  I hope you find at
> least some of them helpful.

  On of the single biggest problems with the ICANN structure is too
many "Layers"...

>
> --
> Thomas Roessler                        http://log.does-not-exist.org/

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup - (Over 118k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail jwkckid1@ix.netcom.com
Contact Number:  972-447-1800 x1894 or 214-244-4827
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208