Reviewer: Mallory Knodel Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-add-split-horizon-authority-?? Reviewer: Mallory Knodel Review Date: 2024-06-11 IETF LC End Date: 2024-06-06 IESG Telechat date: Not scheduled for a telechat Summary: This document provides clear specifications for an important functionality in the DNS. It's well written from a general area vantage point. Major issues: None. Minor issues: None. Nits/editorial comments: The opening sentence for Section 5 is a bit premature, redundant and leads to some confusion, "To establish its authority over some DNS zone, a..." I would suggest simply removing this opening clause because what is described in that paragraph is an essential component of establishing authority but not the action. The following paragraph begins the same way because it is where the establishing action is described. Furthermore in the penultimate paragraph (bullet points notwithstanding) of Section 5 again the opening phrase is used, "To establish its authority, the network..." Suggest removing this and replacing it with a simple "Then, the network..." to denote that the paragraph goes on to describe the next step in the establishment of authority. In 8.1.2, Step 3: Genuinely unsure if the opening sentence is describing something causal, "The DNSSEC validation is successful and the token matches, so this Authorization Claim is validated," and if so then it might rather be re-phrased "If..., then..." Additionally the next sentence begins with "When" when subtly it should begin with "Once," where the latter implies causation and the former is typically used only if the timing of an action is important. In Security Considerations advice is given to local resolvers when naming their ADN, however the advice is somewhat confusing because I think it might be inaccurate. It says, " To avoid leakage, local resolvers..." but what it's really saying is that leakage is possible and so to avoid negative impacts of that leakage the local resolvers... Please check my (mis)understanding and better clarify what the risk is and what this mitigation can actually achieve. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
