[ga] [fwd] [council] teleconference / discussion fodder (from: roessler@does-not-exist.org)

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

fyi.  Of course, you're welcome to take up the discussion fodder, 
too. ;-)
-- 
Thomas Roessler                          http://log.does-not-exist.org/


----- Forwarded message from Thomas Roessler <roessler@does-not-exist.org> -----

From: Thomas Roessler <roessler@does-not-exist.org>
To: council@dnso.org
Date: Wed, 1 May 2002 18:41:25 +0200
Subject: [council] teleconference / discussion fodder
Mail-Followup-To: council@dnso.org

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>


----- End forwarded message -----
--
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