[Gnso-newgtld-wg] Final Compromise Proposal for the Prioritization of IDN applications

Tue Apr 21 18:32:45 UTC 2020

Ok, let me try to tackle this one point at a time:

  1.  Yes, we are proposing an application draw process like that used in 2012.  It was convoluted, yes, but it was done to comply with the lottery laws in California where ICANN is located.  If we continue to agree that the processing of applications (subject to the IDN priority proposal) should be randomized, then my STRONG recommendation is that we as a group do not try and mess with something we know both works and is legal.  We may hot have loved it, but again it was legal.

  1.  If you recall our discussions and look at the section, there is also a recommendation to be more efficient with the process by recommending that one should be able to elect its participation in the draw and submit its fee (if there is one) at the time of application rather than having to show up in California with cash in hand (Assuming that this new efficiency change complies with the law -  which it may not).

  1.  One who participated in the random draw is not making an assertion that they need to launch quickly.  They just want to be delegated the TLD sooner rather than later.  Imposing a use requirement simply because they choose to be in the lottery is not consistent with the working group's discussions to date.

Jeff Neuman
Senior Vice President
Com Laude | Valideus
D: +1.703.635.7514
E: jeff.neuman at comlaude.com<mailto:jeff.neuman at comlaude.com>

From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces at icann.org> On Behalf Of Alexander Schubert
Sent: Tuesday, April 21, 2020 12:39 PM
To: gnso-newgtld-wg at icann.org
Subject: Re: [Gnso-newgtld-wg] Final Compromise Proposal for the Prioritization of IDN applications

Hi All,

I notice we are talking about an "application draw".
I assume we won't create a convoluted, complicated, time-consuming and costly "lottery" again; instead facilitate the prioritization within the batches via "random numbers":
There are providers who provide "real random" numbers (not computer generated: generated by physical devices but transmitted via Internet) of e.g. 128 digits - the application system can attach such number to each application at its inception. Once the application window closes, one last random number will be generated: All application assigned random numbers would be multiplied with that last random number to ensure a final randomization (think: Shuffling of cards). The resulting system-generated "prioritization number" would then serve as priority designator within each of the batches (applicants who request speedy evaluation and those who don't, etc.).

So no "draw" but rather some system internal randomization, right? Or is somebody insisting on a 2012-style lottery? The only reason we had a lottery was, that we did not foresee the need for prioritization before the application window opened. At least that is my understanding. Whether or whether not a speedy evaluation is requested could be part of the application - and applicants should be allowed to "untick" that box at any time before their evaluation started (but not the other way around: if not elected before application submission then it can't be requested afterwards).

Is that "implementation" - or would that be part of the AG?

Regarding electing "priority":
Any application that elects priority (IDN or non-IDN) obviously indicates, that it needs speedy processing. The ONLY reason for which we should grant such need is the intention to start up the registry real fast. If an applicant who elects priority in the evaluation proposes a Sunrise Phase in their application: then such Sunrise would have to be executed in timely manner; or else the contract would be terminated (the same way a contact will be terminated for not engaging in testing). If an applicant can't commit to the execution of their Sunrise in a timely manner: please do not elect evaluation priority. Is that reflected somewhere in our language? I don't see it. IDN's aren't a protected species just because there are IDN's. We want to aid those who have plans to go online fast. No plans = no priority. Again: if a registry has no Sunrise Period; then they would not be impacted by the rule anyways.

Thanks,

Alexander

From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces at icann.org] On Behalf Of Jeff Neuman
Sent: Tuesday, April 21, 2020 5:47 PM
To: gnso-newgtld-wg at icann.org<mailto:gnso-newgtld-wg at icann.org>
Subject: [Gnso-newgtld-wg] Final Compromise Proposal for the Prioritization of IDN applications

All,

Thank you all for your thoughtful comments on the previous proposals for the processing of applications.  I have assembled the comments and offer this as proposed text for the draft final report.   I first lay out what the existing section states followed by the proposed new language:

EXISTING LANGUAGE

No Agreement: The Working Group notes that in the 2012 round a decision was made by ICANN Org to prioritize applications for IDN strings. Although there was a 30-day public comment period, the decision to prioritize IDN strings was never subject to policy review. Although the Working Group received a number of comments on this issue (both in support and against), the Working Group was not able to come to agreement as to whether IDN applications should receive any priority in subsequent rounds.

PROPOSED NEW LANGUAGE

Affirmation with modification (Rationale xx):  If the volume of applications received significantly exceeds 500, applications will be processed in batches of 500.*
*In the 2012 round, the Section 1.1.2.5 of the Applicant Guidebook provided that the first batch would consist of 500 applications, but each subsequent batch was to be only 400 applications.  For ease, the Working Group has modified this to an even 500 applications per batch.  (See Applicant Guidebook, page I-9).

Recommendation (Rationale xx):  The Working Group notes that in the 2012 round a decision was made by ICANN Org to prioritize applications for IDN strings. Although there was a 30-day public comment period, the decision to prioritize IDN strings was never subject to policy review.  For Subsequent rounds, the Working Group recommends that the following formula must be used with respect to giving priority to Internationalized Domain Name applications:

  1.  First Batch of 500
     *   If there are more than 125 applications for IDN strings that elect to participate in the prioritization draw, the first 25% of applications processed in the first batch shall be those applications for IDN strings that elect to participate in the prioritization draw.  The remaining 75% of applications in the first batch shall consist of both IDN and non-IDN applications that elect to participate in the prioritization draw.
     *   If there are less than 125 applications for IDN strings that elect to participate in the prioritization draw, then all such applications shall be processed in the first batch prior to any non-IDN application.

  1.  Each Subsequent Batch of those electing to participate in the Prioritization Draw
     *   For each subsequent batch. the first 10% of each batch of applications must consist of IDN applications until there are no more IDN applications.
     *   The remaining applications in each batch shall be selected at random out of the pool of IDN and non-IDN applications that remain.

  1.  Processing of Applications which do not elect to participate in the Prioritization Draw
     *   When all of the applications that have elected to participate in the Prioritization Draw have been processed, ICANN shall process the remaining applications is batches of 500 applications.
     *   The first 10% of each batch of applications must consist of IDN applications until there are no more IDN applications.
     *   The remaining applications in each batch shall be selected at random out of the pool of IDN and non-IDN applications that remain.

 Example:  Assume ICANN receives 3,000 applications. There are 1,200 applications for IDN strings and 1,800 applications for non-IDN strings.  1,000 of the IDN strings and 1,000 of the non-IDN strings elect to participate in the prioritization draw.  The remaining 200 IDN string and 800 non-IDN strings have declined to participate in the Prioritization Draw.  ICANN shall place the applications in 6 batches of 500 applications in the following manner:

Batch 1:
125 of the 1,000 IDN applications (selected during the prioritization draw) shall be processed first.  The remaining 750 IDN-applications shall be combined with the 1,000 non-IDN applications. Of those 1,750 applications, 375 of them shall be selected at random to be processed in the first batch.

Batch 2:
Assume there are 700 IDN applications and 800 non-IDN applications remaining that have elected to participate in the prioritization draw.  In the second batch, the first 50 applications processed shall be for IDN strings selected at random.  The remaining 450 applications processed in the second batch shall be selected at random from the pool of both the 800 non-IDN applications and the remaining 650 IDN applications.

Batch 3:
Assume that there are now 400 IDN applications and 600 non-IDN applications that have elected to participate in the prioritization draw.  In the third batch, the first 50 applications processed shall be for IDN strings selected at random.  The remaining 450 applications processed in the second batch shall be selected at random from the pool of both the 600 non-IDN applications and the remaining 400 IDN applications.

Batch 4
Assume there are now only 25 IDN applications and 475 non-IDN applications for the last batch that has elected to participate in the prioritization draw. In this case only 5% of the last batch is comprised of IDN applications.  Therefore all of the remaining IDN applications will be processed in the last batch prior to the remaining 475 non-IDN strings.

Batch 5:
There are now 200 IDN strings and 800 non-IDN strings that have elected not to participate in the prioritization draw. The first 50 applications process in Batch 5 shall be IDN strings.  The remaining 450 applications process shall be selected at random from the pool of both the 800 non-IDN applications and the remaining 150 IDN applications.

Batch 6:
Assume of the remaining 500 applications, 30 of them are for IDN strings and 470 of them are for non-IDN strings.  In this case only 7.5% of the last batch is comprised of IDN applications.  Therefore all of the remaining IDN applications will be processed in the last batch prior to the remaining 470 non-IDN strings.

Jeff Neuman
Senior Vice President

Com Laude | Valideus
1751 Pinnacle Drive
Suite 600, McLean
VA 22102, USA

M: +1.202.549.5079
D: +1.703.635.7514
E: jeff.neuman at comlaude.com<mailto:jeff.neuman at comlaude.com>
www.comlaude.com<http://www.comlaude.com/>

[cid:image001.jpg at 01D617E9.B5AB4E90]

________________________________
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>
________________________________
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200421/b93629fc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2700 bytes
Desc: image001.jpg
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200421/b93629fc/image001-0001.jpg>