ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Applying priority before collision

  • To: 3gtld-guide@xxxxxxxxx
  • Subject: Applying priority before collision
  • From: Werner Staub <werner@xxxxxxxx>
  • Date: Sun, 22 Nov 2009 22:47:33 +0100

The current design of the New gTLD process calls for all parties to
enter the race and only then to assign priority rights in case of

Once an organization has committed substantial resources to a gTLD
project, it is under pressure to make the most of it. The same party
would easily abandon the project or choose a different TLD string if it
had not been forced to go to great lengths before achieving certainty.

Pushing everybody into a race at the same time is a way to (a)
maximize fee income, (b) maximize litigation and collateral damage
and (c) delay the entire process (as we could see), thus further
increasing uncertainty and damage.

This is like a lottery: the uncertainty of the outcome is enhanced
artificially, and the added uncertainty puts more parties under
pressure to pay a fee (the application fee in this case).

ICANN is under no obligation to design the process as a "big bang". It
is a fallacy to believe that making everybody run at the same time is

I therefore submit that ICANN should divide the coming application
round into several priority windows:

- The first priority window should be for community-based TLDs for
which ICANN requires the approval or non-objection of the relevant
government authorities.

- The second priority window should also allow other community-based
TLDs, requiring however that the applicant demonstrate a clear and
ongoing accountability framework to its community.

- The third priority window should also allow for standard TLDs other
than single-registrant projects.

No party is disadvantaged in a multi-window process compared to a
single-window process. Virtually all TLD experts and technical registry
operators cater for all kinds of TLDs. If all TLDs came at the same
time, they would face severe resource bottlenecks. ICANN would face
even worse bottlenecks and cause unpredictable (and thus even more
expensive) delays.

Werner Staub

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy