Re: [wg-c-1] Wecome to Drafting Committee 1

[Jonathan Weinberg <weinberg@mail.msen.com>]

Javier --

	I don't want to make unecessary trouble, and I've got no ax to grind here,
but I think the procedural approach you suggest would be a bad mistake.
There are two polar views represented in this working group on ICANN's role
in the expansion of the name space -- each view is respectable.  One is
that ICANN must decide the names and charters of any new gTLDs, so as to
"give stability to the Internet."  Another is that ICANN should limit
itself to the operational aspects of admitting new registries into root
(number, speed, and the like),and let Internet users themselves decide
which of the new TLDs they will patronize and which they will not.
Personally, I see merit in both positions.  I don't see, though, how we can
carry out our mission if somebody decrees, in advance of debate, that all
discussion must assume the correctness of the first view -- that any
discussion of the merits of the debate is forbidden.

	That would be a bad idea for three reasons.  First, it would open up the
working group's (and the DNSO's) conclusions to political attack --
proponents of the second view will be able to argue that the debate was
rigged, that they were not allowed to advance their views.  Second, it
would vitiate the consensus-building that we are supposed to be engaged in.
 And third, it is completely unnecessary.  If the vast weight of argument
is on the side of the view that ICANN *should* decide the names and
charters of the new gTLDs, then it will be a simple matter for this group
to reach that conclusion as a matter of substance.

	You've argued that our consideration of this debate is inconsistent with
the WG1 charter, which you drafted, and which the incomplete Names Council
approved.  I take it that you're referring to the second word of the second
line of question 1: "Which?"  That word, though, doesn't disable us from
considering this issue -- assuming that WG1 decides that ICANN should be
deciding the names and charters of the new gTLDs, then it will indeed have
to answer the "which" question.  I don't think the Names Council believed
that, in approving the WG1 charter, they were declaring the issue of
ICANN's role off-limits to debate.

Jon


Jon Weinberg
Professor of Law, Wayne State University
weinberg@msen.com



At 10:55 AM 7/10/99 +0200, Javier wrote:
>John,
>
>Your analysis of the situation that has been discussed is very clear, but
>it moves away from the charter of this drafting committee. We have been
>asked by the Names Council some specific questions that we are supposed to
>answer.  
>
>>*	Should ICANN, in expanding the name space, consider the names or charters
>>of the particular TLDs seeking authorization, so as to achieve policy goals
>>relating to the structure of the expanded name space?
>
>The dilema can also be stated as: should it be the internet community the
>one to define the names of new gTLDs or should it be the arbitrary decision
>of some entity that has been selected as a registry.
>
>To me the answer is very clear: It should be the Internet community. That
>is why the DNSO has been created and also why this drafting committee has,
>in its charter (approved by the Names Coucil) these specific questions.
>
>>  Or should it
>>consider only the number of new TLDs, and the speed at which they should be
>>added, leaving the structure of the expanded name space to the marketplace?
>
>The structure of the registry system is dealt with by Drafting committee 3.
>
>The idea is to build a constructive policy that will give stability to the
>Internet. Our goal is to define what this policy should be and recommend it
>to ICANN. We are not at all concerned with anybody asking ICANN or anybody
>else for a private TLD. Many of us believe that gTLDs should be managed on
>a non-profit basis, but this is being discussed in a different drating
>committee.  Drafting Committee 1 is not concerned with registries.
>
>> But unless we can reach adequate consensus that
>>ICANN *should* be considering the names or charters of the particular TLDs
>>seeking authorization, then we're not in a position to consider either
>>"what should the new TLDs be" or whether they should have charters.
>
>Again, our goal is not to discuss our charter. We have joined a drafting
>committee that has to answer some very specific questions. 
>
>>1.  Should there be new gTLDs?  If so, how many?
>>
>>2. If there are to be new gTLDs, should they be introduced all at one time,
>>one at a time, or in groups, and over what time period? 
>>
>>3. Assuming that a limited number of new gTLDs is to be deployed over a
>>period of time in the near future, how should ICANN select the gTLDs to be
>>deployed, and the registries deploying them?
>
>We are the ones who should recommend which ones should be deployed.  ICANN
>executes policy that it approves, but the policy has to come from the DNSO.
>Registries are not the concern of DC 1.
>
>>  Should it consider the names
>>or charters of the particular TLDs seeking authorization?  
>
>"TLDs" do not seek authorisation. TLD are not entities. Please do not take
>this as sarcasm, but TLDs do not know how to write an application. A person
>may apply to ICANN. Anybody can apply for anything they want to anybody
>they want, but this is not our concern here.
>
>One of the goals of our drafting committee is to figure out which and how
>many TLDs should be deployed
>
>>If so, what
>>should the new gTLDs be?  In what order should they be introduced?  Should
>>each one, or certain ones, have a specific charter? In other words, should
>>some gTLDs be limited to use by certain entities, and if so should the
>>limitation be mandatory?
>
>A charter could not only limit the type of organization that could have it,
>it could also limit the type of contents (would this be considered as
>censorship?). 
>
>>  If the limitation is to be mandatory, what should
>>be the enforcement mechanism and who should be the enforcement body? 
>>
>>4. What should be the mechanism for developing new gTLDs after the first
>>new gTLDs are deployed?
>
>Javier
>
>
>