<<< Date Index >>>     <<< Thread Index >>>

[alac] Final gTLD document



This is the final version of our gTLD comment document. We are releasing it right now.



ALAC Response to the Proposed sTLD RFP and Suggested Principles for New TLD Processes

The At Large Advisory Committee welcomes the opportunity to provide
comments on ICANN's proposed "Establishment of new sTLDs: Request for
Proposals."

As we have previously indicated, ALAC supports an expansion of the gTLD
namespace that allows both sponsored and unsponsored names.  We
understand that the current proposed RFP limited to sponsored TLDs, is
suggested as a continuation of the "Proof of Concept" testbed.  First,
therefore, we offer suggestions for making this limited expansion more
equitable.  We further urge ICANN to move quickly beyond "testing" to
more open addition of a full range of new gTLDs in the near future, and
offer some general principles to guide that expansion.


Concerns regarding the sTLD RFP

The proposed sTLD RFP is not an equitable way to address even its
limited goals.  It errs in unduly restricting the class of potential
applicants and in imposing substantial fees for re-submission.


Anyone Should Be Eligible to Apply for a New TLD in the Upcoming Round.

The proposed sTLD RFP calls for "revised applications" only from
unsuccessful applicants for sponsored TLDs from the Fall 2000 round.
This limitation of the applicant pool is unfair -- both to those who
might wish to submit new proposals and even to those who participated in
the ICANN process in 2000 by submitting applications for unsponsored
TLDs.  Moreover, limitation of the applicant pool to a narrow class of
prior applicants is unrelated to any reasonable objective.

Restricting eligible new TLD proposals to year 2000 applicants
submitting proposals closely following their old applications mandates
ignorance.  ICANN would be ignoring the economic development of the past
three years, and would be forcing applicants to ignore the collective
experience of the Internet community in the past three years, willfully
blind to ignore today's market environment.  TLD proposals that may have
looked promising during the dot-com boom may look uninteresting now;
while new ideas for TLD proposals may have arisen since then.  ICANN's
restrictive proposed RFP would deprive the community of the opportunity
to hear new, innovative, and viable sTLD proposals suitable for the
post-.com Internet.  It would be little surprise if this outdated "test"
failed.

Instead, several characteristics of the new TLD program in 2000 make it
appropriate to expand current consideration beyond the applications (and
a mere subset of those) for the "proof-of-concept" then:

- Although Fall 2000 new TLD applicants were asked to classify their
proposals as "sponsored" or "unsponsored," and to submit additional
materials if choosing "sponsored," the distinction did not carry nearly
so much weight then as it is now being made to bear.  Sponsorship was
merely one of several characteristics among which applicants could
choose.  Clearly applicants could not have known that they were
foreclosing themselves from later consideration by choosing
"unsponsored" in 2000.

- Nothing in the criteria announced in August 2000, prior to submission
of applications, indicated that sponsored TLDs would be given any
special priority, such that applicants would be encouraged to choose
sponsored over unsponsored where either type of operation would fit
their needs.  "The evaluation of delegation of policy-formulation
functions for special-purpose TLDs to appropriate organizations" was
only the seventh of nine criteria for evaluation.
<http://www.icann.org/tlds/tld-criteria-15aug00.htm>

- Further, ICANN's evaluation of the 2000 new TLD proposals did not
distinguish between sponsored and unsponsored as a major category in its
report, instead looking at general/specific purpose,
restricted/unrestricted use, and new services.  The report suggests that
even after reviewing all applications submitted in 2000, the evaluators
did not believe the distinction was significant.
<http://www.icann.org/tlds/report/>

- Finally, nothing in the lead-up to the 2003 process has ever indicated
that preference would be given to past applicants for sponsored TLDs.
This decision frustrates those who expected to be able to apply for
future TLDs even if they had not previously applied or planned to change
the nature of a previous application based on interim experience.

- A likely effect of limiting the pool of possible applicants in the
proposed RFP would be to create a secondary market for failed sTLD
applications, without improving the quality of those in this round.

ICANN is presumably continuing the "proof-of-concept" because it
believes it is learning something from the testbed process, yet limiting
applications to a narrow selection of those unsuccessful three years ago
deprives the Internet community of a meaningful chance to use the
experience of those years.  Moreover, at the slow pace of ICANN's new
TLD roll-out, missing the opportunity to apply in the continuing
"proof-of-concept" phase imposes a significant hardship on would-be
sponsors.  If ICANN is committed to making the testbed a representative
evaluation of new TLD policies, it must open the application process to
all who fit its substantive criteria.


High Application Fees Discourage Non-Profit and Less-Established
Applicants.

The proposed sTLD RFP would require applicants to pay $25,000 along with
their revised applications, on top of the $50,000 they paid for
consideration in the first round.  While we understand that it may be
costly to review application proposals, a lower fee would suffice to
discourage frivolous applications, while the high one also deters
bottom-up and low-cost organization of legitimate non-commercial proposals.

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.


Moving Forward

It is time for ICANN to regularize the process of examination and
approval of new TLD proposals.  Testbeds are fine, but after 5 years of
operation, ICANN needs to move beyond evaluations to permit those
proposing new TLDs to put their plans into effect.

Approving a few new sponsored TLDs chosen from a list of applicants that
was narrowed arbitrarily cannot replace the creation of a quick,
effective and uncontroversial process for the creation of any kind and
number of new TLDs.  ICANN must focus and act swiftly with respect to
this issue, which can be called the holy grail of ICANN's mission.

Further, ICANN must make more meaningful evaluations when it does
conduct reviews.  In presentations heard at the Rio de Janeiro meeting -
ICANN Paper <http://www.icann.org/riodejaneiro/stld-rfp-topic.htm>, and
Report on Compliance by Sponsored gTLDs with the Registration
Requirements of Their Charters
<http://www.icann.org/committees/ntepptf/stld-compliance-report-25feb03.htm>
- on existing sponsored TLDs, both err in focusing primarily on
exclusion: Do the sponsored gTLDs represent a limited community and
adhere to their charters by permitting registrants only from within that
community? The question more important to the public's communicative
goals, however, is the flip side: Are there people or organizations who
are left without logical places to register domain names, or who are
denied registration in a sponsored TLD whose charter they fit? That is,
are communities of prospective registrants most effectively served by a
single TLD, operated by a sponsor that purports to represent them, or by
multiple commercial players that perceive them as a market for
registrations in a number of competing top level domains?

It is easy to make the error rate arbitrarily low by asking questions
that examine only one kind of error -- gTLDs could block all
cybersquatters simply by refusing any registrations, but that would
hardly serve the point of adding new gTLDs.


Suggested Principles for Addition of New TLDs

- Competition.  Prospective registrants of a domain name in a gTLD
should have a choice -- between competing TLD strings, between competing
policies, between competing business models.  ICANN should foster, not
impede competition among different registries that access identical or
overlapping market segments.  Mutual substitutability of different gTLDs
fosters competition.

- Fairness and objectivity.  The processes used by ICANN in allocating
new gTLDs to registries must be well-documented at the outset, fair, and
predictable.  Criteria must be applied in an objective and non-arbitrary
fashion, and without undue influence from policy-making bodies or
advocacy groups on any side of the issues.

- Market operation.  An open, competitive market, not a beauty contest,
should determine what names get into the root.  The only standard
applied to new Top Level Domains should be a simple no-harm evaluation
which avoids confusingly similar TLD strings, according to some
well-defined standard such as that of consumer confusion in trademark law.

- Rapid resolution of conflicts among applicants.  When multiple parties
propose the same domain string, ICANN needs a mechanical way of
resolving conflicts.

- Technical evaluation / accreditation.  ICANN's past practice of
substantive and technical evaluation is both costly and inefficient.
Even after passing these a priori evaluations, the .pro TLD has yet to
become operational.  ICANN should consider paring this requirement down
to a minimum "competence," perhaps leaving open the possibility of
terminating gTLD contracts with registries that failed to achieve
minimum performance standards within a reasonable time.

- Business continuity.  Once a contract is approved, ICANN should ask
for data escrow and/or business continuity insurance to reduce the risk
of registry failure, but should not try to guarantee that a registry or
TLD string will live forever.  Customers can include risk evaluation in
their choice of TLDs to use; ICANN need not make this a criterion of
approving an application.

- Geographical and linguistic diversity.  As an international
organization, ICANN should ultimately work to allow applications in
major non-English languages, and should encourage a wider geographical
distribution of TLD registries.


Public Comment

ALAC invited public comment on this document and received several
substantive comments (available online at <http://forum.icann.org/alac-forum/new-gtlds/> and <http://gnso.icann.org/mailing-lists/archives/ga/>).

A few comments commended the analysis; two suggested postponing introduction of any new gTLDs, either for a period of time or until consideration of WHOIS data management was resolved. Finally, one
commenter (Michael Froomkin) suggested that the only reason we don't
have an in-hand 'evaluation' of the existing 'experiment' of new gTLDs
is that ICANN has refused to define criteria for 'success' or 'failure'
ex ante, and has failed to analyse the data itself. He concluded that failure should not stop the process to the detriment of new gTLDs, the applicants, or the public.
--
.oOo.oOo.oOo.oOo vb.
Vittorio Bertola - vb [a] bertola.eu.org
http://bertola.eu.org/    <-- Vecchio sito, nuovo toblog!