<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-vi-feb10] Short-term schedule
- To: "Mike O'Connor" <mike@xxxxxxxxxx>, "'Gnso-vi-feb10@xxxxxxxxx'" <Gnso-vi-feb10@xxxxxxxxx>
- Subject: Re: [gnso-vi-feb10] Short-term schedule
- From: Volker Greimann - Key-Systems GmbH <vgreimann@xxxxxxxxxxxxxxx>
- Date: Thu, 01 Jul 2010 18:17:57 +0200
Hi Mikey,
thank you for the starter list. Here are a few thoughts regarding the
atoms. I wish to point out that I have during the ICANN meeting gotten
the feeling from some comments that the VI PDP is being used to address
some wider concerns some have with possible abuse and harms from the new
gTLD process not felt to be addressed sufficiently by ICANN at this time.
Harm -- Insider trading, anti-competitive collusion:
This needs to be controlled with strong equal access provisions. Please
consider however that CO does not cause such abuse. The danger still
exists even if there is 100% seperation.
Harm -- favorable access (to operational support, deleted names, traffic
data, "shelf space", etc.)
I may be going out on a limb here, but there will always be favorable
access in some form, especially when it comes to operational support.
Take a regional TLD, where language support is limited. Local registrars
will always receive "better" support due to the lack of the language
barrier.
Regarding deleted names: We might require new gTLD registries to publish
droplists, similar to what NASK is doing right now for .pl . Making such
abusable data publicly (as in: all ICANN registrars) available would
greatly reduce the risk of abuse. Traffic data might also be made public
to all registrars.
How about this: ICANN shall require all RO's and RSPs to make available
such data to all accredited registrars wia a special database.
Harm -- higher prices (predatory pricing, account lock-ins,
transfer-out pricing, etc.)
Occurs already with R-R seperation.
Harm -- Reduced innovation, choices for consumers/registrants
I agree with this one as a result from blanket restictions on registrars.
Harm -- Reduced innovation, choices for registry applicants
I agree with this one as a result from blanket restictions on registrars.
Option -- Percent ownership
Does not resolve any one of the issues. May reduce risks, but only by a
fractional amount. All proposed harms are just as likely with no CO/VI
as will full CO/VI. Any abusive registray may still chose to sell the
critical information to an abusive registrar and partner with them in
the proceeds, regardless of any ownership or control.
Option -- Control
See above.
Option -- Registry service providers
I do not get this option. RSPs are a possibility by the current draft.
Option -- Exception for SRSU
While I agree with this exception in general, we need to be very
cautious in drafting this exception to limit it to true SRSU TLDs.
Option -- Cross-TLD
I believe this refers to limiting CO/VI entities beyond (insert
arbitrary number here) % ownership/control from selling or reselling
their own TLD. I like the solution proposed by JN2 for this.
Option -- Contracts for non-Ry/Rr's (eg. RSPs)
Makes absolute sense and should be adopted even if we do not reach an
agreement on any other issue.
I would like to add another options:
Option: full data access for ICANN enforcement. ICANN enforcement teams
need to be authorized to at any time request any relevant document,
registration information or database for a new gTLD required to
investigate any report of abuse. This right extends to Registrars, RSPs
and Registry Operators alike.
Option: access to data prone to abuse for all registrars accredited with
said TLD.
Issue -- Compliance/Enforcement
Enforcing compliance or enforcement of penalties are possible and will
have to be implemented regardless of any restrictions on CO/VI. All
harms are just as likely or unlikely with or without CO/VI. Therefore,
regardless on the solutions proposed, we should make sure
Compliance/Enforcement teams are well prepared and funded for the new
gTLD era. Even if the 2% horror scenario becomes a fact. The new TLDs
need to be controlled.
Issue -- Compliance with competion law
Will be enforced by local authorities anyway, if any possible violation
is seen/brough before them. However I doubt they will care about the
small fry.
--
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
>>>
|