Re: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]
Eric,
Two things I want to point out.
"My constituency" as you put it is your constituency (or stakeholder group as
it should now be called) also.
The views I give are my personal views. I understood you to be asking me what I
thought, not what the RrSG as a whole thought.
Stéphane
Le 23 nov. 2009 à 22:32, Eric Brunner-Williams a écrit :
> Stephane,
>
>
> It is odd you should mention single-registrant, as it was just a year ago
> that the authors of the CRAI report, and why no one seems to know, or is
> willing to admit, tossed that idea towards, but not immediately into, the DAG.
>
> As the DAG isn't final, it is still possible that, not only will applications
> from individuals or sole proprietorships not be considered (DAGv3, 1.2.1,
> p1-15), that applications for "single-registrant" will not be considered.
>
> Whether for the reasons that Werner offered, or for other reasons.
>
> Either way, the CRAI Report has engendered a year-long delay while we try to
> figure out the vertical integration and Sherman and Clayton Act issues, and
> the dubious notion of queuing an arbitrary number of edits to the root zone
> for entities that plan not to use the DNS.
>
> But this is a distraction from why you, or your constituency, but not the
> Council, as Chuck has been kind enough to point out, is opposed to the
> general, or specific, suggested offered by Edmond, that is, either a "gTLD
> IDN track", or a "ccTLD IDN FT similar track".
>
> CORE does have a view distinct from each of the RSG and RySG, and the
> Council, in that CORE did not advocate any delay on the ccTLDs seeking to
> offer IDNs, beyond the technical issue of protocol and table consistency. So
> CORE did not oppose the ccTLD IDN FT, nor preventing the ccTLD IDN PDP from
> concluding before the gTLD IDN PDP. We just don't see the value in the delay
> to offer literacy where it is lacking.
>
> Having made that choice, within this GNSO activity, for as long as CORE is
> allowed to participate, we're more supportive of the general, even the
> specific proposals offered by Edmond. Hence my curiosity in your interest,
> and your opposition.
>
> Thanks for your time today.
>
>
> Eric
>
> Stéphane Van Gelder wrote:
>> 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
|