Re: [gnso-idng] rethinking IDN gTLDs

[Avri Doria <avri@xxxxxxx>]

hi,

based on:

> In essence, the result will be that all active second level domain names
> for .com or .net (ASCII or IDN) will have the same registrant. 

I came to essentially the opposite conclusion.

So for some IDN-equivalent_of_LDH.com  the registrant will be the same as 
LDH.com

I am also assuming that for other IDN.com they will still use FCFS, and there 
is no confusingly similar rule operating at the 2nd level, so then 
some_other-IDN-equivalent_of_LDH.com may have a different registrant than 
LDH.com

a.


BTW I try to make a habit of using LDH instead of ASCII in recognition of the 
fact that we do not yet support ASCII, just a subset of ASCII in TLD space.


On 2 Dec 2009, at 11:46, Stéphane Van Gelder wrote:

> Chuck,
> 
> Your example makes very interesting reading. Thanks for take actual live 
> Verisign examples to the list, that's very helpful.
> 
> So I am right in understanding that no matter how many IDN variants of .COM 
> Verisign launches, the intent is that the holder of an ASCII .COM name, say 
> EXAMPLE.COM, would automatically be listed as the owner of the corresponding 
> EXAMPLE.(IDN_COM)? And is this automatic correspondence only valid for the 
> direct equivalent of the 2nd level name? In other words, I am right in 
> thinking that having EXAMPLE.COM does not entitle me to 
> (IDN-EXAMPLE).(IDN_COM)?
> 
> Thanks,
> 
> Stéphane
> 
> Le 2 déc. 2009 à 00:34, Gomes, Chuck a écrit :
> 
>> 
>> Mike,
>> 
>> Let me use our own plans for IDN versions of .com and .net as an
>> example.  Our current plans that we have communicated to our customers
>> and others is as follows:
>> Second level registrants for any .com or .net domain names will have the
>> right to activate their second-level name for any IDN versions of the
>> corresponding .com or .net name and no one else will be allowed to do
>> that.
>> All second level registrations for IDN versions of .com or .net will be
>> associated with their corresponding ASCII .com or .net as applicable.
>> In essence, the result will be that all active second level domain names
>> for .com or .net (ASCII or IDN) will have the same registrant.  For any
>> that are not activated, they will be unavailable to others.
>> I don't think there should be any user confusion in the DNS in this
>> approach.  Do you?
>> 
>> Chuck 
>> 
>>> -----Original Message-----
>>> From: owner-gnso-idng@xxxxxxxxx 
>>> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Mike Rodenbaugh
>>> Sent: Tuesday, December 01, 2009 3:40 PM
>>> To: gnso-idng@xxxxxxxxx
>>> Subject: RE: [gnso-idng] rethinking IDN gTLDs
>>> 
>>> 
>>> Thanks Chuck, that helps a bit, but I would like to 
>>> understand the details of how an existing gTLD registry might 
>>> offer an IDN equivalent "in a way to minimize any confusion". 
>>> I think I saw a mention of 'sharing a root zone file' but 
>>> there was no explanation.  If this is already explained 
>>> somewhere, then maybe I just need to be pointed in the right 
>>> direction.
>>> 
>>> Mike Rodenbaugh
>>> RODENBAUGH LAW
>>> 548 Market Street
>>> San Francisco, CA  94104
>>> (415) 738-8087
>>> http://rodenbaugh.com  
>>> 
>>> -----Original Message-----
>>> From: Gomes, Chuck [mailto:cgomes@xxxxxxxxxxxx]
>>> Sent: Tuesday, December 01, 2009 10:19 AM
>>> To: icann@xxxxxxxxxxxxxx; gnso-idng@xxxxxxxxx
>>> Subject: RE: [gnso-idng] rethinking IDN gTLDs
>>> 
>>> Mike,
>>> 
>>> Maybe I should have said "minimized" instead of "null".  It 
>>> is probably impossible to completely eliminate all chances of 
>>> user confustion.
>>> 
>>> My point is this: if two strings are confusingly similar but 
>>> are offered in a way that minimizes the risks of user 
>>> confusion, they should be allowed.  For example: if the 
>>> chinese version of .asia is proposed, it is confusingly 
>>> similar to the ASCII version of .asia; but if it is proposed 
>>> by dotAsia, the same registry operator as for the ASCII 
>>> version, and is offered in a way to minimize any confusion, 
>>> there should be no problem with that.  In a case like that, 
>>> there should be no need for extended evaluation.
>>> 
>>> Does that make sense?
>>> 
>>> Chuck 
>>> 
>>>> -----Original Message-----
>>>> From: owner-gnso-idng@xxxxxxxxx
>>>> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Mike Rodenbaugh
>>>> Sent: Tuesday, December 01, 2009 12:51 PM
>>>> To: gnso-idng@xxxxxxxxx
>>>> Subject: RE: [gnso-idng] rethinking IDN gTLDs
>>>> 
>>>> 
>>>> Chuck,
>>>> 
>>>> How do you mean "the chances of user confusion are null"?
>>>> 
>>>> Thanks,
>>>> Mike
>>>> 
>>>> Mike Rodenbaugh
>>>> RODENBAUGH LAW
>>>> 548 Market Street
>>>> San Francisco, CA  94104
>>>> (415) 738-8087
>>>> http://rodenbaugh.com
>>>> 
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: owner-gnso-idng@xxxxxxxxx
>>>> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Gomes, Chuck
>>>> Sent: Tuesday, December 01, 2009 6:59 AM
>>>> To: Avri Doria; gnso-idng@xxxxxxxxx
>>>> Subject: RE: [gnso-idng] rethinking IDN gTLDs
>>>> 
>>>> 
>>>> 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
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>