ICANN ICANN Email List Archives


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

Comments from APTLD on the Draft New gTLD Applicant Guidebook

  • To: <gtld-guide@xxxxxxxxx>
  • Subject: Comments from APTLD on the Draft New gTLD Applicant Guidebook
  • From: "Jonathan Shea" <jonathan.shea@xxxxxxxx>
  • Date: Mon, 15 Dec 2008 20:35:51 +0800

Dear Sir/Madam,


APTLD (Asia Pacific Top Level Domain Organisation) is pleased to provide
comments to ICANN from its members on the draft New gTLD Applicant Guidebook
(referred as “Guidebook” here after) on which public comments are invited
starting 24 October 2008.  APTLD hopes ICANN can give these comments as much
consideration as possible, and we will be happy to provide more information
and seek clarifications from members as needed.


A.    General Observations in relation to the Guidebook


1. Protection of Geographic Names

APTLD endorses the paper (see attached) from the ccNSO’s Working Group on
Protection on Geographical Names on the mechanism for protection of
Geographical names as proposed in the Draft Applicant Guidebook for new
gTLDs.  Further to the views raised in this paper, APTLD would like to make
the following two points to further clarify members’ views in relation to
this Working Group paper

1.1   The gTLD introduction process and IDN ccTLD fast track (and later the
IDN ccTLD process) should if possible use the same references to identify
official languages used in a territory and when checking for the names of
countries or territories.

1.2   The ccTLDs are required by RFC 1591 to serve the local internet
communities (including the local government) in the different countries or
territories, as defined in ISO-3166-1.


2. Language Barrier:

The whole process (including consultations, documentations, forms,
communications, people involved, …) is done in English. Non-English
speaking communities would be put in behind because of the language barrier.


3. English and others:

ICANN claims to be a international body! However, it treats the world
languages differently. ICANN address languages as English and others! This
is can bee seen in ICANN's documentations, policies, and procedures. This
can be seen very clearly in the new gTLD documents. For example, the process
for English TLDs is different from that for "other' languages TLDs; there is
a need for a linguistic committee to approve IDN TLDs but it is not needed
for English TLDs.


Languages must be addressed and supported equally regardless of the location
of the headquarter of ICANN. The current technical limitation of the DNS
system, i.e. ASCII based system, should not deter the support of the "other"
languages in an equal foot.


4. Rationale:

ICANN reasoning for opening new gTLDs are not convincing, particularly, with
many skepticism from the Internet communities.


5. Consultation Period:

The consultation period (45 days) is too short for a very important issue
that has a world-wide impact.


6. Stability and Security of Local Communities Living in Harmony

Some communities (or countries) consist of multiple ethical groups with
different races, religions, sectors, languages, etc, that are living somehow
in harmony and peace just because of the enforcement of local laws and
public policies that were developed by the\ communities/countries
themselves. Now, ICANN, with the new gTLD program, is involving itself in an
area that is beyond its mandate. By allowing itself to set some public
policies to harmonize the whole (internet) it is intervening indirectly in
world cultural issues and worse, is breaching local community harmonies. If
the local community/country cultural concerns are not treated with due
sensitivity, the right for a new gTLD may ignite a civil war in that local
community! Local communities cannot depend on objection mechanism to avoid
such a catastrophe


7. Protection

The new gTLD program has a very serious deficiency with respect to
protection of values that are safeguarded by communities, countries,
nations, and governments since ancient times.  Examples of some of these
values are:

  * Geographic names (countries, cities, provinces, …, ) (See point 1

  * Religion values (holy names, scripts,  location, sectors, scholars, …)

  * Morality and public order

  * Social security (ethical differences…)

  * Local trade names/marks


8. Blurring between ccTLDs and gTLDs

The introduction of new gTLDs will blur the difference between ccTLDs and
gTLDs and would make setting new different policies (for ccTLDs and gTLDs)
more difficult.


9. User trust and confidence on these choices

It is expected that with many gTLDs in the market users will lose their
faith in the domain name system with so many variations to maybe a single
label with multiple (10s or 100s) TLDs.


10. Objection process

The objection process of the new gTLD program shifts the responsibilities
from ICANN to the communities when it is ICANN's duty to make sure that the
introduction of a new gTLD would not hurt any communities by causing havoc.
The objection process involves cost and time constraints on communities and
they will have to continuously monitor ICANN's processes so that the
introduction of a new gTLD will not harm the community's values. The
proposed model: "if you do not like it then file an objection" cannot be
used to deal with many morality and public order issues across the board.
The process would put some communities on high alert and might not wait for
ICANN to pass a verdict on a new gTLD


11. IDN gTLD

Full IDN has not been introduced (or used) by the Internet communities.
Introducing IDN on a large scale (e.g. part of the new gTLDs) while the
technology is still immature may lead to user confusion and distrust in the
IDN solution.


12. GAC gTLD Principles:

We strongly urge ICANN to adhere to GAC principles in general and in
particular the following:

  (a) New gTLDs should respect the sensitivity regarding terms with
national, cultural, geographic and religious significance.

  (b) ICANN should avoid country, territory or place names, and country,
territory or regional language or people descriptions, unless in agreement
with the relevant governments or public authorities.


B.    Specific Comments on the Guidebook


B1   Community Endorsement for IDN gTLD Applications


As most of us agreed, the Asia-Pacific region is the most diversified region
in the world. Furthermore, it is the region with the most pressing needs for
IDN TLDs, due to the diversity in language and scripts. Official Languages
and scripts defined by most countries in Asia are non-Latin letter based.


While we understand that ICANN is making effort to benefit Internet users in
languages other than English by allowing IDN TLDs to be inserted into the
root, we find the RFP, which is prepared by a third party who does not have
rich experiences with IDNs, fells short in setting up policies that address
IDN applications.


In the Guidebook, Module 2, attachment Evaluation Questions and Criteria,
Question 18, it is indicated that a “Community Based” application will be
evaluated against the following criteria in the “String Contention”

A.    Nexus between proposed string and community: String is name or
well-known abbreviation of community institution


D.    Community endorsement. Endorsement by a recognized institution or by
member organizations, including evidence of support such as meeting minutes,
voting records, or divisional or sub-organizational member endorsements.


 From the above criteria A, we could see that the drafter did not realize an
IDN TLD, which is a localized service that intends to serve a specific
language speaking community, is a “community based” TLD by itself. Thus in
turn, criteria D, has not been specific enough to address community support
for an IDN string. 


In order to better address such special requirement for IDNs, we propose
ICANN to modify the criteria A and D as following:

A.   Nexus between proposed string and community: String is name or
well-known abbreviation of community institution, or, string is in a
non-ASCII script that intend to serve users from a specific language


D.    Community endorsement. Endorsement by a recognized institution, which
must represent the interests of the most significant number of users in that
language community for an IDN application, or by member organizations,
including evidence of support such as meeting minutes, voting records, or
divisional or sub-organizational member endorsements.  


Through such modification, non-English speaking users’ interests are well
defined and protected. 


In addition to above suggestions, in Module 4, clause 4.2.3 Comparative
Evaluation Criteria, the Guidebook requires the minimum qualification score
for a“community based” application as 11. We do consider that the
qualification score of 11 points as too stringent. It may discount the value
of Comparative Evaluation process, and force competing parties to auction,
which in turn will increase cost burden for applicants. We believe that’s
not ICANN’s original intent.  We suggest to lower the qualification score
to 8 points.


In Module 4, clause 4.1.3 Self-Resolution of String Contention of the
Guidebook, although it does allow contenting parties to settle the
contention among themselves without going through Comparative Evaluation and
Auction process, the limitation on prohibiting a join venture by the parties
as a new applicant to the string is not necessary. It will increase the cost
of obtaining a TLD string and will not benefit the community as a whole.


B2   Linguistic Panels


We also have a question in relation to IDN string evaluation by linguistic
panels (Applicability of IDNs in page 7 to 9) of the "Proposed Process for
Geographic Name Applications" Explanatory Memorandum date of publication, 22
October 2008 refers.


The question is: Will the IDN string evaluation for gTLDs and ccTLDs be
performed by the same linguistic panel?   



Yours sincerely,
Jonathan Shea, Chairman of APTLD AND YungJin Suh, Board Member of APTLD


Attachment: comments on gTLD introduction-final2.doc
Description: MS-Word document

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

Privacy Policy | Terms of Service | Cookies Policy