<<<
Chronological Index
>>> <<<
Thread Index
>>>
[council] teleconference / discussion fodder
I may not be able to participate in tomorrow's telephone
conference.
However, I'd like to give you some discussion fodder for tomorrow:
Please pay attention to the interaction between the beneficiaries of
ICANN, the policy-making process, and the enforceability of
policies.
Basically, there are two models:
1. A cooperative effort between registrars, registries, and
registrants, for the mutual benefit of all these parties. This is
the description of ICANN which Roger Cochetti asked to be included
with recommendation 1 during one of the earlier calls. In such an
ICANN, there is basically neither a need for policy enforcement, nor
a need for a robust consensus process: Policy would only be made in
win-win situations for all the parties involved, and there would be
obvious economical incentives to adhere to policy. In such an
environment, the current consensus-based process is no problem at
all: Consensus could easily be reached on policies which are for
the benefit of all parties involved, and it would never be reached
for policies which are not beneficial for any one of the parties
involved. Such policy-making would have to happen outside the
ICANN policy-development process - either formally, or by ignoring
process. (*) Such an ICANN could work as designed, but it would
leave lots of interests unsatisfied, and it would certainly not be
"effective."
The current structure and processes are quite close to this
approach.
(*) More precisely: The registrants are in an inherently weaker
situation in this setting. Registrars and registries may be able to
establish [inside _and_ outside the process!] policy which is
slightly detrimental to registrants if they can hope that the gain
from such policy outweighs the cost of registrant dissatisfaction.
Parties which can create a credible thread of generating outside
costs (through litigation or lobbying) may find this approach
attractive, just like registrars and registries.
2. An ICANN which can, if needed, impose policy on some players when
it's for the benefit of the public, or of users - even when such
policy would _not_ be for the benefit of some of the parties
involved. Obviously, such policy will hardly be made in a true
consensus-based process: Either, there would be open disagreement,
or there would be more or less hidden attempts to otherwise prevent
the process from coming to an end - think about filibustering,
re-iterating procedural questions, and so on. I'm rather sure that
most of you know what I'm talking about. Such an ICANN needs two
things: (a) A policy-making process which is able to deal with
players who actually don't want policy to be established. Such a
process must create an incentive for those parties. Tight deadlines
("either you collaborate, or it will look worse for you than it has
to") can be one incentive of this kind. As stated before, such a
process could _not_ be truly consensus-based. (b) Credible
policy-enforcement mechanisms. If policy which is not for the
benefit of those who have to implement it is not enforced, it's
ignored.
Note that the Lynn plan apparently tries to address these problems,
and suggests an ICANN which is actually able to enforce policy.
Also note that it's rather natural for (at least!) the gTLD
registries to resist such a structure, while it may be more
attractive to registrant-oriented constituencies.
I'd suggest that, before you start discussing individual policy
development mechanisms, you come to some agreement on what kind of
ICANN you are talking about. It may, in fact, be helpful to
investigate structures for both kinds of ICANNs, and to clearly
indicate which of these approaches bears greater benefits for which
constituencies. In particular, it's nonsense to discuss robust
policy-making in a purely consensus-based setting, just like it's
nonsense to suggest self-interested, consensus-based policy-making
in an environment where policy is supposed to be imposed on some of
those who participate.
--
Thomas Roessler <roessler@does-not-exist.org>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|