<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 9, 2022, at 10:24 AM, Matt Larson <<a href="mailto:matt.larson@icann.org" class="">matt.larson@icann.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Nov 9, 2022, at 10:09 AM, Jeff Schmidt via NCAP-Discuss <<a href="mailto:ncap-discuss@icann.org" class="">ncap-discuss@icann.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif; caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="font-size: 11pt;" class="">Hia – I was referring to the technical conversation on the dns-operations list circa this past spring where both standards compliant and non-standards-compliant technical approaches were being debated. There are plusses
and minuses. The NCAP document and Casey’s document don’t contain sufficient detail to determine the exact implementation variety currently being promoted (or if they do I missed it).<o:p class=""></o:p></span></div>
<div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif; caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0in; font-size: 10pt; font-family: Calibri, sans-serif; caret-color: rgb(0, 0, 0); font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">
<span style="font-size: 11pt;" class="">It sounds like the current thinking is a properly formatted empty zone with COTS authoritative server software (no server modification changes required) hosting a proper and complete empty zone. The root delegation would
be typical. I think there would be a change in behavior wrt NXD vs NODATA in some narrow cases, but yeah it seems that would be standards compliant. If you could post the template of the actual zone you’re proposing be hosted that would be illustrative.<o:p class=""></o:p></span></div>
</div>
</blockquote>
</div>
<br class="">
<div class="">The PCA configuration is not clear based on the current text in the <a href="https://docs.google.com/document/d/1oPmy0MVRcqkjOzh-OvJRMomYc76TYxvQSXjbEG8LV9w/edit" class="">Study 2 draft</a>. On p. 31:</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">With PCA, each applied-for string will be delegated in the root and point, with all appropriate glue records, to an authoritative name server for that TLD. The authoritative name server will return NXDOMAIN wherever possible
and log the DNS queries.</blockquote>
<br class="">
</div>
<div class="">And a bit later:</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">This new TLD delegation and empty zone configuration is intended […]</blockquote>
<br class="">
</div>
<div class="">So maybe one could infer an empty zone from the current text, but it’s not obvious. Jeff’s point that different options for implementing PCA were discussed is entirely valid.</div>
<div class=""><br class="">
</div>
<div class="">On a related note, I remain concerned that PCA and especially ACA are not well specified in the document. There is nowhere near sufficient detail. For ACA, the report needs to specify exactly which ports will allow connections, and the exact semantics
of each protocol that is offered on those ports. Client applications can be expected to behave differently, potentially significantly differently, depending on how the ACA server behaves.</div>
<div class=""><br class="">
</div>
<div class="">This group cannot reasonably propose PCA and ACA without a rigorous description of exactly how they would be implemented, or it will be impossible for someone to evaluate their potential impact.</div></div></div></blockquote><div><br class=""></div><div><br class=""></div>I completely agree with this assessment. And to be clear (and as I mentioned previously) the comparison doc does not attempt to *specify*--at least not as its primary purpose. However, in some places (e.g., passive collision assessment) it clearly makes some assumptions, which might or might not be correct. In other places, it makes no assumptions. For example, with active collision assessment, it discusses user experience and security issues with various ports and applications.</div><div><br class=""></div><div>Casey</div></body></html>