<<<
Chronological Index
>>> <<<
Thread Index
>>>
[gtld-council] [Fwd: PDPDec05: Comments from CORE on latest draft]
- To: gtld-council@xxxxxxxxxxxxxx
- Subject: [gtld-council] [Fwd: PDPDec05: Comments from CORE on latest draft]
- From: "GNSO.SECRETARIAT@xxxxxxxxxxxxxx" <gnso.secretariat@xxxxxxxxxxxxxx>
- Date: Mon, 27 Nov 2006 20:10:22 +0100
Dear all,
In view of the today's teleconference, I have compiled some feedback
regarding the latest drafts. Glen, could you forward this to the GNSO
council list on my behalf?
Regards,
Werner
On Restricting the number of applications (point 7.11 in staff memo)
===================================================================
There should be no limitation on the number of applications. This
would only cause pointless antagonism between applicants would
otherwise have not problem with one another. Each application cycle
would become an arena of an all-against-all game, e.g. .web against
.mp3 against .archive.
To allocate evaluator resources properly, the best solution is to
offer a stable, predictable application cycle and to avoid useless
pressure on applicants to submit preemptive TLD applications.
a) Maintaining a minimal horizon of announced application cycles
If only on cycle is announced at a given point in time, applicants may
fear that it could be the last for quite some time. As a result, they
will rush to submit their application when in reality they would have
preferred to apply later. Applicants who need time to develop community
support and TLD policies would be pushed in submitting insufficiently
prepared applications. This would be bad for all parties involved, not
just for the evaluation team.
We therefore propose that ICANN should always maintain at least three
announced application cycles scheduled at about 6 months' interval.
It should also be clearly announced that a the application period of
the subsequent cycle will be opened under all circumstances, even if
some of the applications of earlier cycle(s) have not yet been
processed.
b) Avoiding pressure to submit preemptive TLD applications
To avoid an application stampede, especially for the first cycles, the
process must not penalize applicants who would prefer to apply in a
later cycle. Under the current concept, any potential applicant would
have to apply in the first cycle as a matter of simple defense against
other contenders.
We should avoid this race condition. Unless a protective mechanism is
added here, a potential applicant who was not able during the
application period, or who was surprised by someone else's
application for the same string, would have no other choice but to
try to prevent to creation of the TLD. This would be done trademark
grounds (it is easy to register a frivolous trademark), on string
allowability or on confusability, or worse (depending on its strength),
by starting an intense lobbying or pressure campaign that might
threaten the entire process.
We reiterate our recommendation to build a challenge mechanism into
each cycle. A challenge application would have the objective of
launching the TLD string, but with a different applicant and
potentially different policies.
The challenge period would start as soon as the application for the
string is published by ICANN. A challenge would refers to the string
itself, i.e. the challenger can have different plans for the same
string.
A challenge period of 1 month is sufficient if it merely requires the
challenger(s) would have to pay the application fee. After that, the
challenger(s) might be given 2 additional months to file the
challenging application(s). The challenging applicant(s) would from
there on be treated in the same fashion as the contender(s) who applied
during the application period.
If optional pre-evaluation hearings are used, the challenge period
could be waived for those applicants who faithfully presented their
TLD project in a pre-evaluation hearing.
The challenge application mechanism has the following benefits:
- It helps avoid an initial avalanche of applications (which in turn
could threaten the entire process)
- It helps diminishes the weight of the early cycles, improves
predictability and helps spread the workload over time
- Less confusion with trademark vs TLD concerns. In the absence of a
challenge mechanism, there is pressure on potential applicants to
hoard trademark registrations for the TLD string. With a challenge
mechanism, the challenger enters as another contender who will be
evaluated on the basis of support from the community of potential
registrants.
- Better credibility of the new TLDs thanks to the fact that
challenges were allowed.
- Better quality of new TLDs.
- There will be less opposition (on trademark, string allowability or
confusability ground)
- Less danger of litigation overall
On Auctions
===========
We do not believe that auction should be forced upon any applicant.
However, if all applicants for the same accept the principle of an
auction, then there should be no problem with it. The application form
might therefore ask the applicant if it (freely) agrees with the
principle that the TLD applied for would be auctioned, or even offer a
choice of auction mechanisms, as well as a choice of beneficiaries (if
applicable) of the auction proceeds.
Minor points
============
2.5.3.2: For clarity, we propose to use the word "oppose" instead
of "challenge" when the complainant's objective is to prevent the
creation of the TLD. This would enable the use of the word "challenge"
when a new contender comes in with the objective of launching the TLD
but to replace the an earlier applicant.
3.1: We recommend to replace the word "round" with "cycle" in this
paragraph as well.
3.2.2: We propose to replace the expression "both applicants" with
"all applicants contending for the same string" as there may be more
than 2 contenders.
---
--
Glen de Saint Géry
GNSO Secretariat - ICANN
gnso.secretariat[at]gnso.icann.org
http://gnso.icann.org
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|