[gtld-council] [Fwd: PDPDec05: Comments from CORE on latest draft]

["GNSO.SECRETARIAT@xxxxxxxxxxxxxx" <gnso.secretariat@xxxxxxxxxxxxxx>]

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