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

["Edmon Chung" <edmon@xxxxxxxxxxxxx>]

Hi Patrik,

Thanks for the clarification.
Yes, I think we are probably saying pretty much the same thing too.  The 
subtle, and critical difference is perhaps whether the excuse for ICANN to 
withhold/discriminate single character IDN TLD implementation is appropriate.

If you say 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", then we have the same problem with 2, 3 or more character IDN TLD 
strings.  The same logic if applied would result in ICANN not being able to 
identify what is a 2 character string (and so on).  i.e. if one cannot 
determine whether a string is 1 character long, how can one determine whether a 
string is 2 characters long, and so on.

Similarly, "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.", the same logic if applied to 2 or more characters also 
yield the same problematic logical conclusion that if you cannot determine 
whether one character may cause confusion to another character, regardless of 
how many characters you have in two or more strings, one would not be able to 
come up with a method to determine whether the strings should be considered 
confusing or not.

To illustrate the point:
- if one cannot determine whether "o" should be considered confusing with "0"
- neither can one determine whether "oo" should be considered confusing with 
"00"

I can agree that there is potentially a higher percentage of confusable single 
character IDN strings (but I can equally argue that there are a larger absolute 
number of potentially confusable 2 or more character IDN strings)... 
nevertheless the key question is not whether 2 strings are confusable (because 
that can happen regardless of how many characters a string has), but what to do 
when there are 2 confusable strings.  Because, as with 2 or more characters, 
the aim is not to disallow any string that may confuse with any other string, 
but to determine:
1. if 2 strings are applied in the same round, whether they form a contention 
set
2. if a string is applied in a particular round, whether they form a contention 
set with an existing TLD (included in previous rounds)

i.e. there does not seem to be need to pre-determine and/or identify all 
possible pairs of possibly confusing strings because however many there are it 
is irrelevant.  What is relevant is only when presented with 2 applications (or 
one application with an existing TLD) whether they are to be considered 
confusing.  And for that, if we argue that a panel is not ready to determine 
whether two single character IDN TLDs are confusing, there doesn't seem to be a 
way we can argue that the same panel with the same tools can be ready to 
determine whether two multi-character IDN TLDs should be considered confusing.

Edmon




-----Original Message-----
From: Patrik Fältström [mailto:patrik@xxxxxxxxxx] 
Sent: Saturday, February 04, 2012 12: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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
>