Re: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]
I'm not thinking so much of a possible comparison between a .paris and a
.ile-de-france, which would probably be able to run within the same track, but
rather between say a regional TLD and a company TLD (if single-owner), which
the latest CORE comments for example seem to suggest should not run at the same
time (Werner's comments: single-registrant TLDs ... should not be allowed in
the coming round).
Stéphane
Le 23 nov. 2009 à 19:07, Eric Brunner-Williams a écrit :
> Stéphane Van Gelder wrote:
>> 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.
>
> Thanks again for your patience. I'm still having some difficulty
> understanding the importance of application submission, when the thing sold
> is domains, which could take between 6 months and 24 months after the
> application window closes, depending on the innate characteristics of the
> applications.
>
> "If your application window opens a year after someone else's, you have a
> to-market disadvantage."
>
>
> I don't see how a .paris in 1Q10 creates a to-market disadvantage to anyone,
> except perhaps a .il-de-france in 2Q10 or later, should such an application
> actually exist.
>
> I don't see how a .shoe in January creates a to-market disadvantage to
> anyone, except perhaps a .sock in December, should such an application
> actually exist.
>
> I'm sure there's a nugget of truth in your assertion, I simply think the
> claim you're making could be narrowed to be generally true, rather than
> generally false.
>
> Perhaps, any ".com-like .thingie" creates a to-market disadvantage to any
> otherwise indistinguishable ".com-like .other-thingie", if the .com-like
> .thingie precedes the .com-like .other-thingie.
>
> That seems a likely to be true statement, possibly even true where one of the
> thingies, or both, are IDN, whereas the ordering of Paris or Barcelona and
> some .com-like .thingie-or-another, in ASCII or not, seems likely to be false.
>
> I hope you can address the registrar interest in any restriction on the
> inventories the RAA enables.
>
>
> Eric
>
>> 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
|