[NCAP-Discuss] Root Zone Change Rates

Thu Sep 14 22:55:41 UTC 2023

> Does delegation without the sale of second level domains and associated
> activity at the second level equate to the delegation to the root described
> in the RRSAC report in 2018 and the Sub Pro Final Report?  (I don't think
> Sub Pro considered the type of delegation that is contemplated by the
> NCAP study group when it endorsed the Recommendations for Topic 26.)

It expressly does. These technical analysis work products were concerned with root zone transactions/growth. What is in the zone pointed-to makes no difference.

> In other words, is the "delegation load"  and risk the same as that
> considered by the RRSAC and Sub Pro?

What is in the sone pointed-to by the root makes no difference. The root doesn’t know the difference between .com and .foo running “Casey’s Thing” (tm) 😊

> Separately, do we have consensus on the following which can be
> captured at the workshop?

We do have consensus on the first point, which included an “IANA” proviso.

We do not yet have consensus on the second point, which I would reframe as “the role of the TRT is to make a “delegate” or “do not delegate” recommendation per string.”

Jeff

From: Anne ICANN <anneicanngnso at gmail.com>
Date: Thursday, September 14, 2023 at 5:07 PM
To: Rubens Kuhl <rubensk at nic.br>
Cc: Jeff Schmidt <jschmidt at jasadvisors.com>, ncap-discuss at icann.org <ncap-discuss at icann.org>
Subject: Re: [NCAP-Discuss] Root Zone Change Rates
Question for the technical experts:  Does delegation without the sale of second level domains and associated activity at the second level equate to the delegation to the root described in the RRSAC report in 2018 and the Sub Pro Final Report?  (I don't think Sub Pro considered the type of delegation that is contemplated by the NCAP study group when it endorsed the Recommendations for Topic 26.)

In other words, is the "delegation load"  and risk the same as that considered by the RRSAC and Sub Pro?

Separately, do we have consensus on the following which can be captured at the workshop?

(1)  Phase 1 risk analysis in the first 14-15 days as described by Casey and propsed by Jeff S in our meeting two weeks ago? TRT to determine next steps based on that initial analysis?    Is application layer relevant for the next step?

(2)  the role of the TRT at some point in the risk assessment process to make determinations as to strings that are not "high risk" and let those applications proceed, while identifying high risk strings and advising applicants of this determination?  Then applicants would have the option to withdraw or submit a mitigation plan for analysis by the TRT?  The mitigation plan to be submitted to the Board for decision along with TRT analysis for high risk strings?

thank you,
Anne

On Thu, Sep 14, 2023 at 7:44 AM Rubens Kuhl via NCAP-Discuss <ncap-discuss at icann.org<mailto:ncap-discuss at icann.org>> wrote:

Em 14 de set. de 2023, à(s) 10:12, Jeff Schmidt <jschmidt at jasadvisors.com<mailto: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

_______________________________________________
NCAP-Discuss mailing list
NCAP-Discuss at icann.org<mailto:NCAP-Discuss at icann.org>
https://mm.icann.org/mailman/listinfo/ncap-discuss

_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230914/dd827d88/attachment-0001.html>