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

Rinalia Abdul Rahim rinalia.abdulrahim at gmail.com
Mon Nov 11 01:27:31 UTC 2013

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,




·       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” (
).  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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ICANN-APRALO IGF 2013 Workshop Report.pdf
Type: application/pdf
Size: 101879 bytes
Desc: not available
URL: <http://atlarge-lists.icann.org/pipermail/at-large/attachments/20131111/6920a2fd/ICANN-APRALOIGF2013WorkshopReport.pdf>

More information about the At-Large mailing list