[APAC-Discuss] [At-Large] New Procedure for the DNS Root Zone Affecting Linguistic Diversity at the Top Level

Mon Nov 11 01:29:43 UTC 2013

Many thanks Rinalia.

On Mon, Nov 11, 2013 at 2:27 PM, Rinalia Abdul Rahim <
rinalia.abdulrahim at gmail.com> wrote:

> 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
>
> _______________________________________________
> At-Large mailing list
> At-Large at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/at-large
>
> At-Large Official Site: http://atlarge.icann.org
>