[Gnso-newgtld-wg] ICANN Org's Input on the Rate of Delegation of gTLDs

Fri Jan 26 22:55:48 UTC 2018

Thanks Rubens.  This helps.
Anne

Anne E. Aikman-Scalese

Of Counsel

520.629.4428 office

520.879.4725 fax

AAikman at lrrc.com<mailto:AAikman at lrrc.com>

_____________________________

[cid:image003.png at 01D396BE.21BAA8B0]

Lewis Roca Rothgerber Christie LLP

One South Church Avenue, Suite 2000

Tucson, Arizona 85701-1611

lrrc.com<http://lrrc.com/>

From: Rubens Kuhl [mailto:rubensk at nic.br]
Sent: Thursday, January 25, 2018 6:54 PM
To: Aikman-Scalese, Anne
Cc: Steve Chan; gnso-newgtld-wg at icann.org
Subject: Re: [Gnso-newgtld-wg] ICANN Org's Input on the Rate of Delegation of gTLDs

On 25 Jan 2018, at 19:31, Aikman-Scalese, Anne <AAikman at lrrc.com<mailto:AAikman at lrrc.com>> wrote:

As I understand it, the basic issue here is the rate of change to the root and not necessarily how many more TLDs can be added in any one year.  (Rate of change to the root could be too high if all 1,000 were added in one month or one quarter.)

Rate of change and total zone size. While ICANN Org mentioned total zone size once in their response, they ended up not answering that part of the question.

The letter seems to indicate that the controlling variable is going to be human resources/processing time for applications rather than root instability on technical grounds, while at the same time pointing out there are lots of uncontrolled variables.

Which it always was, but history of this issue is that one limit is circularly applied to the other.

Hard to see how we could base a policy change on this information.

The issue here is the difference between current GNSO Policy and current ICANN Org new gTLD implementation. GNSO Policy indeed did not prescribe anything that suggested a rate limit; even recommendation 4 "Strings must not cause any technical instability." does not talk to it, since it was about the applied-for strings, not about how they are delegated. The problem for the 2012-round started when a guess of 1,000 per year was made at how demand and application processing could progress, followed by asking if the root system could handle that 1,000 a year load. The answer that it would do ok with such a load was turned into an imaginary line of the system capacity, one that now ICANN reckons is very hard to estimate.

The change here would bring implementation back to original policy, one that indeed no one sees need for change: don't impose inexistent limits to systems, while recognising limits where they do exist.

Rubens

________________________________

This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180126/b0fda258/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 6488 bytes
Desc: image003.png
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180126/b0fda258/image003-0001.png>