<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">[ forgot my important footnote ]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> Now in April, let’s assume that the TRT is “done” (*)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">(*) All this assumes pipelining the TRT analysis, which seems possible, but we’ve never explicitly addressed it to my recollection. The TRT will work in batches of < 100 and will never have “all” of the strings
and data together at one time for analysis.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">That doesn’t seem like a problem, but it’s a departure from 2012 and may have unintended consequences. Interisle and JAS both had the complete datasets prior to making our recommendations.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">If we don’t want to pipeline the TRT work, or we want to give the TRT the option to have all the data before making any decisions (I could see vendors asking this), then it blows-up the whole timeline.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Jeff<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">NCAP-Discuss <ncap-discuss-bounces@icann.org> on behalf of Jeff Schmidt via NCAP-Discuss <ncap-discuss@icann.org><br>
<b>Date: </b>Thursday, September 14, 2023 at 11:38 AM<br>
<b>To: </b>James Galvin <galvin@elistx.com>, ncap-discuss@icann.org <ncap-discuss@icann.org><br>
<b>Subject: </b>Re: [NCAP-Discuss] Root Zone Change Rates<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">> 4. Regarding Recommendation 26.3 and Implementation Guidance 26.4, let’s
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> do the math and see what we’re dealing with. The root zone currently has
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> more than 1,000 TLDs in it. The stated recommendation is to ensure a rate</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> of change of about 5% growth per month. Using the nice round number of
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> 1,000, that’s 50 TLDs per month. ICANN Org has already offered about 400</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> per year, which is 33 per month. That is well within the desired 5% and, in
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> fact, as the root zone grows the steady state rate will be even further inside</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> the limit. It is also pretty well aligned with the 1 TLD addition per day we are
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> proposing. The essential observation here is simply that we are aligned with
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> the rate of change concerns addressed by SubPro. This does not change any
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> of our other observations.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">We have to make some assumptions about the TRT process and model:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Let’s say in January we delegate (5%*1800) = 90 candidate strings to the TRT. That’s our maximum capacity. Assume that gets peanut-buttered over the month somehow, so by Jan 31 the TRT has 90 strings to start
collecting data on. Cool.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Repeat in Feb. On 28 Feb the TRT has 90 strings with 30 days of data and 90 strings initiating coverage.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Repeat in March. On 31 March, the TRT has 90 strings with 60 days of data, 90 strings with 30 days of data, and 90 initiating coverage.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Now in April, let’s assume that the TRT is “done” (*) with the January lot of 90. They declare them ok to delegate. So April would look like this:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">We have 90 available work slots. All 90 would be used to re-delegate the now completed January strings to their Registries. We have no available slots to delegate new research strings to the TRT.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">You see the problem. If we use all the available slots in April, May, and June to delegate the January, February, and March lots to their Registries, we’re stuck in July.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">So we need to split somehow. Let’s say that in each month, we use a maximum of *<b>half</b>* of the available 90 slots for final delegation. That means in each month starting in April we are delegating 45
to the TRT for research and 45 to the final Registry. That seems plausible. Would lead to a steady-state final delegation rate of (12*45)=540 per year. It would take (1000/45)=22 months to delegate all the strings to the TRT, assuming ~1000 ala 2012.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I think Rubens is doing this sort of analysis in his spreadsheet but I’m not smart enough to have absorbed it all yet.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">But, I reiterate, nothing about this is “conservative.” We’re talking about pegging IANA-Verisign at maximum rate of change 5% (90 RZCS/mo) every month for more than a year, maybe two. That’s like running
your car engine at redline RPM for a year – sure it’s technically within spec, but certainly not “conservative.”</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Jeff</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>