Comments on Draft Implementation Plan for the IDN ccTLDs Fast Track Process (Rev 3.0)

["Abdulaziz Al-Zoman" <azoman@xxxxxxxxxxx>]

Dear ICANN,

 

We welcome the release of the revised version of the Draft
Implementation

Plan for the IDN ccTLDs Fast Track Process (Rev 3.0) and the supporting

documents:

   - Proposed Documentation of Responsibility; 

   - Financial Contributions to Support the Development and Deployment

     of IDN ccTLDs; 

   - Cost Analysis of IDN ccTLDs Focus on Program Development and

     Processing Costs; and 

   - Proposed Development and use of IDN Tables. 

 

 

General:

----------

- It is strongly recommended not to inter-connect issues together. 

  For example, the Documentation of Responsibilities, Financial 

  contributions, Fast track should be dealt with separately and 

  not in relation to each other.

 

- IDN and ASCII ccTLDs operators should be treated similarly, i.e., 

  the same treatment should be given to IDN and ASCII ccTLDs, 

  particularly on documented relationships and fees.

 

  The delegation of IDN ccTLDs is seen in the same light as existing 

  ccTLDs - they are for the local communities to operate for their own

  communities use. The only significant difference is that the IDN ccTLD

  provides a facility for local users to completely use the Internet in
their

  own language. Otherwise, we see no change in the status quo 

  relationship from the existing ccTLDs.

 

- There should be NO taxation for the introduction of IDN.

 

- The IDN ccTLD fast-track process should not be held back by the coming

   revision of the IDNA protocol or finalizing fast track issues.
Protocols 

   are never perfect and there seems to be revisions every now and then.

   Also, it should not be delayed by the on-going discussions on the 

   Financial Contributions and the mandating of Documentation of 

   Responsibilities.

 

The Draft IDN ccTLD Fast Track Implementation Plan and the supporting

documents raise additional topics for discussion. The following are our

responses to some of them.

 

I. Financial contribution:

-----------------------------

- There should be no difference between the existing ccTLDs and the 

   new IDN.

 

- Financial Contributions should not be made mandatory, i.e. payment 

  to ICANN by IDN ccTLD registries should be VOLUNTARY.

 

- Governments, especially of developing countries, have developmental

  objectives that should be facilitated by the introduction of IDN
ccTLDs 

  and may be hindered by financial obligations. Also, some countries are

  trying to provide domain names in the local languages not for profit 

  purposes but rather to enhance the internet usage penetration.

 

- Mandatory financial contributions will be a burden, especially for

  developing countries. Thus in a trial to solve the language barrier, 

  a cost barrier would be introduced, i.e., a mandatory financial 

  contribution is the same as depriving those countries or territories
of

  their rights to have their ccTLDs in their own languages

 

- It is also worth noting that significant work on IDN preparations has 

  taken place outside ICANN remit, including in countries and
territories

  and that those expenditures haven't been reflected in the cost
analysis

  documents. For example, the Arabic Domain Name Pilot Project

  (www.arabic-domains.org), the Arabic Team from domain names that

  works under the supervision of Arab league, United Nations Economic

  and Social Commission for Western Asia (UN-ESCWA), and many ccTLDs

  in the Arab world have incurred a lot of resources in developing 

  technical standards and implementations for IDNs, and those are 

  shared by the Internet community (e.g. gTLD registries) without any

  cost recovery.

 

II. Documentation of Responsibilities:

------------------------------------------------

- Many of the existing ASCII ccTLD registries have been administering
their

  domains successfully for a long time without such as agreement.

 

- Agreements between ICANN and IDN ccTLD operator should not be

  made a condition for IDN ccTLDs delegation.

 

- The delegation process for new IDN ccTLDs should not be used to

  "force" ccTLDs to enter into contractual agreements with ICANN.  

  In many cases, a ccTLD represents sovereignty or a
territorial/national

  right and cannot be subjected to a contract with a corporation under

  the laws of another country.  For these and other reasons, instead of
a

  uniform format of agreement between ICANN and the affected

  country/territory, a voluntary, documented relationship between the

  IDN ccTLD Operator and ICANN should suffice - just as it is available

  to existing ccTLDs. This could take the form of a contract, an 

  accountability framework, an exchange of letters or some other vehicle

  deemed appropriate by ICANN and the ccTLD Manager not violating 

  laws of respective countries. 

 

- For those operators who, for whatever reason, do not want to exchange

  documents with ICANN, a commitment to the stability and security of
the

  Internet, including compliance with the IDNA Guidelines and Protocols,

  should be sufficient.

 

 

III. Variants on TLDs:

--------------------------

- Variants are used in labels regardless whether they are TLD, 2LD, or
3LD.

  Many IDN ccTLD names in our region - Arabic Script (e.g. Saudi Arabia,

  Yemen, Kuwait, Iran , Pakistan , ...  just to name some examples) need

  their variant TLDs be in the root servers so that they can be usable
by

  the whole community. 

 

  For example, we need the Saudi IDN TLD be inserted in the root server
in

  all valid variants. That is we need 2 IDN TLDs: one with ARABIC LETTER

  YEH (U+064A) and the other with ARABIC LETTER FARSI YEH (U+06CC).

 

- Variants TLDs are needed in the root servers for IDN ccTLDs to provide
a

  complete solution to their communities.

 

- Current ICANN position (based on ICANN staff presentations on the 

  Sydney meeting) is that they understand the important of this issue

  (see the Tina Dam presentations: http://syd.icann.org/files/meetings/

  sydney2009/presentation-idn-cctld-fast-track-22jun09-en.pdf)   

  but they ONLY allow one variant to be entered in the root server and

  block the other variants.

 

- Apart from reserving or blocking the variant strings, ICANN should 

  allow the flexibility of delegating those strings to the same
requestor,

  on a case by case basis.  There are genuine needs for certain
countries

  and territories to deploy both the normal string and variant string(s)

  as their IDN ccTLDs.  

 

- Possible issues (if any) at the second and third levels caused by use
of

  variant strings at the top level should be left to the registries to
resolve

  either technically or by adopting certain policies.

 

IV. Language and Variant Tables:

-------------------------------------------

- It is important to have collaborations among communities, sharing same

  languages or same scripts, in the development of IDN tables as well as

  in identifying variants and agreeing on registration policies in order
to

  reduce any potential confusion that could result from typographic

  similarities.  

 

- IANA (language and variant tables) repository should encourage re-

  usability of tables by facilitating, for registries, comparison
between tables

  already in the repository and new tables they intend to submit.

 

- It is expected to start with a more conservative set of characters

  (properly representing a given language) and extending this set later,

  if needed, rather than the contrary. However, the Revised Proposed

  Implementation Details Regarding IDN Tables Development and Usage

  states that "An IDN Table will typically contain characters that
either 

  represent a specific language or are taken from a specific script
without

  particular reference to any of the languages that are written with
it".

  This is believed to furnish a good play-ground for cyber squatting,

  phishing and other security threats if applied at such an early phase.

 

 

Best regards,

--------------------------------

Abdulaziz H. Al-Zoman

Director of SaudiNIC, CITC

 


-----------------------------------------------------------------------------------
Disclaimer:
This message and its attachment, if any, are confidential and may contain 
legally
privileged information. If you are not the intended recipient, please contact 
the
sender immediately and delete this message and its attachment, if any, from your
system. You should not copy this message or disclose its contents to any other
person or use it for any purpose. Statements and opinions expressed in this 
e-mail
are those of the sender, and do not necessarily reflect those of the 
Communications
and Information Technology Commission (CITC). CITC accepts no liability for 
damage
caused by this email.