[Gnso-newgtld-wg] Proposed agenda - New gTLD Subsequent Procedures PDP WG - 8 August 2019 at 20:00 UTC

Wed Aug 7 16:20:02 UTC 2019

Dear group,

The ONLY reason we had to implement a “prioritization mechanism” in 2012 was the surprisingly (unsuspected) high number of applications – which wasn’t expected (which was why there was no prioritization system in place in the first place). We then had to come up with some mechanism AFTER everybody had already applied.

This time around we know about the need of prioritization already BEFORE the AG is completed.

Last time we offered applicants to NOT seek prioritization – while we offered all others to enter into a (rather complicated, time and money wasting) “lottery”.

Hence let me repeat my suggestion (which is already documented in the referenced google doc below):

*        Applicants who do not care about prioritization (e.g. brands who already know that they won’t immediately put their gTLD to use: as is the case with the majority of brand based gTLDs: they just lay bare – even 7 years after application submission) have the opportunity to indicate so already in their application! Or maybe we make non-prioritization the default – and people may rather indicate they wish speedy evaluation as they are planning to put their gTLD to use ASAP. Just a box you tick in the application: and you become part of the batch that wishes speedy evaluation. This would create two batches: Those who want to be prioritized – and those who actually do not care. Just like in 2012 when we had the lottery.

*        All those who have indicated that they see a need for speedy evaluation (and subsequent speedy contracting) could be prioritized via randomized priority numbers that are being automatically assigned by the application system once an application is being submitted. The application software would be creating a randomized 64 digit number – this excludes even the hypothetical possibility of duplicates (see as an example numbergenerator.org/random-64-digit-number-generator). These randomized numbers will be sorted by order – voila we have a randomized prioritization. WITHOUT any complicated “lotteries”.

What would make sense is an extra fee for speedy evaluation – which is what the lottery fee essentially was back in 2012.  Or rather: Maybe a reduction in application fees if you do NOT wish speedy evaluation! Say 3% application fee reduction if you do NOT wish to be prioritized. You then are in a second batch of applications – and these will be prioritized amongst themselves in the same way: random 64 digit assigned at application submission by the system. Would be good to have an incentive to be in the non-priority batch. Or a hurdle to be in the priority batch. Otherwise everybody will tick the priority box – cause what do you have to lose or gain? In 2012 those who did not need speedy evaluation simply saw no need to participate in the rather complicated lottery.

This system would STILL leave room to create further “priority-batches”; e.g. community applications, geos or whatever we come up with as worthy to be evaluated prior to all others. We can define as many priority tiers (batches) as we want – then WITHIN each batch we have the “random 64 digit number” prioritization.

It would be rather silly to force people through hoops such as the 2012 lottery. Thoughts?

In regard to the possibility to “trade prioritization” within a “group of applications” of an applicant: Many are suggesting to REDUCE the possibility to have multiple applications. Now we are discussing to create INCENTIVES for portfolio applicants? Not cool. There shouldn’t be ANY incentive created for entities who control multiple applications. In 2012 the big portfolio applicants would have strategically moved around priorities in a way that their contention sets where all among the first ones to be evaluated – as within a contention set the highest priority of one member became the priority of all contention set members. We would heavily support portfolio applicants – they would manage to get most of their strings to the front of the line by strategically cooperating with each other. Is that our intent? If so: what rationale would that be based on? 

Thanks,

Alexander

From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces at icann.org] On Behalf Of Emily Barabas
Sent: Mittwoch, 7. August 2019 17:52
To: gnso-newgtld-wg at icann.org
Subject: [Gnso-newgtld-wg] Proposed agenda - New gTLD Subsequent Procedures PDP WG - 8 August 2019 at 20:00 UTC

Dear all,

Please find below the proposed agenda for the call tomorrow, 8 August 2019 at 20:00 UTC for 90 minutes:

1. Welcome and Updates to Statements of Interest

2. Review of summary document: 

a. Application Queuing (continued), beginning on page 2 – See: https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhEcNGM/edit# <https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhEcNGM/edit>  

b. Application Change Requests (page 5) -- See: https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhEcNGM/edit# <https://docs.google.com/document/d/1nf8qGP9Y7OYuT0ZvxIgM1fZtNa4Kj8DyhzpmPhEcNGM/edit> 

3. AOB

For item 2a we will also reference this document, which provides the timing of delegation of IDNs from the 2012 round: https://docs.google.com/spreadsheets/d/1nQw13qN4qdr27ZaNbD47Vp70OzM6ESFDVEaNAvbY5uU/edit#gid=0

If you need a dial out or would like to submit an apology, please email gnso-secs at icann.org <mailto:gnso-secs at icann.org> .

Kind regards,

Emily

Emily Barabas | Policy Manager

ICANN | Internet Corporation for Assigned Names and Numbers

Email: emily.barabas at icann.org <mailto:emily.barabas at icann.org>  | Phone: +31 (0)6 84507976

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