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

[Rubens Kuhl]

> Em 5 de set de 2017, à(s) 15:38:000, Aikman-Scalese, Anne <AAikman at lrrc.com> escreveu:
> 
> Jeff,
> Thanks for your note.  I certainly don’t see a problem with charging fees if a Technical Panel has to be called in – in other words, maintain the status quo in this regard.  With respect to maintaining the status quo, my understanding of the existing Application Question is that it states as follows:

It is actually a bit different than that, i'll explain that below. 

>  
> 23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns.
> The following registry services are customary services offered by a registry operator:
> A.   Receipt of data from registrars concerning registration of domain names and name servers.
> B.   Dissemination of TLD zone files.
> C.   Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service).
> D.   Internationalized Domain Names, where offered.
> E.   DNS Security Extensions (DNSSEC). The applicant must describe whether any of
> these registry services are intended to be offered in a manner unique to the TLD.
> Additional proposed registry services that are unique to the registry must also be described.  (Emphasis added by me.)
>  
> You indicated that both Straw proposals would be discussed and considered.  Later Sarah and I received a redline of the existing (Rubens) proposal  from Kurt Pritz which he said Rubens had asked him to prepare.   That redline raises additional issues.  For example, it says that preapproved services will include

I can't comment on it while it has not been posted on the list, so if Sarah, Kurt and you believe it's ready I encourage all to send it to the list... just as reference, the latest straw-person (which as I said I don't think it's a one's person proposal since it's already in its 4th generation after many suggestions) was sent to the list by me September 1, 1331 UTC. 

>  
> (a)    IDN registrations.  (permitting IDN registrations raise issues of customer confusion. 

Those issues of customer confusions are already address in the IDN Guidelines, a document that was the primary reference during the 2012-round and still is. 


> It also raises trademark Sunrise issues since many TM owners hold idn trademark registrations for their English marks. )  

I don't recall any suggestion during the IDN discussions to stop provisioning IDN registration services due to TM issues... and that would contradict years of ICANN efforts in that regard. Anyway, that would be on-topic for the RPM PDPs WG, not for Subsequent Procedures... 

> (b)    “additional marketplace Rights Protection Mechanisms that have been identified as “blocks”.  (I find myself wondering whether Avri has any comments on this in her personal capacity.  I may really like this but it doesn’t change the procedural aspect of what we are doing.)
> (c)    Bulk Transfer After Partial Portfolio Acquisition (BTPPA).  (Sorry I don’t know what a “BTPPA” service is.)

Curiously one piece news including BTPPA surfaced after the call, and it can give a first glimpse on what BTPPA is:
http://domainnamewire.com/2017/09/01/namecheap-sues-enom-tucows-demands-transfer-4-million-domains/ <http://domainnamewire.com/2017/09/01/namecheap-sues-enom-tucows-demands-transfer-4-million-domains/>

The original Verisign BTAPPA request can be found here:
https://www.icann.org/en/system/files/files/verisign-btappa-request-29jul09-en.pdf <https://www.icann.org/en/system/files/files/verisign-btappa-request-29jul09-en.pdf>



>  
> So we have more to discuss than the two Straw Person proposals put forward.  We also need to discuss the preapproved services. 

Since at least one of them mentioned pre-approved services, we can discuss that while discuss the straw person(s)... 

> Charging  fees for evaluation of additional services is not the only policy issue. 

And while it's a policy issue, it's not a WT4 issue... 

> There is also a policy issue as to which point in time the proposed services will be evaluated.  My proposal says proposed new services should be included in the application phase for proper transparency and evaluation at that time. (This seems to be the case in the existing version of Question 23.)  


> The redline circulated by Kurt to me and Sarah (apparently at Ruben’s request),

The only message I sent was sent to the list; no message was sent by me to any of 3 and no request to be passed along was made. The only suggestion I did, during the call and after in the list, was for those said they are willing to propose something different, to compile something and send it to the list. 

> says the applicant can choose at what stage it wants the new services to be evaluated.  So as I see it , there are three clear policy issues that must be discussed here:
>  
> 1.       Should new registry services be proposed in the application itself or at any stage chosen by the applicant, including at contracting and after contracting?  Why are we changing the time of evaluation of proposed new registry services when the existing application says “Additional proposed registry services that are unique to the registry must also be described.”?  Do registries prefer this be a discussion that occurs only between contracting parties and ICANN?

Actually, we identified that some registries could prefer discussing at application time, contracting time or after contracting depending on their preferred balance of predictability, time to market and innovativeness of the service. 
Note that we would be adding one intermediary option, at contracting; both application time and after contracting were options already available in the 2012-round, and would continue to be available. 

>  
> 2.       What existing services should be pre-approved for the  next round? 

Possibly the same services that would be pre-approved for all gTLD registries by then. But we could establish which services at a minimum should be there, similar to what we are doing with bundled technical evaluation and the RSP program. 


> Does it include idn registrations and RPMs with blocking?

Certainly IDN registrations, since it's the most prolific registry service request there is. 
>  
> 3.       Should applicants pay fees for evaluation of proposed new services even if  no Technical Panel is needed?  Why is this being changed from the process followed in the 2012 round?
>  

There were actually two different panels in 2012:
- Registry Services Evaluation Panel (which shouldn't be confused with Registry Services Evaluation Procedure, or RSEP), performed by an ICANN contractor
- Registry Services Technical Evaluation Panel (RSTEP), performed by technical experts from the community (https://www.icann.org/resources/pages/technical-evaluation-panel-2012-02-25-en <https://www.icann.org/resources/pages/technical-evaluation-panel-2012-02-25-en>)

All applications were evaluated by the former, and the cost of that was included in the 185,000 application fee. Besides issuing CQs or failing applications, the evaluators could have referred the application to an RSTEP, which if called upon, would have cost an extra fee, estimated by AGB at 50,000. 

Nothing is being changed about RSTEP, but instead of the evaluation panel, applicant would have the option of checking a box saying "only pre approved services" and avoiding that evaluation altogether. And if that evaluation was requested by applicant, that would be done by same ICANN Org staff that currently does RSEP for the already contracted registries. The reason for a possible fee, which I will remind again is off-topic for WT4 recommendations but we can discuss the theme, is that RSEP costs are currently carried out by the quarterly registry fee, and in this case applicants wouldn't still be paying ICANN fees, so it wouldn't be unreasonable for ICANN to charge a fee. But if WT1 prefers recommending ICANN not to charge fees in order to foster innovation, that would be fine too; both are reasoned policy decisions. 



Rubens



 

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