Re: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]
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] 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
|