<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25 Jan 2018, at 19:31, Aikman-Scalese, Anne <<a href="mailto:AAikman@lrrc.com" class="">AAikman@lrrc.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt; color: rgb(31, 73, 125);" class="">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.)</span></div></div></div></blockquote><div><br class=""></div>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. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt; color: rgb(31, 73, 125);" class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt; color: rgb(31, 73, 125);" class="">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.</span></div></div></div></blockquote><div><br class=""></div>Which it always was, but history of this issue is that one limit is circularly applied to the other. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255);"><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt; color: rgb(31, 73, 125);" class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt; color: rgb(31, 73, 125);" class=""><o:p class=""> </o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 11pt; color: rgb(31, 73, 125);" class="">Hard to see how we could base a policy change on this information.</span></div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>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. </div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div>Rubens</div><div><br class=""></div><div><br class=""></div></body></html>