[NCAP-Discuss] Root Zone Change Rates

Thu Sep 14 23:14:29 UTC 2023

Thanks Jeff - so are you saying that the TRT only makes a
"recommendation".  Does that mean every string goes to the Board with the
TRT recommendation?  (I thought you were saying the opposite in the meeting
yesterday., i.e. that some strings not deemed high risk would simply
proceed without Board review of each string's name collision risk.)

Separately, for anyone who may not know, in its meeting on September 10,
the Board adopted Sub Pro Recommendation 29.1 with the understanding that
it need not be implemented until they have the results of the NCAP work.
The link to the Board's Sub Pro "scorecard" appears below.  29.1 shows up
in Section B on page 11 of the scorecard.

scorecard-subpro-pdp-board-action-10sep23-en

Anne

Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2024
anneicanngnso at gmail.com

On Thu, Sep 14, 2023 at 3:55 PM Jeff Schmidt <jschmidt at jasadvisors.com>
wrote:

> > 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> wrote:
>
>
>
>
>
> 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
>
>
>
> _______________________________________________
> NCAP-Discuss mailing list
> 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/72619065/attachment.html>