Re: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]
The market I am referring to is the registrant market. What I mean is the first
to be in a position to go through the ICANN application process. i.e., if you
are a prospective TLD applicant and your application window opens a year after
someone else's, you have a to-market disadvantage.
Stéphane
Le 23 nov. 2009 à 16:12, Eric Brunner-Williams a écrit :
> Stéphane Van Gelder wrote:
>> Sorry Eric, I don't mean to suggest you shouldn't ask anything else. Please
>> do so!
>
> OK.
>
> 1. Are you using "first to market advantage" meaning
> (a) first to offer inventory through RAA sales channels, or
> (b) first to offer something else?
>
> If (b), could you explain what the market is, what is bought and sold in it,
> that kind of thing, and what the advantage is in that market?
>
>
>
>
>> I was simply frustrated at my own apparent lack of clarity and my inability
>> to get my message across.
>> Your latest question seems to highlight this fact, as I am in fact very much
>> in favour of the GNSO's position that gs should be released at about the
>> same time as IDN ccs (I don't recall the RySG's position on the matter, but
>> as this is not my SG anyway, I won't comment on it). I am sorry that my
>> previous message led you to understand exactly the opposite. Please note
>> however that the way you seem to be characterizing the GNSO's position on
>> this seems wrong. The GNSO's position is no limited to IDN gs.
>
>
> I only have an observer's knowledge of the Council's position, but the act of
> asserting the desirability of a similar period of availability for ccTLD
> IDNs, the ccTLD IDN FT excluded, and gTLD IDNs, without explicit reference to
> also the same period of availability for gTLD ASCII, creates the possibility
> of sequential, not simultaneous ordering of events.
>
> It is hypothetical, but if the Council had two alternatives, one to allow
> gTLD IDNs "today" and gTLD ASCIIs "tomorrow", and the other to allow gTLD
> IDNs "tomorrow" and gTLD ASCIIs "tomorrow", it seems possible that they might
> settle on the first choice, as "tomorrow" might be several years from "today".
>
> If your recollection of the Council's position on this issue is correct, then
> other than technical nits, such as table consistency, there is no reason for
> this list to exist, as there could be no policy with Council support that
> would differentiate IDNs offered under a registry contract and ASCIIs offered
> under the same contract.
>
>
>> Once again, Eric, please do not hesitate to come back with further
>> questions. I will endeavor to answer as quickly and as clearly as I can, and
>> certainly do not want to stifle discussions.
>
>
> Well, I do have one more, touching on SG positions. As a registrar (USA
> Webhost and CORE), I'd like to offer more RAA restricted inventory _today_.
>
> How is it in the interests of the members of the RSG to advocate that there
> be no more RAA restricted inventory _today_?
>
> I don't mind selling Chuck's or Jeff's or Hal's existing product using my
> RAAs, I'd just like to know why it is in my advantage as a registrar not to
> be able to sell more of their, or anyone else's product, using my RAAs.
>
> Eric
>
>> Thanks,
>> Stéphane
>> Le 23 nov. 2009 à 15:18, Eric Brunner-Williams a écrit :
>>> 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
>>>>>>>
>>>
>
>
Attachment:
smime.p7s
|