ICANN ICANN Email List Archives

[gnso-idng]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-idng] rethinking IDN gTLDs

  • To: "Avri Doria" <avri@xxxxxxx>, <gnso-idng@xxxxxxxxx>
  • Subject: RE: [gnso-idng] rethinking IDN gTLDs
  • From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Date: Tue, 1 Dec 2009 13:32:44 -0500

Avri,

I still don't think that the extended evaluation is the place for this.
It is important to remember that the confusing similarity review is in
two parts: a preliminary comparison and a panel review.  See the
following from DAG3:

"2.1.1.1 String Similarity Review

This review involves a preliminary comparison of each applied-for gTLD
string against existing TLDs and against other applied-for strings. The
objective of this review is to prevent user confusion and loss of
confidence in the DNS.

The review is to determine whether the applied-for gTLD string is so
similar to one of the others that it would create a probability of
detrimental user confusion if it were to be delegated into the root
zone. The visual similarity check that occurs during Initial Evaluation
is intended to augment the objection and dispute resolution process (see
Module 3, Dispute Resolution Procedures) that addresses all types of
similarity.

This similarity review will be conducted by an independent String
Similarity Panel."

Note the objective in the first paragraph: "to prevent user confusion
and loss of confidence in the DNS".

And notice one key word in the 2nd paragraph: "detrimental".  It seems
to me that the panel will be required to determine whether there is
"probability of detrimental user confusion".

Chuck

> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx 
> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Avri Doria
> Sent: Tuesday, December 01, 2009 12:21 PM
> To: gnso-idng@xxxxxxxxx
> Subject: Re: [gnso-idng] rethinking IDN gTLDs
> 
> 
> Hi,
> 
> Yes, and that is what comes out in the extended review.  As 
> far as I can tell there is no provision  for an initial 
> evaluation to take those complicating details into account.
> 
> Given the range of things that can be deemed similar, it 
> would be very difficult to figure this out in an initial 
> stage as far as I can tell.  As far as I understood the 
> initial tests where going to flag anything that required more 
> investigation.
> 
> Of course if the initial test are primarily for visual 
> confusing similarity, and I know that is a bone of contention 
> for some, then there would not be much of a problem.
> 
> a.
> 
> On 1 Dec 2009, at 15:58, Gomes, Chuck wrote:
> 
> > Avri,
> > 
> > One of the main purposes of the restriction on confusingly similar 
> > strings was to avoid user confusion.  We talked about that 
> a lot.  If 
> > the chances of user confusion are null, why would the strings be a 
> > concern?
> > 
> > Chuck
> > 
> >> -----Original Message-----
> >> From: owner-gnso-idng@xxxxxxxxx
> >> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Avri Doria
> >> Sent: Monday, November 30, 2009 9:37 PM
> >> To: gnso-idng@xxxxxxxxx
> >> Subject: Re: [gnso-idng] rethinking IDN gTLDs
> >> 
> >> 
> >> Hi,
> >> 
> >> I do not remember any GNSO policy conversation that covered this 
> >> point and always assumed that this would be the mechanism for 
> >> rectifying such coincidences.
> >> 
> >> Are there any of the discussions in the policy 
> recommendations that 
> >> give this impression?
> >> 
> >> a.
> >> 
> >> On 30 Nov 2009, at 19:04, Gomes, Chuck wrote:
> >> 
> >>> An extended evaluation shouldn't even be needed in cases
> >> like this.  
> >>> It was never intended that the confusingly similar
> >> restriction would
> >>> be used for variations of the same name by the same operator.
> >>> 
> >>> Chuck
> >>> 
> >>>> -----Original Message-----
> >>>> From: owner-gnso-idng@xxxxxxxxx
> >>>> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Avri Doria
> >>>> Sent: Monday, November 30, 2009 9:45 AM
> >>>> To: gnso-idng@xxxxxxxxx
> >>>> Subject: Re: [gnso-idng] rethinking IDN gTLDs
> >>>> 
> >>>> 
> >>>> hi,
> >>>> 
> >>>> Would/could  this not be dealt in the extended evaluation
> >> stage where
> >>>> one requests an extended review of the rejection on the basis of 
> >>>> Confusing Similarity because there is no risk of adverse effect?
> >>>> 
> >>>> Or do you think it should be a complicating factor in 
> the initial 
> >>>> evaluation?  Do we need a stmt somewhere in the doc
> >> allowing for this
> >>>> possiblity?
> >>>> 
> >>>> Personally I think that using standard process for the 80%
> >> case and
> >>>> the extended review and other review/appeals processes for the 
> >>>> complicated questions (20%) is one of the more clever
> >> things in the
> >>>> GNSO recommendations that has been adequately, I think, 
> translated 
> >>>> into the DAG.  I think one of the places where we run into
> >> problems
> >>>> is where people with the 20% concerns don't want to have
> >> to resort to
> >>>> the review processes, be it confusingly similar or geo names.
> >>>> 
> >>>> a.
> >>>> 
> >>>> On 30 Nov 2009, at 08:57, Eric Brunner-Williams wrote:
> >>>> 
> >>>>> Gomes, Chuck wrote:
> >>>>>> Here's what I think is a simpler way to make my point: If the 
> >>>>>> problems anticipated by offering confusingly similar 
> strings are 
> >>>>>> avoided, then the restriction of offering the strings is
> >>>> unneccessary.
> >>>>> 
> >>>>> 
> >>>>> Agree.
> >>>>> 
> >>>>> We're not doing string comparison for the mathematical
> >>>> pleasure of describing the algebraic structure of 
> semi-groups and 
> >>>> their generators, but because some non-algebraic property exists 
> >>>> outside of the universe of character repertoires and the strings 
> >>>> generated over them, some property with a lawyer attached.
> >>>>> 
> >>>>> More broadly, some, if not all of the IRT issues are dealt
> >>>> with if the application is not considered in an 
> artificial vacuum. 
> >>>> There's not a lot more gained by lawyering in the abstract
> >> than from
> >>>> string manipulation in the abstract.
> >>>>> 
> >>>>> 
> >>>>> So, restrictions are context dependent, not absolute.
> >>>>> 
> >>>>> Eric
> >>>> 
> >>>> 
> >>>> 
> >> 
> >> 
> >> 
> 
> 
> 




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy