[Gnso-newgtld-wg-wt4] Registry Services straw-person

[Rubens Kuhl]

> Em 31 de ago de 2017, à(s) 14:10:000, Aikman-Scalese, Anne <AAikman at lrrc.com> escreveu:
> 
> Well here we are definitely establishing a disincentive to proposing new innovative services.  We are saying in this straw proposal that if you propose new services, it is going to cost you more to apply and we don't know how much more.   This is a terrible  idea running a program which is otherwise touted as fostering innovation and competition.

Anne,

Competition doesn't necessarily need new services, only new players and/or new methods to deliver current services.
As for innovation, the evidence-driven nature of PDPs makes it undeniable that none was suggested in 2012. The only examples some may quote are Google dotless proposal, which is similar to what Verisign did for a while in .COM/.NET, and .frogans, an innovation that required no new registry services (see https://www.icann.org/sites/default/files/tlds/frogans/frogans-agmt-html-19dec13-en.htm <https://www.icann.org/sites/default/files/tlds/frogans/frogans-agmt-html-19dec13-en.htm> agreement for reference). 

We don't know how much would be the fee because we can't know at this point, but that's something will have to be clear to any applicants, and goes more to the predictability discussions than to WT4 discussions. 


> 
> My proposal is that there be two tracks - and not that the application fee changes if you propose new services.  If no new services are proposed in evaluation, you go to one dept/staff set.  If new services are proposed, you go to another section for evaluation so that at least some new services proposals get launched in parallel to those proceeding without new services.  

That is exactly the opposite of streamlining, and the opposite of cost-recovery. But the WT dealing with applicant support could be amenable to the idea of subsidizing innovative applications, and I suggest raising that at that forum... 

> New services should in fact be part of evaluation (and not delayed to contracting phase where the community is not involved.)

The Registry Services Policy already specifies that community involvement in new services only happens when a security and stability concern is identified, and we can't go against that policy.  And this is something that already happens every day... even services where a competition concern is identified are not prevented from being deployed: they just get a 45-day penalty where a competition authority may or may not prevent the launch of the service. 

Some references on the current Registry Services policy:
https://gnso.icann.org/en/issues/registry-services/final-rpt-registry-approval-10july05.htm <https://gnso.icann.org/en/issues/registry-services/final-rpt-registry-approval-10july05.htm> (GNSO Policy as approved by Council)
https://gnso.icann.org/en/meetings/review-process-registry-change-requests25apr05.pdf <https://gnso.icann.org/en/meetings/review-process-registry-change-requests25apr05.pdf> (Process flowchart as approved by Council)
https://www.icann.org/resources/board-material/resolutions-2005-11-08-en <https://www.icann.org/resources/board-material/resolutions-2005-11-08-en> (Board resolution approving GNSO Registry Services Policy)
https://www.icann.org/resources/unthemed-pages/net-registry-agreement-2005-07-01-en <https://www.icann.org/resources/unthemed-pages/net-registry-agreement-2005-07-01-en> (.NET agreement of the time, mentioned in Board Resolution)



Rubens





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170831/d5756565/attachment.html>