First of all, I sort of agree with Bertrand (GAC) when he said,
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,
discuss them in separate tracks such that each track would not hold
Based on that, and the question of getting "beyond the criticisms that
being used to stall gTLDs in general", I therefore sort of proposed a
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
- This track would need to address the overarching issues
- Focused discussion on IDN may (or may not) make resolving the issues
- Result of the discussion may (or may not) merge the process back
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
- 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
registration policies to achieve the same
- Where objection is received and not resolved, then the application
move to Track A above (that is the part where I proposed the "confusingly
Both IDN Track A and Track B can proceed together and in fact can
to exist. Track B can essentially be an ongoing process, even for future
On the topic of limitation on number of script/language, first of all,
IDN ccTLD Fast Track did not set a numerical limit, but rather, it is
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
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
the issue further complicates because of the overlap in script/character
usage, which could become a fairness issue, as whichever is launched
could take away names available for the latter. This is also a reason I
think perhaps we should distinguish this discussion from "fast" track,
rather look at this IDN Track B as an ongoing track for even future new
Initially, perhaps limiting to non-latin scripts could work.
1 per language per script may be ok too, which I believe is similar to
approach taken by the IDN ccTLD Fast Track.
The EOI seems quite separate to this discussion I think.
PS. It seems we are gaining some momentum with this discussion.
should schedule a few conference calls to further hash out possible ways
forward. Will start a separate thread on this.
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
Subject: Re: Process forward [RE: [gnso-idng] restarting discussions on
... what gets the gTLD fast track beyond the
criticisms that are being used to stall gTLDs in general.
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
- 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
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
being proposed by for new gTLDs (full IRT, no Geo related name of any
sort, no word that anyone on earth considers controversial, nothing
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
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
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.
- 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
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".