[NCAP-Discuss] Root Zone Change Rates

[Jeff Schmidt]

[ forgot my important footnote ]

> Now in April, let’s assume that the TRT is “done” (*)

(*) 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.

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.

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.

Jeff



From: NCAP-Discuss <ncap-discuss-bounces at icann.org> on behalf of Jeff Schmidt via NCAP-Discuss <ncap-discuss at icann.org>
Date: Thursday, September 14, 2023 at 11:38 AM
To: James Galvin <galvin at elistx.com>, ncap-discuss at icann.org <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] Root Zone Change Rates
> 4. Regarding Recommendation 26.3 and Implementation Guidance 26.4, let’s
> do the math and see what we’re dealing with. The root zone currently has
> more than 1,000 TLDs in it. The stated recommendation is to ensure a rate
> of change of about 5% growth per month. Using the nice round number of
> 1,000, that’s 50 TLDs per month. ICANN Org has already offered about 400
> per year, which is 33 per month. That is well within the desired 5% and, in
> fact, as the root zone grows the steady state rate will be even further inside
> the limit. It is also pretty well aligned with the 1 TLD addition per day we are
> proposing. The essential observation here is simply that we are aligned with
> the rate of change concerns addressed by SubPro. This does not change any
> of our other observations.

We have to make some assumptions about the TRT process and model:

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.

Repeat in Feb. On 28 Feb the TRT has 90 strings with 30 days of data and 90 strings initiating coverage.

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.

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:
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.

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.

So we need to split somehow. Let’s say that in each month, we use a maximum of *half* 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.

I think Rubens is doing this sort of analysis in his spreadsheet but I’m not smart enough to have absorbed it all yet.

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.”

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230914/69ac9ff3/attachment-0001.html>