<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">From:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><a href="https://mm.icann.org/pipermail/ncap-discuss/2022-November/000971.html">https://mm.icann.org/pipermail/ncap-discuss/2022-November/000971.html</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt">(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.
<o:p></o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt"><o:p> </o:p></span></i></p>
<p class="MsoNormal"><i><span style="font-size:11.0pt">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.<o:p></o:p></span></i></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">We (NCAP) currently say this:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> 5.5 Recommendation 5 - ICANN must support the delegation of strings in order to improve the ability to conduct a name collision risk assessment<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Noting this is a “must” and we are silent on the IANA/Verisign/RZM implications.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">This would also put us in direct conflict with SubPro “must” recommendations:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> Recommendation 26.2: ICANN must honor and review the principle of conservatism when adding new gTLDs to the root zone.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">(No reasonable person would consider this “conservative” as it is a dramatic departure from 20+ years of IANA work patterns)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> Recommendation 26.3: ICANN must focus on the rate of change for the root zone over smaller
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> periods of time (e.g., monthly) rather than the total number of delegated strings for a given<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> calendar year.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> Implementation Guidance 26.4: The number of TLDs delegated in the root zone should not<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> increase by more than approximately 5 percent per month, with the understanding that there<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">> may be minor variations from time-to-time.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Jeff<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</body>
</html>