Reviewer: Anthony Somerset Review result: Ready with Issues Hello I have been selected as the DNS Directorate reviewer for this draft. The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the ADs. For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir There are are clear and direct references to various DNS RFC's and this draft is not in any major conflict with the wider DNS space but the following specific suggestions relating to DNS are made. I previously Reviewed Version 18 of this draft and am re-rereviewing in line with the comments I made in that review - https://datatracker.ietf.org/doc/review-ietf-homenet-front-end-naming-delegation-18-dnsdir-telechat-somerset-2022-10-12/ Having re-read the new version a few times, and keeping track of the various reviews as not to duplicate reports for same issues i will try not say the same things again. I specifically note that Geoff has done a very definitive review of version 25 of the document and i won't repeat those comments in this review but suffice to say i do concur with the assessment of the situation in his review and agree with the position of Ready with Issues as well I am happy with the large effort to reflow the document - it does now read in a more sensible order and helps with clarity. I am also happy with the additional security considerations that make sense. Major Issues: None Minor Issues: Section 2 - Public Authoritative Servers - my original NIT was dealt with but I note that anycast is now referenced here which is still extraneous, we are not attempting to deal with the standard of how Public Authoritative Servers be managed operationally Section 3 - now Section 5 - i note specifically the comment about: "In the case the HNA is a CPE, outsourcing to the DOI protects the home network against DDoS for example." I personally would consider this a dangerously inaccurate statement. This offers NO protection against a DDoS, at best it (only) slightly reduces the attack surface exposed but it provides no meaningful additional protection. I specifically repeat this and recommend the statement be removed or re-worded appropriately Section 3.2 - Original NIT dealt with 1.1 - now 3 - NIT dealt with 3.1 now 5.1 - Typo fixed 4.5.1 - now 6.5.1 - i believe this NIT to be well addressed now, the reflowing of the document definitely helps here. Thanks -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
