ICANN ICANN Email List Archives

[gnso-vi-feb10]


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

RE: [gnso-vi-feb10] New Proposal

  • To: Jon Nevett <jon@xxxxxxxxxx>, "Gnso-vi-feb10@xxxxxxxxx" <Gnso-vi-feb10@xxxxxxxxx>
  • Subject: RE: [gnso-vi-feb10] New Proposal
  • From: Milton L Mueller <mueller@xxxxxxx>
  • Date: Tue, 22 Jun 2010 10:40:06 -0400

I guess I don't see how this proposal makes any significant concessions or 
movements towards those of us more in the Free Trade or CAM camp. I don't see 
where it picks up support from new quarters. 

You might want to explain the rationale better - what does this do to address 
concerns about new entry and innovative business models? SRMU and 
Community/Orphan exceptions are meaningless afterthoughts, aren't they?. I see 
no political advance here in terms of the amount of support this proposal is 
likely to generate. I am quite open to explanations that prove otherwise, but 
as far as I can see this is no breakthrough.

-MM

> -----Original Message-----
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-
> feb10@xxxxxxxxx] On Behalf Of Jon Nevett
> Sent: Tuesday, June 22, 2010 5: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




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

Privacy Policy | Terms of Service | Cookies Policy