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

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

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