ICANN ICANN Email List Archives

[gnso-idng]


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

Re: [gnso-idng] rethinking IDN gTLDs

  • To: gnso-idng@xxxxxxxxx
  • Subject: Re: [gnso-idng] rethinking IDN gTLDs
  • From: Avri Doria <avri@xxxxxxx>
  • Date: Mon, 30 Nov 2009 09:44:38 -0500

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