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: Wed, 2 Dec 2009 08:27:24 -0500

Avri,

If I understand you correctly, your conclusion is not correct.  FCFS will only 
apply (for LDH or IDN) if the exact second-level domain is not already 
registered as a second-level domain name in the applicable TLD (LDH or IDN).

Chuck 

> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx 
> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Avri Doria
> Sent: Wednesday, December 02, 2009 6:42 AM
> To: gnso-idng@xxxxxxxxx
> Subject: Re: [gnso-idng] rethinking IDN gTLDs
> 
> 
> 
> 
> 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
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>> 
> >>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >>>> 
> >>> 
> >>> 
> >>> 
> >> 
> > 
> 
> 
> 




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

Privacy Policy | Terms of Service | Cookies Policy