ICANN ICANN Email List Archives

[ft-implementation]


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

Comments from the Arab Team for Domain Names and Internet Issues on Rev3.0 of the Draft Implementation Plan for IDN ccTLDs Fast Track Proces

  • To: ft-implementation@xxxxxxxxx
  • Subject: Comments from the Arab Team for Domain Names and Internet Issues on Rev3.0 of the Draft Implementation Plan for IDN ccTLDs Fast Track Proces
  • From: Ibaa Oueichek <oueichek@xxxxxxxxxxx>
  • Date: Thu, 16 Jul 2009 01:58:49 +0300

Please find belw comments by the Arab Team for Domain Names and Internet Issues on Rev3.0 of the IDN ccTLDs fast track implementation plan.

Best regards
Dr. Ibaa Oueichek
Chairman of the team

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


.

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

Privacy Policy | Terms of Service | Cookies Policy