ICANN ICANN Email List Archives

[gtld-council]


<<< 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 >>>

Privacy Policy | Terms of Service | Cookies Policy