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

[Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>]

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.
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.
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] On
> > Behalf Of Eric Brunner-Williams
> > Sent: Sunday, November 22, 2009 12:23 AM
> > To: Avri Doria
> > Cc: 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature