ICANN ICANN Email List Archives

[gnso-vi-feb10]


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

RE: [gnso-vi-feb10] New Proposal & ccTLDs

  • To: <Gnso-vi-feb10@xxxxxxxxx>
  • Subject: RE: [gnso-vi-feb10] New Proposal & ccTLDs
  • From: "Ron Andruff" <randruff@xxxxxxxxxxxxxxx>
  • Date: Tue, 22 Jun 2010 09:13:44 -0400

With due respect Antony, it borders on the ludicrous to assert that
registrars are the only ones who are going to bring innovation to
registries.

RA

Ronald N. Andruff
RNA Partners, Inc.


-----Original Message-----
From: Antony Van Couvering [mailto:avc@xxxxxxxxxxxxxxxxxxxx] 
Sent: Tuesday, June 22, 2010 9:07 AM
To: Ron Andruff
Cc: Volker Greimann; <Gnso-vi-feb10@xxxxxxxxx>
Subject: Re: [gnso-vi-feb10] New Proposal & ccTLDs

The business, regulatory, and advisory arrangements with governments ccTLDs
vary across the board, from complete government control to complete
non-involvement.  The level of consumer harm, as far as I can tell, is
similar. The level of investment, revenue, innovation, and domain volume,
however, is inversely correlated to restrictive policies. And as a rule, the
more government involvement, the more restrictive the policies.   Compare,
for instance, the hands-off regulatory regime of Germany with the
command-and-control style that has characterized .it or .fr, and then look
at registration volumes. I suppose you could say that because there are
fewer customers, there are correspondingly fewer harms, but that is cold
comfort.  

Sent from my handheld.   

On Jun 22, 2010, at 12:55, "Ron Andruff" <randruff@xxxxxxxxxxxxxxx> wrote:

> 
> Volker,
> 
> Often is has been noted that ccTLDs operate without consumer harm, but
> (while I don't know this as fact and welcome others to confirm or clarify)
> it appears to me that most ccTLDs have significant government oversight or
> are run by governments, academic institutions or not-for-profits.  I am
> aware that some smaller nations have outsourced and contracted operations
to
> commercial entities, but the larger measure is as noted above.  If I am
> correct in my understanding, it is understandable that there has been less
> harm in that group of TLD operators and thus the argument about ccTLDs is,
> in fact, not a supporting one for VI.
> 
> If I am incorrect, I welcome corrections to my understanding.
> 
> Thanks,
> 
> 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
> Sent: Tuesday, June 22, 2010 6:27 AM
> To: Jeff Eckhaus
> Cc: Gnso-vi-feb10@xxxxxxxxx
> Subject: Re: [gnso-vi-feb10] New Proposal
> 
> 
> While this proposal may be a step in the right direction, especially 
> when considering the new additions for RSPs, I see it lacking in many 
> respects. The blind focus of the 15% limit as a fix-all without 
> addressing any of the perceived harms should be seen as what it is: 
> simple protectionism of the interests of current providers by keeping 
> registrars from the registry market. 
> 
> I therefore propose to reintroduce the most crucial exception of the JN2 
> proposal: allowing Registrars to act as Registries provided they agree 
> not to sell or resell their own TLD, especially in the case of community 
> TDs. Please bear in mind that many ccTLDs operate successfully and 
> without consumer harm selling their own TLDs, so we registrars are 
> already making a huge concession here, in fact this is the line I will 
> not be able go beyond.
> 
> Please also define the term structural seperation. Will it require 
> seperate executive staff, support staff, or seperation of system? Any 
> such seperation will drive up the price of operations. While I agree 
> that financial seperation makes absolute sense, I do not see this for 
> structural seperation of it means what I think it does.
> 
> It is lacking a policy review procedure, which is needed to ease up the 
> requirements in the light of experience.
> 
> 
> 
> Volker
>> One question -  does this proposal restrict a Registrar  from
> participating in the gTLD round as an applicant? 
>> 
>> 
>> Thanks
>> 
>> Jeff
>> 
>> 
>> -----Original Message-----
>> From: owner-gnso-vi-feb10@xxxxxxxxx
[mailto:owner-gnso-vi-feb10@xxxxxxxxx]
> On Behalf Of Jon Nevett
>> Sent: Tuesday, June 22, 2010 11:57 AM
>> To: Gnso-vi-feb10@xxxxxxxxx
>> Subject: [gnso-vi-feb10] New Proposal 
>> 
>> 
>> VI WG Colleagues:
>> 
>> Here is a very high level proposal that is coming out of our subgroup
> conversations (not every member of the subgroup supports)
>> 
>> We are looking for a catchy name -- any ideas?  (nothing offensive
Milton)
>> 
>> 
>> New Proposal
>> 
>> **15% restriction going both ways, including resellers and Registry
> Service Providers (Back-end technical service providers) regardless of TLD
> -- taken from RACK
>> 
>> **Exception for Single Registrant Single User for corporate use only --
> (sub group believed that exception was not necessary as registry schedule
of
> reserved names already provides for this, but good to have in contract for
> clarity) -- mostly taken from JN2
>> 
>> **Exception for back-end (RSP) IF a) RSP doesn't control registry or its
> policy, pricing and registrar selection; b) there is structural separation
> between RSP function and affiliated registrar function; AND c) RSP has
> direct contract with ICANN requiring data
> security/confidentiality/structural separation with graduated sanctions
> including de-accreditation for any violations -- new idea
>> 
>> **Use of registrars required; registry may select based on objective
> criteria; Non Discrimination & Equal Access for registrars selected --
taken
> from JN2
>> 
>> **Group continues work on Single Registrant Multiple User and
> Community/Orphan exceptions -- not necessary to be in place at time of
final
> AG
>> 
>> 
>> Looking forward to discussing on Thursday.
>> 
>> Thanks!
>> 
>> Jon
>> 
>> 
> 
> 
> --
> 
> Fur Ruckfragen stehen wir Ihnen gerne zur Verfugung.
> 
> Mit freundlichen Grusen,
> 
> Volker A. Greimann
> - Rechtsabteilung -
> 
> Key-Systems GmbH        Prager Ring 4-12                            Web:
> 66482 Zweibrucken                           www.key-systems.net
> <http://www.key-systems.net/>
> Tel.: +49 (0) 6332 - 79 18 50               www.domaindiscount24.com
> <http://www.domaindiscount24.com/>
> Fax.: +49 (0) 6332 - 79 18 51               www.ISPproxy.net
> <http://www.ispproxy.net/>
> Email: vgreimann@xxxxxxxxxxxxxxx <mailto:vgreimann@xxxxxxxxxxxxxxx>
> www.RRPproxy.net <http://www.rrpproxy.net/>
> 
> Geschaftsfuhrer: Alexander Siffrin
> Handelsregister Nr..: HR B 1861 - Zweibruecken
> Umsatzsteuer ID.: DE211006534
> 
> Der Inhalt dieser Nachricht ist vertraulich und nur fur den angegebenen
> Empfanger bestimmt. Jede Form der Kenntnisnahme, Veroffentlichung oder
> Weitergabe durch Dritte ist unzulassig. Sollte diese Nachricht nicht fur
> 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) 6332 - 79 18 85
> Fax.: +49 (0) 6332 - 79 18 61
> Email: jpfeiffer@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