<div dir="auto">Ditto. What Anne Said.<div dir="auto"><br></div><div dir="auto">Tom</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 14, 2022, 2:57 PM Aikman-Scalese, Anne <<a href="mailto:AAikman@lewisroca.com">AAikman@lewisroca.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="m_-5382405097037016563WordSection1">
<p class="m_-5382405097037016563MsoPlainText">Rubens,<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">The written system for a Name Collision Assessment Framework is supposed to be in place for all future rounds and as you know, future rounds are supposed to be ongoing based on the policy adopted in the Sub Pro Final Report. It's not
at all about IPv6 TODAY.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText">I’ll add that anyone who wants to see .MAIL move forward (as you have advocated many times) won't be happy with a fallback to the 2012 Framework which bans it. In addition, I don't know how many times I have to say this, but we need
a Framework that assesses risk at the point of application and that was not in place in 2012. Implementation Guidance from Sub Pro says we also need for the risk assessment to occur in the “evaluation process” as well as “during the transition to delegation”.
So there are two phases of risk assessment described there. To my non-technical mind, this comports with PCA and ACA. I leave the assessment of the efficacy of those risk assessment systems to the technical folks and the SSAC. Casey’s report does a lot
to clarify that certain risks of a new system are “unknown”. I will point out, however, that I agree with Heather that no aspect of “Public Reception” is technical in nature. That category does not belong in Casey’s chart.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText">All these offhand references on the list to "non-technical" people and what we "need to understand" are obscuring the need for clarity.
<b>We need a written Name Collision Assessment Framework in place that can be adopted by the Board.</b> And the Community At Large and the GAC need to be able to understand it along with all the rest of us non-technical people. Will you and Jeff please get
your proposed language and charts in place rather than just taking "pot shots" at the current draft? Please be sure to include your proposals for the “DNS Stability Evaluation” and the “name collision risk criteria and a test” as set forth in the Sub Pro
Implementation Guidance.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:15.0pt;font-family:"Arial",sans-serif">Recommendation 29.1: ICANN
<b>must</b> have ready prior to the opening of the Application</span><br>
<span style="font-size:15.0pt;font-family:"Arial",sans-serif">Submission Period <b>
a mechanism to evaluate the risk of name collisions</b> in the New gTLD</span><br>
<span style="font-size:15.0pt;font-family:"Arial",sans-serif">evaluation process as well as during the transition to delegation phase</span><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b><u></u> <u></u></b></p>
<p class="MsoNormal"><b><span style="font-size:15.0pt;font-family:"Arial",sans-serif">Implementation Guidance 29.4</span></b><span style="font-size:15.0pt;font-family:"Arial",sans-serif">: To the extent possible, all applied-for strings</span><br>
<span style="font-size:15.0pt;font-family:"Arial",sans-serif">should be subject to a
<b>DNS Stability evaluation</b> to determine whether they</span><br>
<span style="font-size:15.0pt;font-family:"Arial",sans-serif">represent a name collision risk.
<u></u><u></u></span></p>
<p class="MsoNormal"><br>
<b><span style="font-size:15.0pt;font-family:"Arial",sans-serif">Implementation Guidance 29.5</span></b><span style="font-size:15.0pt;font-family:"Arial",sans-serif">:
<b>The ICANN community</b> should develop name</span><br>
<b><span style="font-size:15.0pt;font-family:"Arial",sans-serif">collision risk criteria and a test
</span></b><span style="font-size:15.0pt;font-family:"Arial",sans-serif">to provide information to an applicant for any</span><br>
<span style="font-size:15.0pt;font-family:"Arial",sans-serif">given string after the application window closes so that the applicant can</span><br>
<span style="font-size:15.0pt;font-family:"Arial",sans-serif">determine if they should move forward with evaluation.<u></u><u></u></span></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText">Thank you,<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">Anne<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText">Anne E. Aikman-Scalese<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">Of Counsel<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><a href="mailto:AAikman@lewisroca.com" target="_blank" rel="noreferrer">AAikman@lewisroca.com</a><u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">D. 520.629.4428<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">Lewis Roca Rothgerber Christie LLP<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">One South Church Avenue, Suite 2000<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">Tucson, Arizona 85701-1611<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><a href="http://lewisroca.com" target="_blank" rel="noreferrer">lewisroca.com</a><u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">-----Original Message-----<br>
From: NCAP-Discuss <<a href="mailto:ncap-discuss-bounces@icann.org" target="_blank" rel="noreferrer">ncap-discuss-bounces@icann.org</a>> On Behalf Of Rubens Kuhl via NCAP-Discuss<br>
Sent: Monday, November 14, 2022 12:19 PM<br>
To: James Galvin <<a href="mailto:galvin@elistx.com" target="_blank" rel="noreferrer">galvin@elistx.com</a>><br>
Cc: NCAP Discussion Group <<a href="mailto:ncap-discuss@icann.org" target="_blank" rel="noreferrer">ncap-discuss@icann.org</a>><br>
Subject: Re: [NCAP-Discuss] Current Status of the NCAP Project<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText">Jim.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText">It doesn't matter if the share of IPv6-preferred hosts grow and even reach near 100%. The issue, or lack thereof, is with IPv6-only hosts. This ratio is abysmally low which is why adding IPv6 brings zero benefit.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText">You may not remember, but the organization I work for is also an address resource registry (an NIR). We keep track of the development in IPv6 deployment both number-wise and device-wise, and try fostering the growth of IPv6 whenever
we can. But we are both not seeing IPv6-only hosts and not advocating for IPv6-only hosts. They could exist in the distant future, and I hope my kids will live long enough to see them, possibly at the end of this century.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText">Rubens<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> On 14 Nov 2022, at 15:48, James Galvin <<a href="mailto:galvin@elistx.com" target="_blank" rel="noreferrer"><span style="color:windowtext;text-decoration:none">galvin@elistx.com</span></a>> wrote:<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> I agree with your observation that controlled interruption fails for IPv6-only hosts. I’m not yet ready to concede that dual-stacked or XLAT networks are not similarly impacted as we haven’t looked at that scenario.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> As far as adding IPv6 support to collision assessment being a zero-sum game, I disagree with that. As I noted below, IPv6 usage may be small and increasing at a very low rate however, as a technical point, this does not justify dismissing
collision assessments on an IPv6 network.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> At a minimum, the DG was tasked to consider how to assess collisions in the future. Since IPv6 is present today and is increasing, however slowly, I think the DG would be remiss if it did not consider whether or not there was a solution
for when IPv6 was in use. Since we have found a solution the DG would be negligent if it did not call it out, on its technical merits.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> Jim<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> On 13 Nov 2022, at 19:20, <a href="mailto:rubensk@nic.br" target="_blank" rel="noreferrer">
<span style="color:windowtext;text-decoration:none">rubensk@nic.br</span></a> wrote:<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>> On 12 Nov 2022, at 22:53, James Galvin <<a href="mailto:galvin@elistx.com" target="_blank" rel="noreferrer"><span style="color:windowtext;text-decoration:none">galvin@elistx.com</span></a>> wrote:<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>> A few comments inline.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>> On 11 Nov 2022, at 10:52, Casey Deccio wrote:<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>>>> \On Nov 10, 2022, at 4:34 AM, James Galvin <<a href="mailto:galvin@elistx.com" target="_blank" rel="noreferrer"><span style="color:windowtext;text-decoration:none">galvin@elistx.com</span></a>> wrote:<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>>>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>>>> I consider the following things better.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>>>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>>>> 1. Frankly, [lack of IPv6 support] was a serious technical gap in the 2012 Controlled Interruption<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>>> It is a fact that controlled interruption does not support IPv6. While I do agree that IPv6 support is *desirable*, I am interested to know why you feel that this is a "serious technical gap". And to be clear, I'm not talking
about the general advancement of IPv6; I'm talking about the goals of controlled interruption. I have taken time to write categories for technical consideration in the comparison doc, among which are the goals for alerting and data collection. Also in that
doc are descriptions of how controlled interruption and the other proposed techniques measure up.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>> A goal of controlled interruption is to work on today’s Internet. Today’s Internet includes IPv6. Failing to cover IPv6 increases the risk that controlled interruption will not achieve the goal of manifesting name collisions.
And while the traffic volume of IPv6 may be increasing ever so slowly, whatever that rate is becomes the same rate at which the risk of controlled interruption failing to achieve its goal will also increase.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>>> Thus, on this one key point, both PCA and ACA are vastly superior to controlled interruption.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>> Today's Internet is composed of IPv4-only hosts and IPv4 and IPv6 capable hosts (either thru dual-stacked networks or IPv6 + 464 XLAT networks). Controlled interruption only fails in IPv6-only hosts, for which there are almost none
whatsoever. So this alleged improvement is 0 at this point and in the foreseeable future.<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>> <u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText">>> Rubens<u></u><u></u></p>
<p class="m_-5382405097037016563MsoPlainText"><u></u> <u></u></p>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message
or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying
to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
<br>
</font>
</div>
_______________________________________________<br>
NCAP-Discuss mailing list<br>
<a href="mailto:NCAP-Discuss@icann.org" target="_blank" rel="noreferrer">NCAP-Discuss@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/ncap-discuss" rel="noreferrer noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/ncap-discuss</a><br>
<br>
_______________________________________________<br>
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 (<a href="https://www.icann.org/privacy/policy" rel="noreferrer noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). 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.</blockquote></div>