RE: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

Two clarifications: 1) It is a GNSO as a whole position, not just the RySG, 
that neither IDN ccTLDs or IDN gTLDs should proceed the other; 2) there was no 
exception of the IDN ccTLD fast track.  The position went on to say, if one did 
proceed before the other, that arrangements should be made to minimize possible 
problems. (Note I am not quoting exact wording.)

Chuck 

> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx 
> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Eric Brunner-Williams
> Sent: Monday, November 23, 2009 9:18 AM
> To: Stéphane Van Gelder
> Cc: Edmon Chung; gnso-idng@xxxxxxxxx
> Subject: Re: Process forward [RE: [gnso-idng] restarting 
> discussions on IDN gTLD]
> 
> 
> Stephane,
> 
> 
> Thank you but you've managed not to suggest what the 
> advantage is that you seek to avoid, and what the market is 
> in which this advantage might exist.
> 
> 
> Would it be reasonable to conclude from your comment that you 
> are also opposed to the position of record of the GNSO, or at 
> least the RySG, that, except for the ccTLD IDN FT, that IDN 
> offering by the ccTLDs and the gTLDs occur roughly at the 
> same time, to minimize the "first to market advantage" 
> (obviously, not in the same sense as you use the term), 
> because that position distinguishes IDN gTLDs from ASCII 
> gTLDs, and could, as a "track", result in applications for 
> IDN gTLDs being accepted prior to applications for ASCII gTLDs?
> 
> I believe that was your initial statement, and I simply want 
> to know if you're opposed to the coupling of the cc and g IDN 
> offerings, and favor either (a) no gTLD IDN until gTLD ASCII 
> or (b) no ccTLD IDN until gTLD IDN and gTLD ASCII.
> 
> Thank you for your patience. I won't ask anything else, no 
> matter how curious I am.
> 
> Eric
> 
> Stéphane Van Gelder wrote:
> > Hi Eric,
> > 
> > I think what I mean is fairly clear. That no category of 
> applicant should be given an application window before 
> others. What happens once the application window is open for 
> all obviously then depends on the specifics of each 
> application and the validation process.
> > 
> > Thanks,
> > 
> > Stéphane
> > 
> > Le 23 nov. 2009 à 14:12, Eric Brunner-Williams a écrit :
> > 
> >> Stéphane Van Gelder wrote:
> >>> Sorry, I should have said "having some applicants be 
> allowed to apply before others".
> >>
> >> Could you suggest a rational, as "first to market 
> advantage" will exist where two or more applications are 
> fully evaluated, contracts entered, unless all the associated 
> DNS data is added to the root as a single unit of change.
> >>
> >>
> >> Or do you mean both "apply before others" _and_ "delegated 
> before others"?
> >>
> >>
> >> Or do you mean the "first to market advantage" to be just 
> the act of submitting an application?
> >>
> >>
> >> If the "first to market advantage" arises simply from the 
> act of submitting an application, what is that advantage? In 
> what market?
> >>
> >>
> >> Eric
> >>
> >>
> >>> Thanks,
> >>> Stéphane
> >>> Le 23 nov. 2009 à 13:37, Eric Brunner-Williams a écrit :
> >>>> Stephane,
> >>>>
> >>>> Thank you for the clarification.
> >>>>
> >>>> Its my experience that the round in 2000-2002, having 
> only 7-10 applicants, 3 of type sTLD (aero, coop, museum), 
> and 4 of type gTLD (biz, info, name, pro), was not executed 
> to avoid sequential delegation and sequential launches.
> >>>>
> >>>> How can "some applicants [] go before others" be prevented?
> >>>>
> >>>> Eric
> >>>>
> >>>> Stéphane Van Gelder wrote:
> >>>>> Eric,
> >>>>> Seems I really must try and make my emails clearer ;) I 
> am not in 
> >>>>> favor of a system which would allow some applicants to 
> go before others and hence gain a first-to-market advantage.
> >>>>> Hope that is clearer.
> >>>>> Stéphane
> >>>>> Le 22 nov. 2009 à 15:15, Eric Brunner-Williams a écrit :
> >>>>>> Stéphane Van Gelder wrote:
> >>>>>>> Edmon,
> >>>>>>> Your track A/track B idea is interesting.
> >>>>>>> I maintain that track A as you suggest it requires 
> that the general idea of tracks be accepted under the new 
> gTLD program. I cannot see where the only track is an IDN 
> track and other categories have to wait until the DAG is finalised.
> >>>>>> Are you arguing for "more tracks" or against "language 
> as a track"?
> >>>>>>
> >>>>>>
> >>>>>>> Track B. This is a different topic, but it does tie 
> into new gTLDs in general of course as even if they were 
> based on existing gTLDs, the IDN TLDs referenced would 
> constitute a new TLD.  That being so, it will be difficult 
> IMO to make a case for the early release of IDN versions of 
> existing gTLDs, as that would be giving entities who already 
> have the advantage of being on the market a first-to-market 
> advantage for new gTLDs.
> >>>>>> Are you arguing for "more TLDs" or for "no more TLDs 
> until an unknown set of conditions are satisfied"?
> >>>>>>
> >>>>>>
> >>>>>> Eric
> >>>>>>
> >>>>>>> Stéphane
> >>>>>>> Le 21 nov. 2009 à 22:49, Edmon Chung a écrit :
> >>>>>>>> First of all, I sort of agree with Bertrand (GAC) 
> when he said, 
> >>>>>>>> perhaps it is not so much about "fast" track, but 
> just "track 
> >>>>>>>> differentiation".  The point is, what would be 
> useful may be to 
> >>>>>>>> have a focused discussion on IDN gTLDs in parallel 
> with other 
> >>>>>>>> discussions with new gTLDs in general, i.e. to 
> discuss them in 
> >>>>>>>> separate tracks such that each track would not hold 
> back the other.
> >>>>>>>>
> >>>>>>>> Based on that, and the question of getting "beyond the 
> >>>>>>>> criticisms that are being used to stall gTLDs in general", I 
> >>>>>>>> therefore sort of proposed a dual track approach for 
> IDN gTLDs earlier in the thread:
> >>>>>>>>  1. IDNG Track A: IDN gTLDs operated as completely new gTLDs
> >>>>>>>> - The new IDN gTLD will accept registrations completely 
> >>>>>>>> separate from any existing gTLD
> >>>>>>>> - This track would need to address the overarching issues
> >>>>>>>> - Focused discussion on IDN may (or may not) make 
> resolving the 
> >>>>>>>> issues more effective
> >>>>>>>> - Result of the discussion may (or may not) merge 
> the process 
> >>>>>>>> back with the full new gTLD process (or "track")
> >>>>>>>>
> >>>>>>>> 2. IDNG Track B: IDN gTLDs operated in accordance 
> with existing 
> >>>>>>>> gTLDs
> >>>>>>>> - Only for existing gTLDs, but can be objected to by 
> >>>>>>>> prospective IDN gTLD applicant
> >>>>>>>> - Existing gTLD registry must serve the same 
> zonefile under the 
> >>>>>>>> IDN gTLD (even though the IDN TLD itself would be a 
> separate NS 
> >>>>>>>> delegation at the
> >>>>>>>> root) OR offer registration only to the same registrant OR 
> >>>>>>>> implement other registration policies to achieve the same
> >>>>>>>> - Where objection is received and not resolved, then the 
> >>>>>>>> application should move to Track A above (that is the part 
> >>>>>>>> where I proposed the "confusingly similar" test)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Both IDN Track A and Track B can proceed together 
> and in fact 
> >>>>>>>> can continue to exist.  Track B can essentially be 
> an ongoing 
> >>>>>>>> process, even for future new gTLDs.
> >>>>>>>>
> >>>>>>>> On the topic of limitation on number of 
> script/language, first 
> >>>>>>>> of all, the IDN ccTLD Fast Track did not set a 
> numerical limit, 
> >>>>>>>> but rather, it is based on the number of official languages 
> >>>>>>>> ("official language" in its general
> >>>>>>>> sense) in the cc locality.  For gTLDs, the issue would be 
> >>>>>>>> tricky if a numerical limit is set and could raise 
> technical, 
> >>>>>>>> fairness as well as political issues.  Take ".Asia" for 
> >>>>>>>> example, it would not be appropriate to pick Chinese 
> over Japanese or Korean, or Hindi or Arabic for that matter.
> >>>>>>>> In the case of Chinese and Japanese (Kanji) (and 
> Korean Hanja 
> >>>>>>>> if included), the issue further complicates because of the 
> >>>>>>>> overlap in script/character usage, which could become a 
> >>>>>>>> fairness issue, as whichever is launched first could 
> take away 
> >>>>>>>> names available for the latter.  This is also a 
> reason I think 
> >>>>>>>> perhaps we should distinguish this discussion from "fast" 
> >>>>>>>> track, but rather look at this IDN Track B as an 
> ongoing track for even future new gTLDs.
> >>>>>>>>
> >>>>>>>> Initially, perhaps limiting to non-latin scripts 
> could work.  
> >>>>>>>> Limitation to
> >>>>>>>> 1 per language per script may be ok too, which I believe is 
> >>>>>>>> similar to the approach taken by the IDN ccTLD Fast Track.
> >>>>>>>>
> >>>>>>>> The EOI seems quite separate to this discussion I think.
> >>>>>>>>
> >>>>>>>> Edmon
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> PS. It seems we are gaining some momentum with this 
> discussion.  
> >>>>>>>> Perhaps we should schedule a few conference calls to further 
> >>>>>>>> hash out possible ways forward.  Will start a 
> separate thread on this.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: owner-gnso-idng@xxxxxxxxx 
> >>>>>>>>> <mailto:owner-gnso-idng@xxxxxxxxx> 
> >>>>>>>>> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Eric 
> >>>>>>>>> Brunner-Williams
> >>>>>>>>> Sent: Sunday, November 22, 2009 12:23 AM
> >>>>>>>>> To: Avri Doria
> >>>>>>>>> Cc: gnso-idng@xxxxxxxxx <mailto:gnso-idng@xxxxxxxxx>
> >>>>>>>>> Subject: Re: Process forward [RE: [gnso-idng] restarting 
> >>>>>>>>> discussions on
> >>>>>>>> IDN
> >>>>>>>>> gTLD]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> ... what gets the gTLD fast track beyond the 
> criticisms that 
> >>>>>>>>>> are being used to stall gTLDs in general.
> >>>>>>>>> Good question.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Other questions (perhaps subquestions of the 
> question above):
> >>>>>>>>> - would it be for non-Latin scripts only?
> >>>>>>>>>
> >>>>>>>>>> - would it be for IDN gTLDs only
> >>>>>>>>>> - would it be only for existing gTLD registries
> >>>>>>>>> - would each existing gTLD registry would be 
> allowed to apply 
> >>>>>>>>> for one "similar" name
> >>>>>>>>> - what changes to the existing registry contracts are 
> >>>>>>>>> necessary
> >>>>>>>>>
> >>>>>>>>> That, and the item I added above, would make it 
> most similar 
> >>>>>>>>> to the ccTLD IDN FastTrack.
> >>>>>>>>>
> >>>>>>>>> I make that one museum in a non-Latin script, one cat in a 
> >>>>>>>>> non-Latin script, one aero in a non-Latin script, one ... , 
> >>>>>>>>> and one com in a non-Latin script.
> >>>>>>>>>
> >>>>>>>>> For those counting, that's ~40 change requests to the IANA 
> >>>>>>>>> root arising out of the ccTLD IDN FT process, and 
> ~20 arising 
> >>>>>>>>> from a gTLD IDN FT process, if "this" can be called a "gTLD 
> >>>>>>>>> IDN FT", or about 2/3rds of the budget Thomas 
> Narten suggested was annually available.
> >>>>>>>>>
> >>>>>>>>>> - would applicants have to accept the most 
> stringent of the 
> >>>>>>>>>> restrictions being proposed by for new gTLDs (full IRT, no 
> >>>>>>>>>> Geo related name of any sort, no word that anyone on earth 
> >>>>>>>>>> considers controversial, nothing that has the same 
> meaning or 
> >>>>>>>>>> etymology as any exsiting TLD ...)
> >>>>>>>>> Do we care? Those that get hung up by objections simply 
> >>>>>>>>> survive the objection process or fail. Those to which no 
> >>>>>>>>> objections are offered progress. If a "gTLD IDN FT" is like 
> >>>>>>>>> (see above) the ccTLD IDN FT in the script, number, and 
> >>>>>>>>> equivalence restrictions, most of these 
> restrictions have already been addressed.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> How would this fasttrack combine with the EoI 
> proposed process?
> >>>>>>>>> I'm aware of a Board initiated EOI request for 
> comments, but 
> >>>>>>>>> not a proposed process.
> >>>>>>>>>
> >>>>>>>>> I'm aware "there is a group of participants that engage in 
> >>>>>>>>> ICANN's processes to a greater extent than Internet users 
> >>>>>>>>> generally", who have agreed to attempt to restrict 
> competition 
> >>>>>>>>> through presenting a resolution to the Board 
> proposing a "EoI process".
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I suggest that we ignore the latter, for several 
> reasons, and 
> >>>>>>>>> identify a gTLD IDN FT profile as a response to the 
> former, as 
> >>>>>>>>> well as a more general gTLD IDN, and the even more 
> general TLD 
> >>>>>>>>> IDN profile, to inform the Board.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> I am not against this, but I am not sure I see how 
> it would help.
> >>>>>>>>> I've a long note which I'll submit as a critical comment on 
> >>>>>>>>> the Board's EOI question to the community. In a nutshell, I 
> >>>>>>>>> don't think the EOI motion helped clarify issues. I'm even 
> >>>>>>>>> more skeptical about the purpose of a private party 
> "proposed EOI process".
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I think the next question isn't so much what about the EOI, 
> >>>>>>>>> its what about the restrictions imposed on the ccTLD IDN FT.
> >>>>>>>>> - non-Latin
> >>>>>>>>> - one each (or two for CDNC territories)
> >>>>>>>>> - limited "creep" from the iso3166 alpha-two value into 
> >>>>>>>>> alpha-three or other standardized names (for which 
> we have no 
> >>>>>>>>> equivalent convenient standards to point to)
> >>>>>>>>> - what changes to the existing registry contracts are 
> >>>>>>>>> necessary
> >>>>>>>>>
> >>>>>>>>> In addition, there is the problem of expanding the 
> number of 
> >>>>>>>>> entities holding a distinct IDN delegation in their 
> own right, 
> >>>>>>>>> under a new contract.
> >>>>>>>>>
> >>>>>>>>> Are non-Latin scripts to be prioritized? That has been the 
> >>>>>>>>> basis for the ccTLD IDN FT, and for what I suggest 
> above for a gTLD IDN FT.
> >>>>>>>>>
> >>>>>>>>> Are unserved populations to be prioritized? That is the 
> >>>>>>>>> foundation that the non-Latin requirement is based upon.
> >>>>>>>>>
> >>>>>>>>> I think we can help by suggesting not simply 
> numbers to some 
> >>>>>>>>> EOI effort, but specific groups of applications 
> with specific 
> >>>>>>>>> answers to "the criticisms that are being used to 
> stall gTLDs in general".
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Eric
> >>>>>>
> >>>>
> >>>>
> >>
> > 
> 
> 
> 
>