ICANN ICANN Email List Archives

[gnso-vi-feb10]


<<< 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 >>>

Privacy Policy | Terms of Service | Cookies Policy