ICANN ICANN Email List Archives

[At-Large Advisory Committee]

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

Re: [alac] Suggested response to sTLD RFP

  • To: "Interim ALAC" <alac@xxxxxxxxx>
  • Subject: Re: [alac] Suggested response to sTLD RFP
  • From: "Sebastian Ricciardi" <sricciardi@xxxxxxxxxxxxxxx>
  • Date: Fri, 29 Aug 2003 20:00:59 -0300

Dear all,

We all know that introducing a new TLD is not cheap. No matter if we are 
talking about sponsored or unsponsored TLDs, It is expensive, risky and 
involves a big financial endeveaur. The article referred by Thomas is a good 
example of this. 

However, it is also true that ICANN's should address specific needs of the 
developing countries in order to perform it tasks in a real global environment. 
The digital divide is big enough at the time, and all the organizations 
involved in the development of the Internet should commit efforts to close the 

ICANN has been criticized in the past for marginalizing the participation of 
developing countries (see Shravanti Reddy article on Circle ID). Most of the 
critics seems to be unfair -from my point of view-, but some of them are right. 
I'm preparing a paper for your consideration regarding this issue.

Getting to the point, we need to understand that the introduction of new sTLD 
involves a lot of money given the existent structure. We should promote 
adjustments to these structure, as Wendy noted in her draft :

In the current plan, accepting only revisions to existing applications, the 
high fee seems particularly disproportionate to the likely additional review 
needed.  Yet even if ICANN opens up the process to all applicants, as we 
recommend, it should ask only fees sufficient to compensate for evaluation of 
the proposal, an easier task if the application conditions themselves are 
minimal.  ICANN can streamline and reduce the cost of its approval process by 
approving applications conditionally, provided they continue to meet 
implementation benchmarks (e.g., you must go live by one year from now, and 
before going live you need to show us an escrow contract, a technical 
architecture plan, etc.) as their operators move forward.  Incidentally, a 
conditional approval reduces the front-loading of costs for the applicant as 
well, enabling smaller businesses to participate more easily.

We reiterate our recommendation to ask lower fees from non-profits, and to 
consider taking a portion of the fee only from the winning applicant, rather 
than making all applicants subsidize the later negotiation and implementation 
costs of the eventual winner.

Of course high application fees are only a part of the problem, but we should 
not deny or diminish it by comparing it with other costs or expenses, instead 
of look at them as a clear entry-barrier for orgz form developing nations. On 
the other hand it is true that the financial burdens caused by structural 
problems impede these organizations from applying and participate on the 
process. This needs to be solved asap, in order to guarantee a global and 
equitable development of the DNS.



----- Original Message ----- 
From: "Thomas Roessler" <roessler@xxxxxxxxxxxxxxxxxx>
To: "Vittorio Bertola" <vb@xxxxxxxxxxxxxx>
Cc: "Interim ALAC" <alac@xxxxxxxxx>
Sent: Friday, August 29, 2003 7:12 AM
Subject: Re: [alac] Suggested response to sTLD RFP

> On 2003-08-29 12:05:23 +0200, Vittorio Bertola wrote:
> > If we get rid of the idea that ICANN is the central planner of
> > the Internet (at least for the addressing part), so everything
> > that ICANN approves must be rock solid and lasting forever, and
> > get back to the simpler but more effective idea of competitive
> > trial-and-error on the market, I think we can start to understand
> > that there could be plenty of new TLDs started on volunteer work,
> > where the application fee might actually be the major non-sunk
> > cost - and some of them might actually bring forward new ideas
> > and have a significant impact on the DNS.
> See "structural reasons" in my previous note.
> -- 
> Thomas Roessler <roessler (at) does-not-exist.org>

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

Privacy Policy | Terms of Service | Cookies Policy