[NCAP-Discuss] Root Zone Change Rates

[Rubens Kuhl]

> Em 14 de set. de 2023, à(s) 10:12, Jeff Schmidt <jschmidt at jasadvisors.com> escreveu:
> 
> Thanks! My intention is to have this discussion, so thanks for engaging. Like I said, nothing is impossible, but if we don’t address this (large) implication of our recommendations, I don’t think we have done our work.
> 
> I’m not sure I understand your sheet. Let me simplify:
> 
> Current root size: 1589
> 5%: 80
> So we can add 80 TLDs to the root m/m. Plus or minus. I didn’t address “compounding” but you get the gist.

I normalized to a per week %, which is why there is 1.2% (not 1.25% due to compounding).
I also only listed the total number of TLDs at that point considering the rate described, so the difference between week 0 and week 1 are 20 TLDs for 2012 guidance, 19 for 5% m/m, 8 to account for double delegation and some room for ordinary changes to the root zone.

That ramps up over the years; it reaches 35 a week after 1 year. I added per week columns to all scenarios to ease up the comparison.
> 
> 1. That’s a lot. We need to check with IANA-Verisign and at least give them a courtesy heads-up and get their thoughts.

Which is I what mentioned… these figures are only looking at the 5% a month root zone change rate.

> 2. That’s not a lot. If we have 1200 unique strings to research (same as 2012), that will take 15 months just to delegate to the TRT.

It will reach 1200 in week 48, so it would be 11 months. But considering the 400/batch ICANN Org mentioned in the ODP, that takes 23 weeks, or 6 months.

> 3. This doesn’t address “normal” work to include routine RZCR which IANA-Verisign would still need to complete. That’s additional work on top of all of this.

Which is why I used 0.5% instead of 0.6%. This assumes delegation of new TLDs (either to NTP or to registry) takes up 80% of available capacity keeping 20% pre-reserved for routine changes.

It’s also to be expected that if routine changes require more root zone change, new TLDs are the ones who get throttled.

> 4. This doesn’t address the RZCRs that would re-delegate away from the TRT to the new Registry along the way. That’s additional work on top of all of this.

This is why is not 1.2% every week, to account for the additional move. But I am being too conservative to  slow to 0.5% from the very beginning, when this would only be required by the time strings transition to delegation.



Rubens

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230914/eefa12d6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230914/eefa12d6/signature-0001.asc>