ICANN/DNSO
DNSO Mailling lists archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [council] Re: Resolutions on reform


Joe, et.al.

As I stated during the NC call yesterday, I think one large and potentially
dangers pitfall of the ERC's recommended voting allocation on the GNSO is
that there is a serious risk that many constituencies will be
disenfranchised from the ICANN process and seek solutions to their concerns
through other avenues (e.g., the U.SO. government or the courts).  This
concern should loom large as the Board considers whether to revise the
voting structure.  Why not allow the reorganized GONZO and the
well-articulated PDP come into play and see if the criticism that the ERC is
supposedly responding to subsides?  (However, I doubt it will ever subside
given that the complaints are usually from dissatisfied groups or from those
that do not share the load of work to move the process forward, but only
complain to the Board, the press and the USG).  The sluggishness with which
the DNSO has moved at times is, in my opinion as a long time participant,
more often associated with the fact that the brunt of the work is done by
unpaid volunteers that have priorities in the lives and careers far outside
ICANN.

I, too, do not want to get into a protracted debate.  I did, however, want
you to know the reason that I fully support the proposed NC resolution on
this issue.

J. Scott Evans


----- Original Message -----
From: "Joe Sims" <jsims@jonesday.com>
To: "Philip Sheppard" <philip.sheppard@aim.be>
Cc: "NC (list)" <council@dnso.org>
Sent: Friday, September 27, 2002 8:40 AM
Subject: [council] Re: Resolutions on reform


>
> Let me answer your questions this way, and then unfortunately I am
> traveling and cannot engage in an extended dialog today.
>
> On your first point, I do not believe the relevant question is whether the
> users have forced anything on the suppliers.  Under your view of policy
> development, that cannot be done in any event.  The real question is "Has
> the current structure demonstrated that it is effective in producing
> consensus policies on issues of concern to the community?"  While I am
sure
> there might be some arguments about this, many people believe it has not
so
> demonstrated.  Thus, a search for structure that might be more effective.
>
> On your second point, the conceptual rationale for the current ERC
> recommendation is that, with both sides unable to simply force their way
to
> a majority (especially given the presence of the NomCom reps), there will
> be more of an inclination to seek a consensus solution.  Of course, as in
> today's environment, one side or the other could still simply refuse to
> work toward consensus, but it will be more obvious to the rest of the
world
> that this is happening, and the views of the NomCom reps will be a neutral
> guidepost to the real positions of the parties, however they characterize
> them.  This is certainly not a guarantee of success; it may well be that
> this system fails as well, and if so, yet some other solution may have to
> be tried.  But at least this is an effort to adjust for the right reasons,
> and with the right objective; alternatives proposed should meet the same
> test, or in the alternative there needs to be some persuasive explanation
> as to why the ERC's possible improvement is instead more likely to have a
> negative impact.  So far, I have not seen either attempted.  Indeed, the
> only positive impact on this subject came from those suggesting a separate
> SO for providers, which the ERC believed would simply eliminate the
> rationale for any SOs in this area and move all policy debates up to the
> Board, which it thought not desirable.  On the other hand, as noted above,
> the consensus on the Board was that the current system had not been
> effective, and that lack of staff was not the only reason for that; this
> perspective produced the current ERC alternative.  Although it is getting
> rather late in the game, alternative ideas that seem more likely to
produce
> the desired result are always welcome.  In contrast, it is not that useful
> to just say no.
>
>
> Joe Sims
> Jones Day Reavis & Pogue
> 51 Louisiana Avenue NW
> Washington, D.C. 20001
> Direct Phone:  1.202.879.3863
> Direct Fax:  1.202.626.1747
> Mobile Phone:  1.703.629.3963
>
>
>
>                     "Philip
>                     Sheppard"            To:     "Joe Sims"
<jsims@jonesday.com>
>                     <philip.sheppard     cc:     "NC \(list\)"
<council@dnso.org>
>                     @aim.be>             Subject:     Resolutions on
reform
>
>
>                     09/27/02 08:08
>                     AM
>
>
>
>
>
>
> Joe,
> as I understand it your sole objective is to create a better forum for
> consensus decision making.
>
> (Our objection to the current strategy to achieve this are based on a
> possible scenario whereby suppliers may exploit the proposed voting
> structure in ways that resist pro-competitive or other pro-public interest
> change. You may characterise this as a potential side effect).
>
> You have argued the status quo is flawed.  Does the status quo provide
> examples of users forcing unreasonable demands on suppliers?  As users pay
> the final bill, it is not in our interests to do so.
>
> Also you have not explained why increasing the voting strength of
suppliers
> is more likely to produce true consensus. Users and suppliers will have
> issues however one jiggles about with the votes.
>
> I, and I believe, my fellow users, are open to hear this explanation.
>
> Philip
>
>
>
>
> ==========
> The preceding e-mail message (including any attachments) contains
> information that may be confidential, be protected by the attorney-client
> or other applicable privileges, or constitute non-public information.  It
> is intended to be conveyed only to the designated recipient(s).  If you
are
> not an intended recipient of this message, please notify the sender by
> replying to this message and then delete it from your system.  Use,
> dissemination, distribution, or reproduction of this message by unintended
> recipients is not authorized and may be unlawful.
> ==========
>
>
>
>



<<< Chronological Index >>>    <<< Thread Index >>>