The IAB received this email in response to the IAB Statement: “The interpretation of rules in the ICANN gTLD Applicant Guidebook.”

From: Thomas Narten <narten@us.ibm.com>
Date: March 17, 2012 7:52:26 PM GMT+01:00
To: "IAB Chair" <iab-chair@iab.org>
Cc: iab@iab.org
Subject: Re: [IAB] The interpretation of rules in the ICANN gTLD Applicant Guidebook

IAB,

ICANN appreciates the attention of the IAB to the technical aspects of
the introduction of Internationalized Domain Names (IDNs).  This note
seeks some additional clarification concerning the recent note "IAB
Statement: "The interpretation of rules in the ICANN gTLD Applicant
Guidebook."

The IAB statement could be interpreted as a recommendation to ICANN to
revise the Applicant Guidebook, or as a warning to be cautious when
evaluating applied-for strings with certain properties.

Every applied-for string in the new gTLD program is reviewed by the
DNS Stability Evaluation Panel to determine whether whether the
applied-for gTLD string might adversely affect DNS security or
stability. Were the Panel to use criteria as follows, would that be
consistent with the IAB recommendations:

1.  The Internet Architecture Board has noted that labels that contain
 one or more characters with the Unicode general category property
 of Mc or Mn are much more likely to be the source of stability and
 representation problems than labels consisting entirely of
 characters with the general category properties of Ll, Lo, or
 Lm. An IDN label that contains one or more characters with the Mc
 or Mn property will therefore be evaluated carefully to ensure
 that it is appropriate with respect to the script and associated
 language(s). This evaluation will include a search for any
 language- or context-specific rendering issues that might create
 confusion or instability.

2.  An IDN label that contains one or more characters with the IDNA
 derived property CONTEXTJ or CONTEXTO must be appropriate with
 respect to the script and associated language(s) according to
 unambiguous contextual rules provided by the applicant, which must
 be consistent with the intent of the contextual rule arrangements
 of IDNA. The IDNA specification warns registries to permit these
 characters to be used in domain name labels only after careful
 scrutiny, because they can easily be the cause of considerable
 confusion, false string matches and mismatches, and complications
 when the labels are embedded in identifiers. An IDN label that
 contains one or more CONTEXTJ or CONTEXTO characters will
 therefore be evaluated carefully to ensure that it is not a
 potential source of security or stability problems.

Also, ICANN would like to inform the IAB that there are currently ten
IDN TLDs in the root that have the Mc or Mn characteristics, which
would not match the "most conservative" criteria under the IAB's
statement.  Those are:

Country, String, Language, Script
--------------------------------------
 India, भारत, Hindi, Devanagari
 India, భారత్, Telugu, Telugu
 India, ભારત, Gujarati, Gujarati
 India, ਭਾਰਤ, Punjabi, Gurmukhi
 India, ভারত, Bengali, Bengali
 India, இந்தியா, Tamil, Tamil

 Singapore, சிங்கப்பூர், Tamil, Tamil

 Sri Lanka, ලංකා, Sinhalese, Sinhala
 Sri Lanka, இலங்கை, Tamil, Tamil

Strings that have passed Fast Track string evaluation and are eligible
for delegation:

 Bangladesh, বাংলা, Bangla, Bangla (Bengali script)

The IAB's statement indicates in its third requirement that "existing
TLD labels must be permitted."  Is statement #3 intended to refer to
the ten strings listed above, or is statement #3 intended to have a
broader scope?

Please note, ICANN is requesting a response from the IAB clarifying its
intent as soon as possible, within one week if possible.  The application
window for new gTLDs has been open for many weeks and will close on April
12.  The members of the Internet Community who are applying for a new IDN
gTLD are at a disadvantage without some clarification of the impact of the
IAB's statement on applied-for strings. We appreciate your attention to
this issue.

Thomas
(as IETF Liason to the ICANN Board)

The following email was sent in response to the above:

From: IAB Chair <iab-chair@iab.org>
Date: March 26, 2012 12:41:11 PM GMT+02:00
To: "narten@us.ibm.com" <narten@us.ibm.com>
Cc: iab@iab.org
Subject: [IAB] Response to ICANN questions concerning "The interpretation
of rules in the ICANN gTLD Applicant Guidebook"

Dear Thomas, and colleagues in the ICANN Board.

This note is a response to your questions of March 17, 2012 about the
IAB statement of February 8, 2012, "The interpretation of rules in the
ICANN gTLD Applicant Guidebook."

You asked two questions:

1. Is the procedure followed by the DNS Stability Evaluation Panel
consistent with the IAB recommendation?

There are a great many unknowns when it comes to the use of certain
classes and certain combinations of internationalized characters. It is
likely that in a final specification, the use of some types and classes
of characters in combination with other characters will not cause any
problems in some cases, and will be problematic in other cases.

In absence of a specification, our recommendation provides the 'always
safe rules', for instance, excluding the general classes Mc and Mn.

It is clear that ICANN might receive requests that are not inside of
this rule-set and the ICANN process needs to deal with those
pragmatically. The guidelines that the panel is proposing to follow seem
to pragmatically align with what we consider a conservative approach,
specifically since the panel not only looks at the general character
clases Mc and Mn but also at characters with derived property CONTEXTJ
or CONTEXTO.

We assume that only if the panel assesses that there are no confusion or
instability issues in either of the two types of evaluations, the ICANN
board will approve said proposed TLD.

2. Is statement that "existing TLD labels must be permitted" intended to
refer to the ten strings listed, or is it intended to have a broader
scope?

Existing TLDs that have already been allocated under the ccTLD Fast
Track procedures should be retained. The IAB is currently not aware of
any issues with said TLDs. However, even if they turn out to have
properties that cause confusion, or problems with rendering or
stability, the removal of a TLD is likely to cause stability issues even
if those TLDs might be in conflict with any future specification.

More generically, we see all of these IDN policy issues in terms of
tradeoffs. In the case of names already approved and delegated or
pending delegation under the ccTLD Fast Track, we see the stability
disadvantages of removing names as exceeding the advantages of a more
careful and conservative approach, especially in the context of
delegations to existing ccTLD administrations and governments who have
demonstrated that they can operate delegated TLDs in a responsible
fashion.

As such, requirement 3 says that because a new specification will be
developed, existing TLDs should not be removed, even though their
existence might require an exception in the specification.

Finally, we realize there might be confusion about the position of the
IAB on the use of A-labels in the context of the "Alphabetic Only"
interpretation of RFC1123. The IAB considers the use of A-labels in TLDs
a valid practice; the most conservative approach refers to the IDNA2008
specification and allows A-labels in general with the restrictions set
by the other requirements.

For the IAB,
Bernard Aboba (IAB Chair)