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