[EXTERNAL]

Em 5 de jun de 2019, à(s) 10:51:000, Jamie Baxter <jamie@dotgay.com> escreveu:

 

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.    Without sounding like a broken record, and as was reiterated on the last call, the initial purpose for the RSP pre-approval program was focused on reducing cost and time (in turn also reducing redundancies). These are primarily impacts to the APPLICANT since they are the party that burdened the full cost in the 2012 round, both for the technical evaluation and operational cost delay in moving their business model forward. It's important to remember that not all APPLICANTs are also RSPs, and to really solve the right problem this discussion should remain focused on every type of APPLICANT.     I believe that any pre-approval program by design will likely benefit incumbent RSPs (or those new RSPs who seek pre-approval going into subsequent procedures), and I agree that it could also benefit APPLICANTs under the right circumstance. Reducing costs and saving time are not things I would ever object to, so being able to provide APPLICANTs with an option that avoids paying a technical evaluation fee and helps get their application idea to contract with ICANN faster could be a good thing. I am however concerned when I hear pushback about obligations that may also be necessary for RSPs. If an RSP wants the benefit of marketing themselves as a pre-approved RSP to attract new applicants, then whatever is necessary to meet that standard is the price they should pay for holding such status.   I see the pre-approval program as an opportunity to shift some of the cost & time burden from the APPLICANT to the RSP, because the pre-approval program inherently makes the RSP more marketable and desirable to APPLICANTs and helps them grow their business.    As an example, it will always cost less and get you where you are going faster in NYC to take a yellow taxi than to source a driver that you need to buy a car for. The math is simple here, yet the obligations that the yellow taxi has to the city are still real. There are regular fees and maintenance and safety requirements imposed on those yellow cabs that happen well beyond their initial approval. It makes sense and seems applicable that if the benefit of pre-approval is being offered to RSPs, then something similar could also be established. I am not the expert on what that should look like or what the cadence should be, but it should not be ignored or buried in the discussion about how to improve the APPLICANT experience in subsequent procedures.   Lastly, as I mentioned on the call, any pre-approval program must also have build in APPLICANT protections should the APPLICANT find themselves in a bind because of false advertising or any other unfortunate circumstance that may find their chosen RSP to no longer be on the pre-approval list. Those protections must focus on the two key issues - COST and TIME - ensuring that the APPLICANT is not slapped with additional costs they were not expecting mid-stream, or any delays because of the need to shift RSPs mid-stream that were necessary to avoid paying for a technical evaluation. This is important since subsequent procedures may attract a more diverse applicant pool who could see the removal of techical evalaution fees and time delays as benefits to applying.   Cheers Jamie

-------- Original Message --------
Subject: Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD
Subsequent Procedures PDP WG - 03 June 2019
From: Rubens Kuhl <rubensk@nic.br>
Date: Tue, June 04, 2019 8:00 pm
To: "Aikman-Scalese, Anne" <AAikman@lrrc.com>
Cc: "gnso-newgtld-wg@icann.org" <gnso-newgtld-wg@icann.org>

On 4 Jun 2019, at 18:38, Aikman-Scalese, Anne <AAikman@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 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

 

 

 

 

---

_______________________________________________
Gnso-newgtld-wg mailing list
Gnso-newgtld-wg@icann.org
https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

Jamie, 

Also of notice is that at least if the end result looks like the initial report, applicants wouldn't be required to select an RSP beforehand, if they commit to pick an approved RSP. That's a huge gain of bargaining power, because the RSPs will no longer be a gating factor for applying to the TLD, and when the future registry gets approved, they have a plethora of options to choose from. So I don't see the end result benefiting incumbent RSPs that much, exactly because they lose a lock-in capability at application time. This is strongly adherent to the policy objective of customer choice, even though looking on registries as customers of RSPs instead of registrants as indirect customers of registries. 

Also, not requiring an RSP to be specifically named also protects the applicant from RSPs losing pre-approval status; they don't even have to file a change request, because nothing in the application has changed. They might have to hire someone else to provide them RSP services since they though on using that RSP that is no longer an option, but that could be done with no delay. 

One other indicator that the end result is positive for applicants is that one fear mentioned for the RSP pre-approval program is the "race to bottom", a condition where price declines so much that degrades service. Not that this problem will happen; we know from experience of providing services for 10% the price other RSPs charge simple low-demanding TLDs (like Brand TLDs) that we can provide quality service for our customers even without fat margins, so there is a lot of room for competition to enable cheaper services without compromising on technical quality. 

Rubens