Dear all, Thank you for sharing the outcome of IGV in Bali especially on the linguistic issue, which is one of projects to be explored and partnered with ones concerned at the ITU Connect Asia-Pacific Summit, 18 November 2013, Bangkok, Thailand: http://www.itu.int/en/ITU-D/Conferences/connect/Asia-Pacific/Pages/default.a.... Although many of you may not be able to attend our Summit due to the ICANN meeting at the similar time, I would like to explore cooperation and partnership to work together to serve the needs of countries in the future. Dear Aurora, Please review this for a possibility of cooperation on the issues concerned. Best regards Eun-Ju Kim Regional Director for Asia and the Pacific ITU From: rigf_discuss-bounces@dotasia.org [mailto:rigf_discuss-bounces@dotasia.org] On Behalf Of Rinalia Abdul Rahim Sent: Monday, November 11, 2013 8:28 AM To: apralo; rigf_discuss@web2.dotasia.org; At-Large Worldwide; ISOC Chapter Delegates; ALAC Working List; No name Subject: [Rigf_discuss] New Procedure for the DNS Root Zone Affecting Linguistic Diversity at the Top Level Dear Colleagues, At the recent Internet Governance Forum in Bali, a workshop was held to share information and discuss implications of a new procedure that will affect the DNS root zone and allow the delegation of IDN variants at the top level. Variants are considered important for many languages used by the global population. Attached is the full report and I paste below the summary of the issues discussed for your information. Best regards, Rinalia ----- Note: * The process of implementing the procedure is currently underway with the most immediate need being the establishment of Generation Panels for 17 scripts that have IDN TLDs requested under two TLD programs - the country code Top Level Domain (ccTLD) Fast Track program and the New generic Top Level Domain (gTLD) program. Prioritization of the 17 scripts does not exclude other script communities from moving forward to form Generation Panels. The 17 scripts that have IDN TLDs requested are: Arabic, Bengali, Chinese, Cyrillic, Devanagari, Georgian, Greek, Gujerati and Gurmukhi, Hebrew, Japanese, Korean, Latin, Sinhala, Tamil, Telugu and Thai. A significant proportion of the scripts are Asian language scripts. Main Issues Raised Spillover benefits of the Root Zone Label Generation Rules (LGR) development * The development of the Root Zone LGR, though focused on the top level of the Root system, has applicability at the second and third levels in terms of guidance for dealing with variants. * The ICANN rights protection mechanism for trademark owners in the new gTLD program is currently not addressing variants in an integrated way due to the legacy mentality of only thinking in terms of Latin script and ASCII for solutions. * The Root Zone LGR is expected to guide ICANN's implementation of key TLD initiatives involving variants in the future. The complexity of variant management * Variants are complex and what is defined as variants tends to differ from language to language. * Visual similarity is a major concern that is shared across languages and scripts. Complex scripts with characters that change shapes depending on adjoining characters require a rendering engine at the Operating System and browser level for accurate visual representation. * Challenges in grappling with variants include achieving consistency across and within TLDs, dealing with the innumerability of variants, having the right tools to deal with the technical challenges of managing IDNs and ensuring that IDNs are usable in applications used by users. * Variant management at the Registry level requires deciding whether variants should resolve or point to the same IP address. There is no one size fits all solution. The decision is dependent on three variables: locale, registry and user community. Variations may be needed across registries to achieve consistency of variants. * Language communities have recommended to ICANN that variants should be allocated to the same TLD applicants and not to different applicants to avoid confusion and ensure consistency of user experience. The challenge of universal acceptance of IDNs * With the implementation of the Root Zone LGR procedure, the most important concern for the user community is the universal acceptance of IDNs and IDN variants. Software intended for end users such as web browsers, email clients and operating system needs to support IDN and IDN variants to ensure a positive user experience. * The introduction of IDN TLD and IDN Variant TLD to Internet users will realistically not be smooth and is likely to encounter some barriers and difficulties. Historically it has been extremely challenging to ensure universal acceptance - some of the labels introduced with the new TLD expansion in 2001 still do not work consistently everywhere. There are various points of potential failures in enabling universal acceptance. The problem lies not with the DNS, but with applications. * ICANN has highlighted the issues of universal acceptance in its Report on "Examining the User Experience Implications of Active Variant TLDs" (http://www.icann.org/en/resources/idn/variant-tlds/active-ux-21mar13-en.pdf). The Joint ccNSO-GNSO Internationalized Domain Names Working Group (JIG) at ICANN believes that industry-wide collaboration involving the technical and user communities is essential to address the problem of universal acceptance effectively. * Concrete policy recommendations to address the problem of universal acceptance include: (1) Discourage systems that do not accommodate IDN and IDN Variants; (2) Develop ways of identifying what is a legitimate IDN TLD label; (3) Encourage IDN TLD Operators and Accredited Registrars to ensure that they support universal acceptance of IDN TLDs in their own systems; (4) Advocate for universal acceptance, raise awareness and provide reference/learning materials. Language community engagement and mobilization issues * The Root Zone LGR procedure puts in place an open process that is welcoming and embracing of all languages that have been encoded in Unicode. Engagement in the process requires that language communities be aware of the initiative, be interested to engage and be ready to mobilize their respective communities to fulfill the requirements for forming Generation Panels. * The Arabic, Brahmi/Devanagari and Han script communities are already mobilizing to form Generation Panels. They comprise large language communities that are prepared for engagement because of their previous engagements with ICANN via case studies that led to the development of the Root Zone LGR procedure. Securing the involvement of smaller language communities that have not engaged with ICANN before is a challenge without dedicated or targeted outreach, which is essential to nurture interest and support readiness. * The disadvantage to late entrants or language communities that are not able to engage can potentially be addressed by the Integration Panel, which can produce Label Generation Rules for certain languages without waiting for proposals from Generation Panels, provided that the languages are in active use and are encoded in Unicode. * The Chinese language community experience in making the first proposal for IDN Variant management in 2000 offers the following principles to guide the implementation of the Root Zone LGR procedure: (1) Adopt an open language community concept (i.e., if you speak the language, you are part of the language community irrespective of territorial/country jurisdiction); (2) Adopt a bottom up and consensus-based decision-making and dispute resolution model for the language communities; (3) Ensure that permissible code points are those that are acceptable to the user community. Importance of the ICANN Public Comments for the Root Zone LGR procedure * The Root Zone LGR procedure specifies the ICANN Public Comments as the only governance oversight and appeals mechanism for the decisions of the Integration Panel. Generation Panels will essentially engage in a public negotiation process with the Integration Panel through the Public Comments process. The openness of the process allows for input from other stakeholders/interested parties for the Integration Panel's consideration. * Via the Public Comments process, the Integration Panel is required to defend its decisions in an open and transparent way and in a sufficiently rigorous manner (i.e., provide defensible rationale for its decisions against high standards of scrutiny/challenge). Should the Integration Panel fail in this respect, ICANN is empowered to act to have the Panel replaced. * The Public Comments process still has certain weaknesses such as impediments to the effective participation/input of relevant stakeholders in a timely manner. The ICANN Accountability and Transparency Review Team 2 is currently addressing issues related to improvements of the Public Comments process. END