<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-vi-feb10] New Proposal
- To: Gnso-vi-feb10@xxxxxxxxx
- Subject: Re: [gnso-vi-feb10] New Proposal
- From: Richard Tindal <richardtindal@xxxxxx>
- Date: Tue, 22 Jun 2010 12:51:55 +0200
The Belgium Amalgam?
Btw, I support this proposal. I think prohibitions on RSPs make less sense
than they do on ROs - given, as you state, a rule that prevents the RSP
from controlling registry policy.
The only issue then is data security (queries, lookups, etc). I think the
accreditation system you propose would fix that.
I like this compromise because it allows registrars to participate in the
registry services business, but not control the actual registry operator.
RT
On Jun 22, 2010, at 11:56 AM, Jon Nevett wrote:
>
> 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
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|