[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 June 2019

[Rubens Kuhl]

> On 4 Jun 2019, at 18:38, Aikman-Scalese, Anne <AAikman at lrrc.com> wrote:
> 
> Jeff pointed out in response to my question on the call that the public comment on the duration of the “pre-approved” status ranged from 4 months to one year.  That is pretty hard to ignore when developing a Principle related to the duration of  RSP “pre-approval”.

Duration only applies to a time-based criteria. I don't remember any question on whether it should be time-based or not.


> 
> I think another issue might be allowing ICANN to put a stop on pre-approval applications in order to allow these to be completed before the application window opens. I realize some will say this is anti-competitive, but it almost seems as though an “RSP pre-approval window” would mean a far more orderly process in the next round.

I personally don't see a problem with this, but let's hear from those that think this triggers anti-competitive issues.


> Regarding a public list, you will have to have an agreement that accompanies the pre-approval process.  The reasons are that (1) applicants will have to be able to verify the pre-approval when making decisions on the right RSPs to contact when issuing RFPs for RSP services,  (2) an RSP who is not “pre-approved” by ICANN will need an appeal mechanism if it does not agree with ICANN’s assessment of its capabilities, and (3) the agreement established with ICANN will have to state the information required to be submitted in order to obtain the pre-approval and will have to state under what conditions ICANN can revoke the pre-approval.  Regarding publication of the pre-approved list, all you really need is the RSP’s consent to publish status when applying for pre-approval.  As a WG, we should likely be asking ICANN Org and ICANN Legal whether anyone thinks you can run a Pre-Approval program without any terms and conditions being accepted by the RSP applying for pre-approval.

I mentioned a possible public list of all RSPs; I believe it would be contradictory to have a non-public list of pre-approved RSPs.

ICANN currently has some lightweight mechanisms like MoU's with URS/UDRP providers, that I believe are more suited for RSPs than the contracts used for EBERO providers, for instance.




> 
> As to marketing, I disagree with Greg Shatan’s comment and strongly agree with Jamie Baxter’s comments on the last call.  The whole issue of allocation of ICANN staff resources to the speed and order of processing applications is still in front of us and it is a big deal.  Speed to market is very important.  RSP pre-approval is an important aspect of speed to market.   Many of the questions related to processing of applications in the next round are in fact motivated by the desire to improve speed to market for applicants.  The advantage lies with those who
> (1) have done this many times before,
> (2) get the RSP pre-approval, and

The approach to financial evaluation suggested in the initial report also allows for faster processing, but since it's different from the 2012, it won't favor those that wrote hundreds of 2012 applications. I don't see the overall SubPro approach neither favouring or disfavouring incumbent registries, it looks more like a lessons learned exercise, with "OK" parts being kept or only slightly adjusted, and deficiencies causing major replacements.



> (3) list only the “plain vanilla” services in their application.  The last element is the one we debated in Work Track 4 (and SubGroup B) because the “plain vanilla” approach to the new gTLD application does not serve the goal of innovation that is supposed to be the justification for the whole program.  (You may recall that a couple of us in Work Track 4 observed that sticking with “plain vanilla’ services applications should not result in faster processing of those applications. )

I believe that's a discussion for when we get to that section...

> 
> I still think the whole new gTLD  program falls short of being “innovative” in nature, although Kurt Pritz did an admirable job of presenting a few innovative TLDs in his presentation in Barcelona.  I sincerely hope that as the full WG moves forward, we will be able to develop policy that encourages more innovation in the space., not less.
> 

Most of possible innovation is already hindered by the aggregate of registry agreement and consensus policies (and also market structure in emerging markets). There is nothing this WG can do about that part... specifically on services, such innovation can come both from established TLDs (like the crypto coin .luxe offering) or from new TLDs, equally. The only innovations requiring new strings are those that are somewhat connected to those new services to be commercially interesting.

One disadvantage in the new gTLD program for any type of innovation is its lack of fast timing; the importance of timing in start-up success is well known in business (see https://www.inc.com/chris-dessi/this-ted-talk-explains-the-5-reasons-why-startups-succeed.html <https://www.inc.com/chris-dessi/this-ted-talk-explains-the-5-reasons-why-startups-succeed.html> for a summary and the link to a reference talk on this), but the community is clearly on the side of taking time to consider the impacts of proposed TLDs (rounds, public comment periods, objection periods etc.), and that's also an anti-innovative feature of the program that isn't going to change.





Rubens




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20190604/8541a8fa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20190604/8541a8fa/signature.asc>