Re: [gnso-idng] rethinking IDN gTLDs
Thanks Chuck. Stéphane Le 2 déc. 2009 à 15:06, Gomes, Chuck a écrit : > Stephane, > > Please see my responses below. And let we qualify all of this discussion > with this caveat: VeriSign management is very firmly committed to the > approach I am describing, otherwise we would not have communicated it > publicly, but when it is actually implemented, the fine details will have to > be worked, so please allow some flexibility in that regard. Also, please > allow me a small margin of error in case I mistakenly describe some details > because the approach is a work in progress and my understanding of it may > not yet be perfect. At the same time, I am confident that I do understand > the major aspects of the approach enough to describe it as an illustration. > > Chuck > >> -----Original Message----- >> From: Stéphane Van Gelder [mailto:stephane.vangelder@xxxxxxxxx] >> Sent: Wednesday, December 02, 2009 5:46 AM >> To: Gomes, Chuck >> Cc: icann@xxxxxxxxxxxxxx; gnso-idng@xxxxxxxxx >> Subject: Re: [gnso-idng] rethinking IDN gTLDs >> >> 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)? > > Chuck: You are mostly correct. First, of all I think it is best to avoid > the term 'owner'; registrant is a more accurate term. It is not correct to > say that the holder of an LDH.com would "automatically be listed as the > owner (registrant) of the corresponding" LDH.IDN_COM. Let me use > VeriSign.com as an example. VeriSign, Inc. is the registrant of > VeriSign.com. VeriSign, Inc. would not automatically become the registrant > of VeriSign.IDN_COM but VeriSign, Inc. is the only one that will be allowed > to activate the IDN version; no one else could registrer VeriSign.IDN_COM > even if VeriSign, Inc. has not activated it. BTW, the same principle would > work for an IDN second level name; it does not have to iniitate with an LDH > second level registration. > >> 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)? > > Chuck: Yes. Otherwise, as I stated in an earlier response to Avri, we would > be put into a nearly impossible situation of making subjective judgements. > It is up to the registrant to decide what variations of its name they > consider equivalent and to register those. Again for example, the fact that > VeriSign, Inc. is the registrant of VeriSign.com would not mean that only > VeriSign_IDN.com or VeriSign_IDN.IDN_com would be protected; VeriSign would > have to register VeriSign_IDN.com or VeriSign_IDN.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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> Attachment:
smime.p7s
|