Comments on gTLD Application Guidebook

["James Seng" <james@xxxxxxx>]

Please see below on my comments.

-James Seng

------------
Section 2.1.1.3.2, p.2-8, String Requirements, Policy
Requirements for Generic TLDs:

The policy of three or more visually distinct letter or characters is
not practical for Chinese, Japanese and Korean.

Chinese, Japanese and Korean are phonetic languages and CJK characters
are used to express the phonetics. A morpheme ("word") can be
expressed in a single or two ideographs. This is quite different from
English where a single or two characters are unlikely to have any
meaning.

It should be noted that final report of the GNSO new TLDs Committee
dated 23rd May 2007 include an sub-group report specifically on
"Single and Two Characters Labels" dated 10th May 2007 recommended
that for Single and Two Characters IDN labels
(http://gnso.icann.org/issues/new-gtlds/final-report-rn-wg-23may07.htm
Recommendation #5)

Single and two-character U-labels on the top level and second level of
a domain name should not be restricted in general. At the top level,
requested strings should be analyzed on a case by case basis in the
new gTLD process depending on the script and language used in order to
determine whether the string should be granted for allocation in the
DNS. Single and two character labels at the second level and the third
level if applicable should be available for registration, provided
they are consistent with the IDN Guidelines.

Recommendation: Allow exception to the policy for Chinese, Japanese
and Korean TLD.

------------
With reference to Section 4.2.3, p.4-7, Comparative Evaluation Criteria:

The scoring system awards a minimum of 4 points to an applicant who
don't meet any criteria.

The scaling of the scoring system place equal emphasis on each criteria.

The scoring mechanism for comparative evaluation places an applicant
with substantial community support in the same boat as another
applicant without any community support.

For example, two applicants with the score of 10 and 4 will both fail
the comparative evaluation, though it would be evident that the former
applicant has signifcant community support while the latter does not.

Recommendation: The scoring scaling should place more emphasis on
Community Establishment and Community Endorsement. Instead of setting
a fixed threshold score of 11, the threshold should also be lowered
(e.g. to 9) and the applicant who leads other applicants is deem a
clear winner.

------------
With reference to Section 2.1.1.3.2, p.2-8, String Requirements,
Requirements for IDNs:

The implementation of IDN variant is of utmost importance to CJK
community as variants are often used interchangeably, similar although
not the same, as uppercase and lowercase characters in English.

Recommendation: ICANN should adopt IDN variant in the TLD with similar
to the principle outline in "ICANN Guidelines for the Implementation
of IDNs" at the TLD (
http://www.icann.org/en/topics/idn/implementation-guidelines.htm).

------------
With reference to Section 1.1.5, p.1-11 Subsequent Application Rounds:

Since many of the concepts and rules in the new gTLD RFP are new, it
would be unwise of ICANN to begin launching a new gTLD application
round without ensuring that any potential issue that arises in the
first round is resolved. One would also imagine that upon completion,
for some definition of "completion", ICANN needs to go through a round
of review and debrief in order to resolve any (hopefully) minor
glitches in the process before opening subsequent rounds.

With reference to Sections 2.1.1.1 and Section 4.1.3:

Strings that are placed in a contention set are either identical, or
visually similar such that delegating them into the root may cause
confusion.

However, in the latter case, they are distinct strings, and if the
parties within the contention set are able to address the confusion
issue via by means of business arrangement and/or technical policy,
ICANN should not preclude it as a means for resolving such contention.

Recommendation: ICANN should allow other mechanisms such as business
and technical arrangement that allows string contention to be resolved
among the parties themselves other than withdrawing the application.

------------
With reference to 1.5.1, p.1-20 Breakdown of Fees and Amounts, bullet
#5 (Dispute Resolution Adjudication Fee):

Recommendation: In order to avoid potential abuse by entities that use
their financial prowess to thwart smaller deserving players, a limit
should be placed on the number of disputes per application.

------------
With reference to Section 2.2.1, p.2-15, Technical and Operational or
Financial Extended Evaluation:

Recommendation: If an applicant fails the initial evaluation and
applies for extended evaluation, it should have the choice of engaging
the same panel that conducted the initial evaluation or a different
panel. This affords the applicant a fair evaluation process, if the
applicant thinks that the panel is prejudiced.

------------
With reference to Section 3.1.2.4, p.3-3, Community Objection:

An objector should not have the right to object to a completely
unrelated string, even if he represents a defined community.

Recommendation: In addition to the above, the objector should be
required to satisfactorily prove that the string it is objecting to
has an association to the community it represents. This does not have
to be a strong association, but that it passes the "absurdness" test.

------------
With reference to Section 3.5.1, p.3-12, String Confusion Objections
and Section 4.1, p.4-1, String Contention:

The wordings in Section 3.5.1 and Section 4.1 on String Confusion have
a slightly different meaning as the "Standard for String Confusion" in
Section 2.1.1.1

"Standard for String Confusion – String confusion exists where a
string so nearly resembles another visually that it is likely to
deceive or cause confusion. For the likelihood of confusion to exist,
it must be probable, not merely possible that confusion will arise in
the mind of the average, reasonable Internet user. Mere association,
in the sense that the string brings another string to mind, is
insufficient to find a likelihood of confusion."

Recommendation: Sections 3.5.1 and 4.1 should reference Section
2.1.1.1 on the definition of String Confusion

------------
With reference to Section 3.5.2, p.3-12, Legal Rights Objection #1,

Question: Should the Legal Rights Objection be extended beyond
appearance covering phoentic sound or meaning?

------------
With reference to Section 2.1.1.1, p.2-2 String Confusion Review and
Section 4.1.1, p.4-1, Identification of Contention Sets:

Question: Who are the String Similarity Examiners and how are they selected?

------------
With reference to Section 2.1.1.3, p.2-5 Review for Potential DNS Instability:

Question: Who is responsible to evaluate DNS stability?