[NCAP-Discuss] Root Zone Change Rates

[Jeff Schmidt]

Sorry team – here is a new NCAP thread re-presenting and re-discussing the double-delegation and related workflow issue I brought-up today. Good fodder for the DC workshops.

I wrote about this more completely in Nov 2022, and discussion of this issue appears in the JAS reports. As I mentioned, one reason we implemented 2012 CI the way we did was specifically to avoid double delegations.

From:
https://mm.icann.org/pipermail/ncap-discuss/2022-November/000971.html

(1) Delegating each string to the TRT (presumably a contractor or ICANN itself) *doubles* the number of delegations/root change activities as compared to the previous round. In 2012, .foo was delegated once - to the new .foo registry. This was deliberate to reduce risk and root zone changes. We considered an intermediate delegation (CI being handled by a third party) but intentionally chose against this approach to reduce (re-)delegations. In the currently envisioned process, .foo would be delegated once to the TRT then again to the new .foo registry.

The IANA-Verisign root management process is a low volume process and most requests span calendar weeks. IANA-Verisign processes to do what is envisioned here somehow in "bulk" don't currently exist, so we'd be asking IANA-Verisign to create new processes. Recall from the 2012 round the various "root scaling" research pieces (including one from SSAC and one from RSAC) stated that the "size" of the root zone was less of a concern than the rate of change. The currently envisioned process would *double* the number of root changes. Root zone changes are not zero cost and not zero risk. We better have a darn good reason to *double* the number of changes.

We (NCAP) currently say this:

> 5.5 Recommendation 5 - ICANN must support the delegation of strings in order to improve the ability to conduct a name collision risk assessment

Noting this is a “must” and we are silent on the IANA/Verisign/RZM implications.

This would also put us in direct conflict with SubPro “must” recommendations:

> Recommendation 26.2: ICANN must honor and review the principle of conservatism when adding new gTLDs to the root zone.

(No reasonable person would consider this “conservative” as it is a dramatic departure from 20+ years of IANA work patterns)

> Recommendation 26.3: ICANN must focus on the rate of change for the root zone over smaller
> periods of time (e.g., monthly) rather than the total number of delegated strings for a given
> calendar year.

> Implementation Guidance 26.4: The number of TLDs delegated in the root zone should not
> increase by more than approximately 5 percent per month, with the understanding that there
> may be minor variations from time-to-time.

Any “bulk” delegations to the TRT, notwithstanding the overall doubling of RZCR (root zone change requests) – the fundamental unit of work for IANA/Verisign - would likely need to be spread-out over years to remain consistent with this guidance (which is rooted in the multiple RSSAC reports on this topic, pun intended).

Verisign and IANA are extremely protective of the root zone – correctly, of course. RZCRs span calendar weeks. Each RZCR is reviewed manually by multiple humans in both organizations. Nothing is impossible, but we can’t continue to gloss-over this important implication of our recommendations on how to implement PCA/ACA/etc.

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230913/e4822751/attachment.html>