Re: [wg-c] about the consensus call

[Dave Crocker <dcrocker@brandenburg.com>]

At 01:05 AM 3/15/00 -0500, Jonathan Weinberg wrote:
>         I think the consensus-call approach has two strengths.  First, I 
> think the
>focus on an *application* process, rather than a process in which ICANN
>simply assembles a list of potential TLDs proposed by the world at large
>and picks its favorites, will induce ICANN to proceed with greater
>procedural regularity, and to feel a greater obligation to justify the
>choices it makes.  Second, the consensus call attempts to incorporate the
>
>         I'm coming to wonder, though, whether this vision is limited in a 
> way that

1. It will require ICANN to be strictly reactive rather than 
proactive.  You are confusing this with procedural regularity.  Regularity 
can be achieved in either mode.

2.  The idea that anything at all will make ICANN feel more obligations 
than it already does, given the intensely politicized tone of its context, 
is wrong to the level of being silly.

3.  Coupling authorization of a TLD with authorization of an organization 
to administer that TLD greatly increases the tendency to view that 
organization as "owning" the TLD.  The simple act of separating name 
creation from name administration ensures that such a view of ownership is 
utterly without merit.

4.  In a difficult debate it is inappropriate, and frankly dangerous, for 
the person responsible for assuring fair process to take on an advocacy 
role.  There is a difference between assessing which view dominates, versus 
personally advocating one.

5.  Existing gTLDs were created by IANA, not by the registry running 
them.  Given the difficulty of making progress in this realm, it makes 
sense to do as few "new" things as possible.  Stick with the established 
framework, for now, and consider modifying it after the rest of the 
necessary mechanisms are established and running smoothly.


>the selection process is bounded by meaningful objective criteria, so that
>ICANN can't exercise wholly unbounded discretion in picking the 6-10.  That
>sounds right to me: It seems to me that that concern is important.  At the
>same time, as Eric has recently pointed out (and Kent has emphasized
>previously), we haven't in fact made much progress in developing criteria
>that meaningfully limit ICANN's discretion.  I think the Sheppard/Kleiman

That is primarily due to the groups' orientation towards debate, rather 
than towards putting forward concrete specifications and working to improve 
them.


>principles -- even if we were all agreed on their content -- are too
>general to play that role.  And I'm doubtful that we'll get too far in the

At the least, their proposal has the benefit of being an attempt to be 
concrete.  Like you, I feel that it does not succeed, so it serves to 
highlight how difficult the task is.  Criteria need to be objectively (that 
is, mechanically) assessed.  The Sheppard/Kleinman list, along with the 
later modifications, is almost purely subjective.

d/

=-=-=-=-=
Dave Crocker  <dcrocker@brandenburg.com>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA