<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-vi-feb10] Another angle on allowing VI/CO
- To: vgreimann@xxxxxxxxxxxxxxx
- Subject: Re: [gnso-vi-feb10] Another angle on allowing VI/CO
- From: Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>
- Date: Wed, 21 Apr 2010 16:23:46 +0200
Volker,
I agree with the premise of your first paragraph, but you lost me on the rest
of your email.
If a .BANGKOK was launched, local registrars could be interested, so could
foreign registrars. No matter really, because the important issue is that only
ICANN accredited registrars be able to service the TLD.
So to make the point I think you are trying to make, it's best to choose TLDs
with narrower scopes. And this goes back to the discussions we've been having
for days on this list. To me, SRSUs should definitely be granted exception
status and not be required to farm their TLD out to multiple registrars. I
would also argue that may be the case for SRMUs, but then we do get into the
difficulty of identifying who the multiple users are.
So in essence, I agree that imposing artificial percentage limits may not suit
specific TLD models.
Stéphane
Le 21 avr. 2010 à 16:12, Volker Greimann - Key-Systems GmbH a écrit :
>
> We have seen a number of proposals that favor an arbitrary limitation on
> cross-ownership without explaining how for example 15% are effectively
> different from 30% or 50% or even 100% with regard to the interests of the
> consumers. OTOH, consumer interests will most definitely be hurt by imposing
> limitations that will effectively bar certain TLD proposals from going live
> in the first place.
>
> I think that we might be able to approach the problem from another angle, at
> least for some community TLDs, where only a limited number of registrars will
> be interested in becoming accredited. For example, a dotBangkok will
> probably only be of interest to Thai registrars, and find its market in that
> area. Thai Registrars (I have no idea how many there are, but it can't be
> that many) may be interested in investing in and setting up a registry for
> that TLD, simply because they see a market for it, but would not be likely to
> meet a 15% cross-ownership requirement. Similarly , in many countries there
> are no ICANN accredited registrars at all, but local TLDs may be proposed.
> Should the registry operator be forced to operate through international
> registrars only, or be allowed to create a registrar himself to be able to
> reach his target market more effectively. Should we not therefore propose a
> solution that makes such a new TLD possible, rather than preventing it from
> being established in the first place by setting arbitrary limitations on the
> way registries or registrars may be owned?
>
> Just as an example: The current DAG requires a letter of non-objection from
> the regional/state/city government for applications for regional TLDs. If the
> community now moves beyond the requirements to actual endorsement, ICANN may
> be able to waive the limitations against VI/CO for such applications. As long
> as the community favors such a model, it should be possible. Communities
> without officially accepted self-representation would be excluded from this
> option, but more flexibility in the setup of a registrar model for
> communities that do would be possible. In all cases, equal access should be
> guaranteed, naturally. To excemplify this: if the state of Texas officially
> endorsed a proposal for .TEXAS even if the model is set up with full VI/CO,
> this could be accepted by ICANN as sufficient support for such a model for
> that application, provided the VI/CO registry offers equal access and
> conditions to all interested registrars.
>
> I agree that there need to be safeguards in place that prevent abuse and will
> guarantee equal access, but even here, restrictions may apply. Should a
> french regional TLD be forced to provide all registrar information in English
> for the sake of equal access?
>
> --
>
> Best regards,
>
> Volker A. Greimann
> Key-Systems GmbH
>
>
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|