Egypt's Comments on Rev3.0 of the Draft Implementation Plan for IDN ccTLDs Fast Track Process ..
Below please find comments by the Government of Egypt on Rev3.0 of the IDN ccTLDs fast track implementation plan (also attached in pdf format) .. Kind Regards Manal Ismail National Telecom Regulatory Authority of Egypt Egypt GAC representative --------------------------- Comments by the Government of Egypt on Rev3.0 of the Draft Implementation Plan for IDN ccTLDs Fast Track Process & Supporting Documents * Egypt welcomes the issuing of Rev3.0 of the "Draft Implementation Plan for the IDN ccTLD Fast Track Process <http://www.icann.org/en/topics/idn/fast-track/draft-implementation-plan -cctld-clean-29may09-en.pdf> " along with all supporting documents and welcomes the opportunity to comment on those documents. * Egypt believes that the Documentation of Responsibilities and the Financial contributions should be dealt with separately and not in relation to each other, i.e. An IDN ccTLD manager may go through a formalized relationship without being able to provide financial contributions and vice versa. * Egypt is of the view that, in principle, IDN and ASCII ccTLDs operators should be treated similarly and that the GAC principles and guidelines for ccTLDs equally apply. * Egypt believes that discussing the Financial Contributions and the mandating of Documentation of Responsibilities should not delay the whole process of the Fast Track. On the relationship between ICANN and IDN ccTLD Managers * Egypt supports splitting the discussion into three issues: content of obligations, form by which those obligations are documented and if those obligations can be enforced and believes that this approach would facilitate the discussion and help better understanding and better dealing with special cases. * Egypt welcomes ICANN's flexibility regarding the form of the relationship between ICANN and IDN ccTLD managers by considering the Application Form as one way to indicate intention to adherence to standards. On the financial contributions * Egypt believes that financial contributions should be kept voluntary. * Egypt believes that the cost estimated for the processing of each new IDN ccTLD request is prohibitively high and would introduce a financial barrier for IDN ccTLD managers especially from developing countries. * Egypt believes that the proposed revenue percentages still needs further discussion between ICANN and IDN ccTLD operators. * Significant work on IDN preparations has also taken place at the IDN ccTLD registries' side and those should also be taken into consideration. On development and use of IDN tables and character variants * Egypt notes the importance of collaboration 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. Egypt believes that such community efforts are necessary and should feed into the fast track process for the benefit of both ccTLD registries & gTLD registries. * Egypt notes the benefits of having, within the IANA repository, clearer and fewer language tables, in terms of encouraging re-usability not excluding languages. Egypt hence believes that language tables should be well structured and well documented in order to help developing technical solutions and in order to encourage re-usability of tables by facilitating, for registries, comparison between tables already in the repository and new tables they intend to submit. * Egypt believes that there should be common understanding of all terms in use. In particular, when using the term variant, it is still not clear whether this refers to only confusingly similar strings (i.e. visual confusion) or also includes domain names written in a language that may be represented by more than one script (i.e. semantic similarity). * Following technical experts' advice, Egypt notes the merit behind starting with a more conservative set of characters (properly representing a given language) and, if needed, extending this set later rather than the contrary. However the Revised Proposed Implementation Details Regarding IDN Tables Development and Usage <http://www.icann.org/en/topics/idn/fast-track/proposed-implementation-d etails-idn-tables-revision-1-clean-29may09-en.pdf> 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." Egypt believes that, at such an early phase, supporting characters without particular reference to any of the languages they are written in would facilitate cyber squatting, phishing and other security threats. * Egypt supports the delegation of IDN ccTLD string variants to the same applicant. However the Revised Proposed Implementation Details Regarding IDN Tables Development and Usage <http://www.icann.org/en/topics/idn/fast-track/proposed-implementation-d etails-idn-tables-revision-1-clean-29may09-en.pdf> states that: "However, comments on that proposal have indicated that allocation of variant strings would cause technical stability problems for the name space." It is not clear what technical stability problems would be caused by delegating variants to the same applicant where confusingly similar variant strings are aliased to avoid confusion. It is also not clear whether reference here is made to visual similarities, semantic similarities or both. The document also states that: "The proposal made by ICANN in the previous version of this paper (as mentioned above) was to delegate the variant strings separately and then require that the TLD manager ensures duplication of the multiple zones. However, the technical complication with this proposal is that while a registry manager can duplicate zone immediately under a TLD, this will not function at lower levels. This would put a requirement upon the registrants (and their sub-domains) to duplicate zone contents at lower levels as well. There is no mechanism to ensuring that this takes place. Guaranteeing certain handling of variants in second and lower level domain names should not be a condition for delegation of IDN ccTLD variant strings as there is no mechanism to ensure that this would take place all the way down the DNS tree. ------------------------------------ Attachment:
Egypt Comments on Rev3 of the Draft Implementation Plan for IDN ccTLD FT Process - Final.doc.pdf |