<div dir="ltr"><div dir="ltr">Casey,<div><br></div><div>Thanks for this explanation. </div><div><br></div><div>Out of curiosity, regarding this comment: "Also, the last time something like this was done at similar scale (Site Finder), the public outcry was huge."</div><div><br></div><div>How would you characterize the relative scale of Site Finder in 2003 compared to the relative scale of name collision analysis for the next round of new gTLDs in ~2025?</div><div><br></div><div>thanks,</div><div><br></div><div>tom<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 5, 2022 at 12:54 PM Casey Deccio <<a href="mailto:casey@deccio.net">casey@deccio.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I mentioned in last Wednesday's call that I wanted to make some clarifications with regard to some of the back-and-forth discussions that were had on the mailing list in recent weeks. The discussions got complicated because they lost context over time. This message is intended to restore some context and address three points in particular. Please note that they are not about endorsing a particular solution but to address concerns about the proposed solutions.<br>
<br>
<br>
1. The criticality of IPv6 support in manifesting name collisions.<br>
<br>
First, let me be clear on the following: 1) I am on board with promoting and helping with increased adoption of IPv6; and 2) I am a researcher in the area of Internet measurement, and as such, for me, more data is better.<br>
<br>
That being said, an IPv4-only name collision alerting system is effective for all systems and applications that include *any sort* of IPv4 connectivity. It is only deficient for systems that *lack IPv4 support*. In other words, it is independent of general IPv6 growth, promotion, or support, until systems and applications drop IPv4 functionality.<br>
<br>
Finally, in saying this, I am neither promoting controlled interruption nor saying that we should not desire IPv6 support. I am merely stating that in terms of today's Internet (and frankly for the foreseeable future), IPv6 support is not essential to manifesting name collisions, and it certainly does not make IPv6-supporting solutions "vastly superior" by that characteristic alone. That is simply a mischaracterization.<br>
<br>
For more, please see the sub-section "Application Coverage" under "Alerting Effectiveness and Coverage" in the comparison document.<br>
<br>
<br>
2. The comparison of risk and disruptiveness between active collision assessment and controlled interruption.<br>
<br>
It was stated that "active collision assessment and controlled interruption are equivalently risky and equivalently disruptive."<br>
<br>
"Equivalently disruptive." Both active collision assessment and controlled interruption involve 1) DNS servers returning an answer to a requesting client, where a negative response was the expected response; and 2) the application acting on that answer (i.e., with transport-layer communications), where it previously would not have. Thus, in both cases, communications are interrupted.<br>
<br>
The interruptions, however, are not equivalent. Controlled interruption is expected to always return a "quick-response" error, while the error behavior for active collision assessment varies, depending on several factors, including network configuration, server configuration, and more.<br>
<br>
"Equivalently risky." As I have mentioned before, "risk" is a term that is both highly loaded and highly ambiguous. Nonetheless, the very fact that transport-layer communications leave the client with active collision assessment is a significant leap from transport-layer communications never leaving the host systems, as it is with controlled interruption.<br>
<br>
More importantly, active controlled interruption involves intercepting communications for proposed ports/applications and returning custom content (ports and applications that are not even enumerated at this point). Perhaps the two biggest concerns are that 1) application-layer data *will be* communicated; and 2) the user experience *will be* fraught with issues, including (but not limited to) TLS certificate warnings. Also, the last time something like this was done at similar scale (Site Finder), the public outcry was huge.<br>
<br>
For more, please see the sections entitled "Operational Continuity, Security, and Privacy", "User Experience", and "Public Response" in the comparison document.<br>
<br>
<br>
3. The evaluation of controlled interruption in meeting its goals.<br>
<br>
It has been stated that "controlled interruption did not achieve its desired objective." This is based on the finding from the root cause analysis that "[c]ontrolled interruption is effective at disruption, but not at root cause identification." The problem is that it focuses only on the second half of the sentence and ignores the first half that indicates that it was "effective at disruption." Disruption was part of the goal related to alerting. But more important than that was *change*. Note that another finding from the root cause analysis is the following: "Usage of private DNS suffixes colliding with newly delegated TLDs has decreased over time." Measurements show that potential collisions have consistently decreased since 2014. To me, this is the more important part--the fact that changes in the ecosystem were observed related to queries associated with name collisions. Even though we have some qualitative data that help us anecdotally understand problem resolution, we c<br>
annot definitively point to controlled interruption as the cause for the decrease in queries. Nevertheless, the trend suggests that there was a clear decrease in queries associated with name collisions, which is a "good thing".<br>
<br>
For more, please see "Findings" section in the root cause analysis doc.<br>
<br>
<br>
Cheers,<br>
Casey<br>
_______________________________________________<br>
NCAP-Discuss mailing list<br>
<a href="mailto:NCAP-Discuss@icann.org" target="_blank">NCAP-Discuss@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/ncap-discuss" rel="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" 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" 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.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font face="arial, helvetica, sans-serif" size="2">Thomas Barrett</font><div><font face="arial, helvetica, sans-serif" size="2">President</font></div><div><font face="arial, helvetica, sans-serif" size="2">EnCirca, Inc</font></div><div><font face="arial, helvetica, sans-serif" size="2">+1.781.942.9975 (office)</font></div><div><font face="arial, helvetica, sans-serif" size="2">400 W. Cummings Park, Suite 1725<br></font></div><div><font face="arial, helvetica, sans-serif" size="2">Woburn, MA 01801 USA</font></div></div></div></div></div>