ICANN ICANN Email List Archives

[gnso-idng]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-idng] motion for IDNG WG formation

  • To: Edmon Chung <edmon@xxxxxxxxxxxxx>, <gnso-idng@xxxxxxxxx>
  • Subject: Re: [gnso-idng] motion for IDNG WG formation
  • From: Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>
  • Date: Sun, 07 Jun 2009 12:34:41 +0200

After reading and taking into consideration many of the comments made on
this, I have to admit that I think the idea of an IDN gTLD fast-track is not
a good one at this stage.

I can understand Adrian's argument that such a fast track would probably
"dilute" the main gTLD effort and, if it went ahead, provide a good excuse
for a lot of people to push for further delays to that main process. For
example, I can easily see some people asking for a few months or even a few
years to give ICANN time to evaluate this "test bed" that an IDN gTLD
fast-track would be taken as being.

Further, I think that an IDN gTLD fast-track could only be launched once all
the overarching issues are resolved. And when that's the case, then why not
launch the full process anyway?

Some arguments have been made that an IDN gTLD fast-track is a way to
prevent the IDN ccTLDs from coming out first and getting a time-to-market
advantage. But surely that argument could be turned around. The GNSO Council
has repeatedly stressed that it does not feel ccTLDs should be released
before gTLDs, and vice-versa. So why is it not simply a case of the CCs
waiting for the full gTLD program to be ready, instead of the Gs "hatching"
a fast-track? Surely not doing a gTLD fast-track and insisting that the IDN
ccTLDs only come out at the same time as the gTLDs is another way of keeping
pressure on ICANN to launch the new gTLD program in a timely manner. There's
strong pressure from the governments to have their IDN ccTLDs sooner rather
than later...

On the plus side, I understand the desire to have certain types of gTLDs
that are ready for launch not be delayed by others that may still be too
problematic. This is what I have been advocating for CityTLDs for example,
as when they are supported by the relevant city's government, they are
probably some of the simplest TLD initiatives to validate. So the desire to
not have IDN gTLDs delayed by the full program is understandable. But the
problem is that IDNs encompass all types of gTLDs, so you could have
"simple" ones like CityTLDs and more complex applications that would require
lengthy validation.

So we're back to the basic problem that an IDN gTLD fast-track is too much
of a "mini-me" full gTLD program. If the fast-track is ready, you might as
well launch the full program. If it's not because there's still some issues
to iron out, the aren't we better off devoting all our resources to solving
them for the full program?

Thanks,

Stéphane


Le 07/06/09 01:14, « Edmon Chung » <edmon@xxxxxxxxxxxxx> a écrit :

> 
> After thinking about this for a few months, I think I disagree and think it
> in fact could do the opposite.
> 
> I think the act of moving forward with a possible Fast Track may encourage
> ICANN staff to keep the Full New gTLD process on track.
> 
> It could put the pressure on ICANN to make the New gTLD process happen so
> that there is no need to actually implement another Fast Track. :-)
> 
> Edmon
> 
> 
> 
>> -----Original Message-----
>> From: owner-gnso-idng@xxxxxxxxx [mailto:owner-gnso-idng@xxxxxxxxx] On
>> Behalf Of Avri Doria
>> Sent: Sunday, June 7, 2009 2:51 AM
>> To: gnso-idng@xxxxxxxxx
>> Subject: RE: [gnso-idng] motion for IDNG WG formation
>> 
>> 
>> Hi,
>> 
>> I have had similar concerns.
>> 
>> a.
>> 
>> 
>> On Thu, 2009-06-04 at 10:08 +1000, Adrian Kinderis wrote:
>>> A further point after some sleep.
>>> 
>>> Doesn't segmenting and effectively 'phasing' the release of gTLDs take
> some
>> of the pressure off the ASCII gTLD release.
>>> 
>>> I would have thought that we would have wanted to maintain maximum
> pressure
>> on the ICANN Board and Staff to keep momentum up. By taking away one of
> the
>> strongest impetuses we have, in IDN gTLDs, you effectively dilute this
> pressure.
>>> 
>>> Further, I fear that it could possibly be seen that an early release of
> IDN gTLD's
>> could be considered a 'beta release' for the process, with potential
> delays and
>> issues delaying the process adn subsequent launch of ASCII new gTLD's
> further.
>>> 
>>> Thanks.
>>> 
>>> 
>>> Adrian Kinderis
>>> 
>>> -----Original Message-----
>>> From: owner-gnso-idng@xxxxxxxxx [mailto:owner-gnso-idng@xxxxxxxxx] On
>> Behalf Of Mike Rodenbaugh
>>> Sent: Thursday, 4 June 2009 3:46 AM
>>> To: gnso-idng@xxxxxxxxx
>>> Subject: RE: [gnso-idng] motion for IDNG WG formation
>>> 
>>> 
>>> Hi all,
>>> 
>>> What is the purpose of the 90 minute call that Glen is trying to plan in
> the
>>> next 72 hours?
>>> 
>>> I have forwarded below string to BC List and am soliciting comments.  We
>>> have a draft Charter below, can't we hash it out on this list, or is
> this
>>> call necessary?
>>> 
>>> Any further comments to the below exchange would be welcome also, as the
>> BC
>>> tries to decide whether to support a WG Charter.  Adrian and Chuck both
> make
>>> very good points.
>>> 
>>> Thanks,
>>> Mike
>>> 
>>> -----Original Message-----
>>> From: owner-gnso-idng@xxxxxxxxx [mailto:owner-gnso-idng@xxxxxxxxx] On
>> Behalf
>>> Of Adrian Kinderis
>>> Sent: Wednesday, June 03, 2009 5:40 AM
>>> To: Gomes, Chuck; Edmon Chung; gnso-idng@xxxxxxxxx
>>> Subject: RE: [gnso-idng] motion for IDNG WG formation
>>> 
>>> 
>>> Thanks for taking the time to clarify Chuck.
>>> 
>>> I'll give it due consideration (i.e. sleep on it) and get back to you.
>>> 
>>> I think it is a slippery slope if you start this, however, in the
> scenario
>>> you suggest it could indeed be workable.
>>> 
>>> Thanks.
>>> 
>>> Adrian Kinderis
>>> 
>>> 
>>> -----Original Message-----
>>> From: Gomes, Chuck [mailto:cgomes@xxxxxxxxxxxx]
>>> Sent: Wednesday, 3 June 2009 10:32 PM
>>> To: Adrian Kinderis; Edmon Chung; gnso-idng@xxxxxxxxx
>>> Subject: RE: [gnso-idng] motion for IDNG WG formation
>>> 
>>> It's really not very complicated Adrian.
>>> 
>>> 1. The ideal approach for IDN TLDs is for both IDN ccTLDs and IDN gTLDs
> to
>>> be launched at the same general time frame.  Two reasons for this
>>> are: 1) To avoid giving either IDN ccTLDs or IDN gTLDs a competitive
>>> advantage over the other for a service that has had pent-up demand for
>>> years; 2) to give businesses and organizations that provide services
> and/or
>>> products in multiple countries to have a choice between registering
> their
>>> names in either an IDN gTLD or in multiple IDN ccTLDs or both.
> Regarding
>>> the latter, the Arab region is a good example; if I operate a business
> in
>>> multiple Arab countries, I may prefer to register my name in the Arabic
>>> script in one IDN gTLD rather than in multiple IDN ccTLDs; on the other
>>> hand, if I only operate my business in one Arab country, I might prefer
> to
>>> register it in the IDN ccTLD for that country.
>>> 
>>> 2. It now appears that IDN ccTLDs could be introduced significantly
> sooner
>>> than new gTLDs, so there could be a gap of 6 to 9 months between when
> IDN
>>> ccTLDs are implemented and when IDN gTLDs are implemented, assuming that
>> IDN
>>> gTLDs are introduced as part of the overall new gTLD process as
> originally
>>> planned.
>>> 
>>> 3. In case #2 happens, we could close the gap by having an IDN gTLD fast
>>> tract process.
>>> 
>>> You are of course correct that the overarching issues and other
> unresolved
>>> new gTLD implementation issues apply to IDN gTLDs as well as to ASCII
>> gTLDs.
>>> That is why any IDN gTLD fast track approach would have to address those
>>> issues.  There are probably multiple ways that could be handled; let me
>>> describe one possible scenario:  1) Let's assume that IDN ccTLDs are
>>> introduced by 1 January 2010; 2) let's also assume that the final DAG is
>>> approved in December 2009 as currently projected and that the minimum
>>> 4-month communication period starts then ; 3) an IDN gTLD fast track
> process
>>> could be implemented on 1 January 2010 just like the IDN ccTLD fast
> track
>>> process at the beginning of the communication period.  In this scenario,
> the
>>> final DAG would apply to any IDN gTLDs that are approved.  There of
> course
>>> could be different scenarios that would require other approaches but it
> does
>>> not seem unreasonable to think that processes could be developed to deal
>>> with them.
>>> 
>>> One question for you: Why should IDN ccTLDs get a first to market
> advantage
>>> over IDN gTLDs?
>>> 
>>> Regarding your last question, why should IDN gTLDs have a first to
> market
>>> advantage over ASCII gTLDs, I would say that it is much less of a market
>>> advantage when comparing IDN TLDs to ASCII TLDs than it is comparing IDN
>>> gTLDs to IDN ccTLDs.
>>> 
>>> Chuck
>>> 
>>>> -----Original Message-----
>>>> From: owner-gnso-idng@xxxxxxxxx
>>>> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Adrian Kinderis
>>>> Sent: Wednesday, June 03, 2009 5:18 AM
>>>> To: Edmon Chung; gnso-idng@xxxxxxxxx
>>>> Subject: RE: [gnso-idng] motion for IDNG WG formation
>>>> 
>>>> 
>>>> I'm sorry. I still don't get it.
>>>> 
>>>> I'm sorry I haven't been available for phone calls particularly those
>>>> that fall on or after midnight (as every one has lately, my bad).
>>>> 
>>>> Can someone please explain to me, in simple terms, why this needs to
>>>> proposed?
>>>> 
>>>> I understand completely that IDN ccTLD's should not delay the launch
>>>> of IDN new gTLD's however this seems somewhat superfluous to this
>>>> issue. If the ccNSO et al take too long sorting out their fast track
>>>> process so be it. Their loss. Go forth gTLD (IDN or otherwise)
>>>> 
>>>> Why should IDN new gTLD's be launched *prior* to ascii gTLD's as is
>>>> being suggested? Why don't the exact issues that are retarding the
>>>> release of ascii gTLD's (the four overarching issues plus others)
>>>> apply to IDN gTLD's? Are IDN's not subject to trademarks like ascii
>>>> gTLD's or will they not be subject to second level issues (as proposed
>>>> by the GAC)? Will registrants like McDonald's still have to register
>>>> in every script to protect their brand and ignore any clearing house
>>>> suggestion as proposed in the IRT Report?
>>>> 
>>>> What am I missing here?
>>>> 
>>>> I merely don't understand the point of why IDN gTLD's should get
>>>> special treatment when they aren't special at all. Why should IDN
>>>> gTLD's have any first to market advantage over ascii gTLD's?
>>>> 
>>>> Apologies if I am covering ground that is well travelled but I am at a
>>>> loss with the logic.
>>>> 
>>>> As it stands I will be suggested to my Constituency to vote against
>>>> any such motion.
>>>> 
>>>> Thanks.
>>>> 
>>>> 
>>>> 
>>>> Adrian Kinderis
>>>> 
>>>> -----Original Message-----
>>>> From: owner-gnso-idng@xxxxxxxxx
>>>> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Edmon Chung
>>>> Sent: Wednesday, 3 June 2009 6:29 PM
>>>> To: gnso-idng@xxxxxxxxx
>>>> Subject: [gnso-idng] motion for IDNG WG formation
>>>> 
>>>> 
>>>> Hi Everyone,
>>>> 
>>>> Below is a first stab at a possible motion to go with the IDNG
>>>> charter.  Please take a look and make suggestions.
>>>> 
>>>> Edmon
>>>> 
>>>> 
>>>> ========================================
>>>> 
>>>> WHEREAS:
>>>> 
>>>> The ICANN community has been discussing issues related to IDN and IDN
>>>> TLDs since 2000, and the ICANN board as early as September 2000
>>>> recognized "that it is important that the Internet evolve to be more
>>>> accessible to those who do not use the ASCII character set";
>>>> 
>>>> There is expressed demand from the community, especially from language
>>>> communities around the world who do not use English or a Latin based
>>>> script as a primary language, including the CJK (Chinese Japanese
>>>> Korean) communities and the right-to-left directional script
>>>> communities (e.g. Arabic, Hebrew, Persian, etc.), for advancing the
>>>> introduction of Internationalized Top-Level Domains (IDN TLDs);
>>>> 
>>>> GNSO IDN WG successfully completed its outcomes report in March 2007
>>>> and the GNSO Council approved the incorporation of its findings in the
>>>> GNSO Final Report on the Introduction of New gTLDs in September 2007,
>>>> describing policy requirements for the introduction of IDN gTLDs;
>>>> 
>>>> The community observes the successful development of the IDN ccTLD
>>>> Fast Track based on the IDNC WG recommendations, and the ongoing
>>>> progress for the Implementation of the IDN ccTLD Fast Track Process;
>>>> 
>>>> The implementation of the New gTLD process is ongoing and the schedule
>>>> and development of the implementation should continue;
>>>> 
>>>> GNSO Council had made comments in response to the ccNSO-GAC Issues
>>>> Report on IDN Issues, as well as in its comments on the IDNC WG Final
>>>> Report expressed that "the introduction of IDN gTLDs or IDN ccTLDs
>>>> should not be delayed because of lack of readiness of one category,
>>>> but if they are not introduced at the same time, steps should be taken
>>>> so that neither category is advantaged or disadvantaged, and
>>>> procedures should be developed to avoid possible conflicts";
>>>> 
>>>> GNSO Council made a resolution in January 2009 to assert that "the
>>>> GNSO Council strongly believes that neither the New gTLD or ccTLD fast
>>>> track process should result in IDN TLDs in the root before the other
>>>> unless both the GNSO and ccNSO so agree";
>>>> 
>>>> An IDN gTLD Fast Track, if successfully implemented, could be
>>>> introduced in close proximity with the IDN ccTLD Fast Track in the
>>>> case that the New gTLD process is further delayed, and could address
>>>> the concerns expressed by the GNSO Council regarding possible
>>>> conflicts if IDN gTLDs and IDN ccTLDs are not introduced at the same
>>>> time.
>>>> 
>>>> 
>>>> RESOLVED:
>>>> 
>>>> To recommend to the ICANN Board that an IDNG WG (Internationalized
>>>> Generic Top-Level Domain Working Group) be formed under the Proposed
>>>> Charter for the IDNG Working Group (IDNG WG).
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
> 






<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy