<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class="content-isolator__container"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><blockquote type="cite"><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">> Recommendation 26.2: ICANN must honor and review the principle of conservatism when adding new gTLDs to the root zone.<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">(No reasonable person would consider this “conservative” as it is a dramatic departure from 20+ years of IANA work patterns)</span></div></div></blockquote><div><br></div>I don’t see that conflict, Jeff. The conservatism if this context is more about the root zone per se and not how those changes are applied to the root zone. And if this delegation to NTP ends up making some strings not being delegated, because they are found to be collision risks, that would be more conservative than what was done before. </div><div><br><blockquote type="cite"><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"> <o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">> Recommendation 26.3: ICANN must focus on the rate of change for the root zone over smaller<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">> periods of time (e.g., monthly) rather than the total number of delegated strings for a given<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">> calendar year.<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">> Implementation Guidance 26.4: The number of TLDs delegated in the root zone should not<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">> increase by more than approximately 5 percent per month, with the understanding that there<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">> may be minor variations from time-to-time.<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">Any “bulk” delegations to the TRT, notwithstanding the overall doubling of RZCR (root zone change requests) – the fundamental unit of work for IANA/Verisign - would likely need to be spread-out over years to remain consistent with this guidance (which is rooted in the multiple RSSAC reports on this topic, pun intended).</span></div></div></blockquote><div><br></div>Not over years. I’ve made a spreadsheet using 3 delegation rate scenarios, starting with the current number of TLDs (1589 in 2021)</div><div>- The 1000/year which was the guidance for 2012 (using 20/week)</div><div>- The 5% over each month which is the guidance from RSSAC (using 1.2% for each week)</div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">- The 5% over each month but using half the rate to account for double delegation (0.6% for each week)</span></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0);"><br></span></font></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0);">The spreadsheet is available at </span></font>https://docs.google.com/spreadsheets/d/1N76JFTLnFhP7AC2Fv5deKazGsnOj45eK2Ib52yjP_8M/edit#gid=0 . </div><div>It shows that for the first 15/17 weeks, it does indeed delegate less than the 2012 guidance, but takes up speed as it goes. </div><div><br></div><div>Those 15/17 weeks will be enough to accommodate application evaluation which could be done in parallel, except for DNS Stability review which is a pre-requisite before TRT starts delegating strings to test environments. </div><div><br></div><div>Not that every TLD will have PCA or possible ACA done by them; it’s just that the activity that started at week 0 will be in such a pace that it won’t be a bottleneck by the time applications start being granted and contracts start being signed. </div><div><br></div><div>Also of notice is that 0.6% accounts for the full bandwidth established by RSSAC, and this wouldn’t be sensible since there won’t be any left to the steady changes already delegated TLDs have. So 0.5% per week sounds more reasonable, which changes that timing from 15 weeks to 17 weeks. </div><div><br></div><div>Implied in the 0.5%/0.6% rate is that the NTP will use the same set of servers for PCA and ACA, and that the strings won’t be removed from the root zone even after PCA/ACA ends, but only when the registry takes over the string. Or the application fails and then removed from the root zone for good. </div><div><br><blockquote type="cite"><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif;"><span style="font-size: 11pt;">Verisign and IANA are extremely protective of the root zone – correctly, of course. RZCRs span calendar weeks. Each RZCR is reviewed manually by multiple humans in both organizations. Nothing is impossible, but we can’t continue to gloss-over this important implication of our recommendations on how to implement PCA/ACA/etc.</span></div></div></blockquote><br></div><div>I’ve done a number of RZCRs for ccTLD and for 2012 gTLDs, and they were more in the business days than in calendar weeks timing. That said, it’s indeed a possible bottleneck that is unrelated to the RSSAC guidance. While I imagine some optimizations that could be applied (like having a set of root zone entries provided by TRT that would be flagged as expected for incoming gTLDs), having IANA and Verisign to give us feedback on the feasibility of this process is something I see a lot of value in. </div><div><br></div><div><br></div><div>Rubens</div><div><br></div><div><br></div></div></div></body></html>