<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-vi-feb10] New proposal variant
- To: "'VI'" <gnso-vi-feb10@xxxxxxxxx>
- Subject: RE: [gnso-vi-feb10] New proposal variant
- From: "Ron Andruff" <randruff@xxxxxxxxxxxxxxx>
- Date: Wed, 23 Jun 2010 06:18:18 -0400
I agree with Berry that these elements, along with Alan's variant
contribution, should be implemented regardless of where VI dialogue ends up.
Indeed, if these are the only results of this WG, I would welcome them as
cornerstones in our community's on-going effort toward building
institutional confidence.
Thanks for putting forward some good building blocks, Volker. Let's see
where they take us.
Kind regards,
RA
Ronald N. Andruff
RNA Partners, Inc.
-----Original Message-----
From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx]
On Behalf Of Volker Greimann - Key-Systems GmbH
Sent: Wednesday, June 23, 2010 5:45 AM
Cc: Alan Greenberg; VI
Subject: Re: [gnso-vi-feb10] New proposal variant
Hi Alan,
I like it. Consider it stolen and implemented in my Law and Order
suggestion.
Volker
> ________________________________________
> From: owner-gnso-vi-feb10@xxxxxxxxx [owner-gnso-vi-feb10@xxxxxxxxx] On
Behalf Of Alan Greenberg [alan.greenberg@xxxxxxxxx]
> Sent: Wednesday, June 23, 2010 1:51 AM
> To: VI
> Subject: [gnso-vi-feb10] New proposal variant
>
> I would like to propose a variant. It could be applied to a proposal that
allows registry/registrar integration for marketing TLDs other than those
offered by the registry (such as JN2) or perhaps to allow the "Afilias et
al" proposal to allow such relationships. The proposal provides more
specificity to my previous statements that VI rules could be relaxed if the
registrars involved in the VI relationship were bound by explicit
contractual conditions.
>
> In essence, it puts disclosure and reporting requirements on the registrar
and its partners (partners being loosely defined) and explicitly commits
them to not deal, directly or indirectly, in their registry's own TLDs.
>
> Any registrar involved (with >15% ownership or control) must disclose the
details of:
> - Their family of registrars - owned or controlled (same definition) by
them, or co-owned/controlled.
> - All owned/controlled resellers that they deal with, directly or
indirectly.
>
> All of these entities will be bound by direct contract with ICANN to abide
by a set of rules (which among others proscribe dealing with the domain(s)
offered by the registry arm). The ownership/control relationships will be
made public. There would be a requirement for ongoing reports certifying
compliance and strict, severe penalties for non-compliance.
>
> Among other things, this would contractually restrict two cases which
previous proposals have not addressed.
>
> a) Consider the scenario where J owns registry X and registrar Y. X and Y
are both owned by J but are not otherwise related. As such, the registry
agreement signed by X can in no way bind Y. This variant now binds Y to
specific disclosure and reporting terms associated with VI.
>
> b) Registry X and registrar Y have some sort of >15$ ownership or control.
Y has a controlled reseller R. R also resells for a completely unrelated
registry P. Under prior rules, R could market the X TLDs (routing
registrations through P). This variant precludes such marketing
arrangements.
>
> In summary this proposal variant puts new contractual marketing
restrictions, disclosure and reporting terms on those registrars who want to
play in the VI sandbox. It also requires contracts with controlled
resellers. These are just agreement to restrict marketing, disclosure and
reporting requirements, and not monetary, so they do not form a new class of
"contracted party". One could think of this as a form of certification of
such resellers.
>
> The overall intent is not to eliminate any potential gaming - nothing can
do that. But it does give ICANN compliance a basis to recognize potential
infractions and, if found, it gives them tools to achieve compliance.
>
> This proposal variant is being suggested without being fully fleshed out,
but given the timing, I thought it should go out earlier rather than later.
>
> Alan
>
>
--
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
>>>
|