<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]
- To: Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>
- Subject: Re: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]
- From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 23 Nov 2009 10:12:55 -0500
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
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|