Re: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]
Sorry, I should have said "having some applicants be allowed to apply before
others".
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] 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
|