FW: [jig] SSAC report on Single Character IDN TLDs

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

Forwarded with Patrik's approval.

Chuck

-----Original Message-----
From: Patrik Fältström [mailto:patrik@xxxxxxxxxx] 
Sent: Friday, February 03, 2012 11:56 AM
To: Gomes, Chuck
Cc: Julie Hedlund; edmon@xxxxxxxxxxxxx; 'jig'
Subject: Re: [jig] SSAC report on Single Character IDN TLDs

The work to update the RFC that say what characters are allowed. My personal 
interpretation say that it specifically touches the M* class of code points, as 
I think there is agreement of L* class code points.

See http://tools.ietf.org/html/draft-liman-tld-names-06

SSAC have been in touch with IAB, and I hope that IAB will say something on 
this matter.

I hope this posting to JIG might be possible to be approved, or you Chuck might 
be able to forward this to the list?

   Patrik

On 3 feb 2012, at 17:31, Gomes, Chuck wrote:

> Thanks Julie.  It would be helpful to know what IETF recommendations Patrik 
> is referring to that would be overridden.
> 
> Chuck
> 
>> -----Original Message-----
>> From: owner-jig@xxxxxxxxx [mailto:owner-jig@xxxxxxxxx] On Behalf Of
>> Julie Hedlund
>> Sent: Friday, February 03, 2012 9:40 AM
>> To: edmon@xxxxxxxxxxxxx; 'jig'
>> Cc: Patrik Fältström
>> Subject: Re: [jig] SSAC report on Single Character IDN TLDs
>> 
>> 
>> Dear Edmon,
>> 
>> Since he does not have posting rights to this list, Patrik Faltstrom,
>> SSAC
>> Chair, has asked me to forward the following message.
>> 
>> Best regards,
>> 
>> Julie
>> 
>> Julie Hedlund
>> Director, SSAC Support
>> 
>> -------------Forwarded from Patrik Faltstrom---------------------
>> 
>> Edmon,
>> 
>> I do not think you actually say things differently from what the SSAC
>> says
>> in SAC052. But, there are a few points I want to make:
>> 
>> Yes, normal review of confusability can occur. No new process is
>> needed.
>> But, instructions for how to do the evaluation must be clear. Whether a
>> character is confusing or not is not black or white. There is a sliding
>> scale, and it must be made clear when a character is to be approved and
>> not.
>> 
>> These instructions for approval of IDN TLD labels were just revised and
>> that
>> for the SSAC indicates that the rules currently in use are not stable,
>> but
>> good enough for labels longer than one character.
>> 
>> Specifically the SSAC wants to point out that what is one character
>> might be
>> more than one code point, and then we start to move into an area where
>> the
>> IETF does have ongoing activities. It is the SSAC view that ICANN
>> should not
>> override recommendations from the IETF.
>> 
>> Finally, yes, there are cases that are "simple" and it should be
>> possible to
>> identify which ones they are. The SSAC does not say all one-character
>> strings are dangerous, or that the current confusability rules are
>> broken.
>> 
>> Only that the instructions to the evaluation teams does not describe
>> the
>> case of one character. Remember, it is very specific regarding two
>> characters that might be confusing.
>> 
>>   Patrik
>> 
>> 
>> On 2/2/12 8:28 PM, "Edmon Chung" <edmon@xxxxxxxxxxxxx> wrote:
>> 
>>> 
>>> Hi everyone,
>>> 
>>> Please find the SSAC report on Single Character IDN TLDs:
>>> http://www.icann.org/en/committees/security/sac052.pdf
>>> 
>>> The summary of findings are:
>>> Finding 1: Single-character TLDs are more likely to cause user
>> confusion than
>>> TLDs with more than one character.
>>> Finding 2: No other significant security concerns are apparent with
>> the
>>> delegation of single-character TLDs.
>>> Finding 3: Current work on string similarity and variant issues has
>> not been
>>> completed.
>>> 
>>> Recommendations:
>>> 1. Given the potential for user confusion and the currently
>> unfinished work on
>>> string similarity and IDN variants, the SSAC recommends a very
>> conservative
>>> approach to the delegation of single-character IDN top-level domains.
>> In
>>> particular, ICANN should disallow by default the delegation of all
>>> single-character IDN TLDs in all scripts; exceptions are possible,
>> but only
>>> after careful consideration of each individual case.
>>> 2. Because important relevant work on string similarity, IDN variant
>> issues,
>>> and TLD label syntax is currently underway within ICANN, the Internet
>>> Engineering Task Force (IETF), and other bodies, ICANN should review
>> the
>>> Findings of this report, and any policies that it adopts in response
>> to
>>> recommendations made in this document, no later than one year after
>> the three
>>> work items mentioned above
>>> have been completed.
>>> 
>>> 
>>> Think the report is a good read.  However, the logic of the report
>> seems
>>> confusing:
>>> - If possible user confusion is the only concern
>>> - Then the issue comes down to work on string similarity
>>> - If the SSAC believes that the work on string similarity is not
>> complete
>>> - Then the whole new gTLD process should be called to stop
>>> 
>>> The report explains that in cases of 2 or more characters, where one
>> character
>>> is non-similar, then the string can be considered non-confusing.  The
>> logical
>>> conclusion for cases of 1 character should be the same, where one
>> character is
>>> non-similar, then the string can be considered non-confusing.
>>> 
>>> In cases of 2 or more characters, there exists cases where both (or
>> all)
>>> characters are similar, then the string is considered confusing. In
>> such
>>> cases, the string contention process or the first-come-first-served
>> rule comes
>>> into effect.
>>> 
>>> The conclusion of the SSAC report seems to be in conflict with such
>> contention
>>> and FCFS rule. i.e. if the SSAC findings and recommendations hold for
>> single
>>> characters, there is no reason why the same conclusions and
>> recommendations
>>> will not hold for 2 or more character strings (which was in effect
>> the
>>> conclusion of the JIG report).
>>> 
>>> More specifically:
>>> - the result of 2 TLD strings considered confusing is that they go
>> through
>>> contention process (and FCFS rule by round)
>>> - that should be the same regardless of whether the TLD strings are 1
>> or 2 or
>>> 3 characters or more
>>> 
>>> The SSAC findings simply states that there may be more likelihood of
>> strings
>>> that may be considered similar/confusing, but does not explain why
>> when such
>>> similarity/confusability occurs the same process as 2 or more
>> characters could
>>> not be applied.  The logical conclusion should be simply to warn the
>> applicant
>>> that there may be more cases which may require contention process
>> than for
>>> multi-character TLD applications.
>>> 
>>> I believe we have some SSAC members on this list as well.  It would
>> be good to
>>> hear from them what the logic is behind the recommendation and why it
>> believes
>>> it does not impact 2 or more character strings.
>>> 
>>> Edmon
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
>