ICANN ICANN Email List Archives

[gnso-vi-feb10]


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

Re: [gnso-vi-feb10] RE: "livability"

  • To: Avri Doria <avri@xxxxxxx>, Milton L Mueller <mueller@xxxxxxx>, "'Gnso-vi-feb10@xxxxxxxxx'" <Gnso-vi-feb10@xxxxxxxxx>
  • Subject: Re: [gnso-vi-feb10] RE: "livability"
  • From: Volker Greimann - Key-Systems GmbH <vgreimann@xxxxxxxxxxxxxxx>
  • Date: Fri, 11 Jun 2010 17:23:59 +0200


Hi Avri, Hi Milton,

I had noted this exception, however, as most community TLDs will struggle to surpass this number, this is effectively an exclusion of equal access. The point where equal access is required is the point where implementing the new TLD will not make much sense for most registrars anymore, thereby protecting the monopoly. Even in community TLDs with huge growth potential, the registry can effectively market the most valuable domain names itself. While an auction system as used with modern launches has a similar effect, most registries offer kickbacks to registrars that brought the winning registrant.

I do not get your argument of registries using being ineffective or having to bear a large investment if they use registrars. Do not registrars act as effective multipliers for most TLDs? Registrars also reduce the need for end-customer support, thereby reducing costs. The use of registrars will _help_ new TLDs to become viable, not obstruct them.

Volker

But this exception is only suggested for the first 50K names (all threshhold 
numbers in CAM are negotiable).  After that the equal access provision kicks in 
and the registrants are free to transfer any of those names and all new 
registrants come in from the whole field of willing ICANN registrars.

It does not abandon th equal access clause, but just gives a temporary 
exception to it.  The proposal is trying to find a compromise point that allows 
the new community Registry to get off the ground with a minimal investment in 
the larger Registry-Registrar support structure.  But once it is viable, and 
50k was (as a compromise between 0 and 100K that were suggested) defined as the 
viability mark.

a.

On 11 Jun 2010, at 10:34, Volker Greimann - Key-Systems GmbH wrote:

CAM has in my view one major flaw as it abandons the equal access principle for 
registrars and goes so far as to proposae no registrar is necessary even for 
community TLDs, a position I just cannot sign on to. In its other aspects, CAM 
has some very interesting ideas and proposals for a system of preliminary 
checks, many of which bear consideration for implementation.

We still have a long way ahead of us with respect to buiding a system to 
prevent, restrict or punish abuse prior to and after delegation and I see many 
aspects from CAM's regulatory framework that would come into play at that stage.

Volker
The way in which I can see someone living with the free-trade and not the CAM 
is if they don't believe there should be any regulation or controls, i.e. a 
completely - laissez-faire open system.

So when I checked both, I assumed the bottom-up policy driven imposition of 
some regulatory framework, but I can imagine that others do not want such a 
framework.

I think for some people that is, in fact, a big problem with the CAM proposal, 
that it contains an ongoing notion of regulation on the behavior of registrars 
in situation where there is co-ownership and affiliation with a registry or 
RSP.  Some do not like the idea of regulation in general and some do not feel 
it could be implemented in time to not delay the start of open season on gTLDS 
and think that CO limitations are good enough to do the trick.  I disagree, but 
I can see the points of view.  I once tried believing in a world without 
regulatory frameworks (really worked at since so many people I respected 
thought that way), but was taught  by experience that it doesn't work.  And I 
believe that the basic structure of a regulatory framework, as we described in 
CAM is enough to get started, though we would have to work hard over the next 
months to make sure the full initial policy was in place before the beginning 
of applications.

And while I have an extremely  strong aversion to ICANN making policy, I have 
an equally strong support of ICANN enforcing policy and believe it is something 
they can do effectively if the policy requires them to do so.

a.

On 11 Jun 2010, at 09:53, Milton L Mueller wrote:


Another point (I am obviously in the process of filling out the poll)

The "free trade" proposal is not really a proposal but a philosophy or 
approach. It says that we should have a more open market and that cross ownership limits 
are not the proper tool for counteracting stated or perceived harms. I agree. In this 
respect, it is identical to the CAM proposal. However, it does not propose any specific 
method for preventing harms. The CAM proposal does, proposing that any anticipated harms 
could be checked by auditing requirements and by antitrust checks.

Thus, it is truly incomprehensible to me how anyone could vote that they support or could "live with" with "free trade" proposal and "oppose" the CAM proposal. It just doesn't make any sense. I also wish to state that having this poll was a very good idea. Viewing the selections is really an eye-opener and I think greatly advances the dialogue. --MM

-----Original Message-----
From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-
feb10@xxxxxxxxx] On Behalf Of Milton L Mueller
Sent: Friday, June 11, 2010 9:35 AM
To: Gnso-vi-feb10@xxxxxxxxx
Subject: [gnso-vi-feb10] "livability"


When we talk about whether one can "live with" the DAGv4 proposal, I
have one major uncertainty. My understanding is that DAGv4 ownership
limits and separations would ONLY apply to new applicants, and NOT to
incumbents and their existing TLDs. Thus, DAGv4 would prevent
registrars from having any significant ownership interest in registries
of new gTLDs, but it would not require Afilias/Neustar/VeriSign et al
to divest their existing ownership interests in registrars. Is that
correct?

Milton L. Mueller
Professor, Syracuse University School of Information Studies
XS4ALL Professor, Technology University of Delft


--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann
- Rechtsabteilung -

Key-Systems GmbH
Prager Ring 4-12
66482 Zweibrücken
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 861
Email: vgreimann@xxxxxxxxxxxxxxx

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.key-systems.net/facebook
www.twitter.com/key_systems

Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 1861 - Zweibruecken
Umsatzsteuer ID.: DE211006534

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede 
Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist 
unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per 
E-Mail oder telefonisch in Verbindung zu setzen.

--------------------------------------------

Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann
- legal department -

Key-Systems GmbH
Prager Ring 4-12
DE-66482 Zweibruecken
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 861
Email: vgreimann@xxxxxxxxxxxxxxx

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Follow us on Twitter or join our fan community on Facebook and stay updated:
www.key-systems.net/facebook
www.twitter.com/key_systems

CEO: Alexander Siffrin
Registration No.: HR B 1861 - Zweibruecken
V.A.T. ID.: DE211006534

This e-mail and its attachments is intended only for the person to whom it is 
addressed. Furthermore it is not permitted to publish any content of this 
email. You must not use, disclose, copy, print or rely on this e-mail. If an 
addressing or transmission error has misdirected this e-mail, kindly notify the 
author by replying to this e-mail or contacting us by telephone.










--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann
- Rechtsabteilung -

Key-Systems GmbH
Prager Ring 4-12
66482 Zweibrücken
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 861
Email: vgreimann@xxxxxxxxxxxxxxx

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.key-systems.net/facebook
www.twitter.com/key_systems

Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 1861 - Zweibruecken
Umsatzsteuer ID.: DE211006534

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede 
Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist 
unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per 
E-Mail oder telefonisch in Verbindung zu setzen.

--------------------------------------------

Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann
- legal department -

Key-Systems GmbH
Prager Ring 4-12
DE-66482 Zweibruecken
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 861
Email: vgreimann@xxxxxxxxxxxxxxx

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Follow us on Twitter or join our fan community on Facebook and stay updated:
www.key-systems.net/facebook
www.twitter.com/key_systems

CEO: Alexander Siffrin
Registration No.: HR B 1861 - Zweibruecken
V.A.T. ID.: DE211006534

This e-mail and its attachments is intended only for the person to whom it is 
addressed. Furthermore it is not permitted to publish any content of this 
email. You must not use, disclose, copy, print or rely on this e-mail. If an 
addressing or transmission error has misdirected this e-mail, kindly notify the 
author by replying to this e-mail or contacting us by telephone.










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

Privacy Policy | Terms of Service | Cookies Policy