<<<
Chronological Index
>>> <<<
Thread Index
>>>
[gtld-council] [Fwd: CORE Feedback on current newTLD PDP report]
- To: gtld-council@xxxxxxxxxxxxxx
- Subject: [gtld-council] [Fwd: CORE Feedback on current newTLD PDP report]
- From: "GNSO.SECRETARIAT@xxxxxxxxxxxxxx" <gnso.secretariat@xxxxxxxxxxxxxx>
- Date: Thu, 12 Oct 2006 18:23:39 +0200
Please see the comments from CORE.
Dear Committee Members,
Please find below some comments form CORE on the Committee's current
draft for the final report for the new TLD PDP.
Regards,
Werner
1. Revolving Application Cycle
==============================
1.1. Cycles and Periods, not Rounds
-----------------------------------
We were busy discussing concepts and ended up using unclear or
misleading terminology. This could be fixed as a minor update to
the current draft. (REF: 3.1.1.)
We should avoid the word "round", as "rounds" come at irregular
intervals. This creates the uneasy feeling that the next "round"
could come 4 years later (as has been our unintended track
record). The potential applicants must have certainty as to when
Cycle "N+1" begins before deciding to jump on Cycle "N".
The word "cycle" implies regular intervals. There should be at
least two cycles per year, so that nobody feels penalized by
having missed a cycle.
Each Application Cycle has Periods and Deadlines. For instance,
each Cycle logically starts with an Application Period ending at
the Application Deadline. The Application Period ends with a
Deadline. There is no problem the tail Application Cycle "N"
overlaps with the head of Application Cycle "N+1".
Ideally, we should envisage 2 starts of Application Cycles per
year.
1.2. Cycles eliminate the need for "Apply-as-you-go"
----------------------------------------------------
As long as TLDs are not introduced by the hundreds of thousands,
there is no need for an "apply-as-you-go" paradigm. On the
contrary, apply-as-you-go would be more costly for everyone. A
cycle-based system has the advantage that all parties' attention
is focused on the things allowed for that juncture.
Ideally, the cycles could be linked to the ICANN meetings.
1.3. Pre-Evaluation Hearing
---------------------------
The quality of applications suffers if the applications are
prepared in an environment of secrecy and mistrust. Not only does
it lead applicants to make avoidable mistakes, but may push them
to spend more effort on fighting each other than on creating a
useful TLD.
To solutions could be Pre-Evaluation Hearings, either optional
with an incentive, or compulsory.
In case of a voluntary pre-evaluation hearing, the applicant may
present the proposed TLD at a special session at an ICANN meeting,
prior to sending the application. The audience includes experts
who assess if the application has a realistic business, financial,
technical, and operational plan. The incentive could be that the
pre-evaluation hearing would allow a shortened challenge period.
In case of a compulsory pre-evaluation hearing, all applicants
would pre required to have presented the project at an ICANN
meeting prior to being able to send in an application.
Pre-Evaluation Hearings also enable ICANN to plan ahead and
devote appropriate resources for each upcoming cycle.
1.4. Challenge Period
---------------------
Good TLD projects require homework. But our current draft
penalizes anyone who tries to do the homework seriously. This is
particularly hard for TLDs that require consensus-building and
policy development in the respective community prior to the filing
of an application. They would automatically lose against a badly
prepared rogue application for the same string.
This can be resolved with a Challenge Period. The Challenge
Period would logically start on the day of publication of the TLD
applications filed. It could have a duration of 1 months. Any
potential applicant who did not file for that TLD string would be
allowed to file a Challenge Notice and pay the Application Fee.
The Challenge notice must be for the same string, or a confusably
similar string. The application fee must be paid during the
Challenge Period. The Challenger then has until 3 months after the
end of the Challenge Period to submit a competing application.
That application will then be treated as if it had been sent
during the Application Period. If the challenger files no valid
application, its application fee is not refunded, but accrues to
the challenged applicant(s)'s account with ICANN.
In all, this gives a challenger four months to react to the
announcement of a TLD application for a given string.
2. TLD Requirements
===================
Our current draft for String Criteria (REF:2.5.2) is "boolean":
a given TLD string is either acceptable, and anyone can apply for
it with any project, or it is deemed to be unacceptable as a TLD.
Many strings, by their very nature, are acceptable as TLDs if
certain criteria are met.
We propose to divide String Criteria into two components:
* String acceptability (with the current content of 2.5.2)
and
* String-Specific TLD Requirements (with new content).
The String-Specific TLD Requirements can be a separate document
that evolves over time, based on input from civil society
organizations, the GAC, registration interests and business
interest. It specifies criteria that must be met by TLDs whose
string has a given property.
A given TLD string may have a number of properties listed in the
String-Specific TLD Requirements. In this case, the TLD
application must satisfy the criteria for all the properties.
3. Compulsory Arbitration: take ICANN out of the Shooting Range
===============================================================
Many Committee members were concerned about comparative
evaluations. The truth is that there is no way out of them.
However, it is better if ICANN only makes a preliminary
determination. If the applicants accept it, this is perfect, and
this may indeed often be the case.
If one contending or applicants does not accept ICANN's
preliminary determination, a new comparative evaluation must be
made by an arbitration panel. The arbitration panel is selected by
a recognized arbitration forum.
The process should therefore call for ICANN to specify a default
arbitration forum. Moreover, the TLD application form should
require each applicant to specify an ordered list of three
additional international arbitration forums.
Each contending party may accept to enter into a proceeding at
any one of an adversary's previously stated forums. If there is no
agreement on the choice of the forum, the applicants are asked to
submit the case to ICANN's default arbitration forum.
The arbitrators decide on the basis of ICANN's TLD criteria and,
if the criteria do not suffice, public policy considerations.
--
---
CORE Internet Council of Registrars http://corenic.org
WTC II, 29 route de Pre-Bois, CH-1215 Geneva, Switzerland
Tel +4122 929-5744 Fax +4122 929-5745 secretariat@xxxxxxxxxxx
--
Glen de Saint Géry
GNSO Secretariat - ICANN
gnso.secretariat[at]gnso.icann.org
http://gnso.icann.org
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|