Thanks Peter, Your responses to SECDIR look good to me thanks and good luck for LC.
-- James On Thu, 14 May 2026 at 03:51, Peter Thomassen <[email protected]> wrote: > Hi James, > > Thank you very much for your review! > > With the exception of one typo ("completeless" --> "completeness", which I > have fixed [1]), it entirely restates points made by Donald Eastlake in his > SECDIR review which I've addressed earlier today [2]. Unfortunately I went > serially (so I read your review only now), otherwise I'd have addressed > both reviews jointly. > > To keep discussion on individual points in one place, I ask you to look at > the responses in [2] and continue the conversation there when needed. > > Thanks, > Peter > > [1]: > https://github.com/desec-io/draft-ietf-dnsop-ds-automation/commit/437a21c48946d48b9af8907bbe7e9636af5d366e > [2]: > https://mailarchive.ietf.org/arch/msg/dnsop/2PYF50Z5iV39kBXOIjsOgSgh2VU/ > > > On 5/12/26 22:58, James Gannon via Datatracker wrote: > > Document: draft-ietf-dnsop-ds-automation > > Title: Operational Recommendations for DNSSEC Delegation Signer (DS) > Automation > > Reviewer: James Gannon > > Review result: Ready with Issues > > > > DNSDIR telechat review of draft-ietf-dnsop-ds-automation-06 > > Hi Folks, > > > > I am the assigned DNS Directorate reviewer for this revision of the > draft. > > Please treat these comments like any other IETF Last Call comments. > > > > Document: draft-ietf-dnsop-ds-automation-06 > > Reviewer: James Gannon > > Review Date: 2026-05-12 > > Review Result: Ready with Issues > > > > The document is useful, well structured, and operationally valuable. The > > recommendations are clear overall, and the Appendix A summary is > especially > > helpful. Most previous Last Call review comments appear to have been > addressed > > in `-06`; however, I think a few issues remain, primarily around the > Security > > Considerations and some unresolved review comments from the SECDIR > review. > > > > Major issues: > > > > 1. Section 10, Security Considerations, is too thin. > > > > The document is explicitly about operational practices that affect DNSSEC > > validation and delegation reachability. Section 10 currently says that > security > > considerations are discussed throughout the document, but it does not > summarize > > the threat model or provide concrete examples. > > > > I think this section should briefly discuss at least: > > > > - compromise or misbehavior of the child DNS operator; > > - compromise or misbehavior of registrar or registry-side automation in > the RRR > > model; - on-path interference with CDS/CDNSKEY discovery or > report/notification > > flows; - how consistency checks, DNSSEC validation, reporting, and audit > > records mitigate those risks; - residual risks when the recommendations > are not > > followed. > > > > This would also address the main unresolved SECDIR concern. > > > > Minor issues: > > > > 1. Section 5.1 recommendation 3 says humans should not be notified > > “unnecessarily frequently”. This is directionally right, but vague for a > BCP. > > Consider adding a concrete upper-bound example or guidance, such as > notifying a > > few times initially and then no more than daily while the same condition > > persists. > > > > 2. Section 5.2 says that in the latter two cases, it “would be justified > to > > attempt communicating” using RFC 9567. This seems weaker than the rest > of the > > document’s recommendation style. If these are the reportworthy error > cases, > > consider changing this to a `SHOULD`. > > > > 3. Section 7.1 recommendation 1 says registries and registrars `SHOULD` > provide > > another channel for DS maintenance. Given that this is necessary for > recovery > > when the child has lost access to signing keys, I suggest considering > whether > > this should be `MUST`, or explaining why `SHOULD` is intentionally > sufficient. > > > > 4. Section 7.2.3 characterizes DS flapping from concurrent automatic > updates as > > a “minor nuisance”. The text explains why validation is not expected to > break, > > but there may still be operational impact from churn, logs, > notifications, rate > > limits, or registry/registrar side effects. Consider qualifying the > statement > > or adding that operators should monitor and dampen repeated churn. > > > > Nits: > > > > - Section 3: “Recommendations given in this document are optimized as to > > maximize…” is awkward. Consider “Recommendations in this document > optimize > > interoperability and safety.” - Section 4.2.2: “For the sake of > completeless” > > should be “For the sake of completeness”. - Section 7.1 point 5: “has > declared > > to be performing automated” could be “has declared it performs > automated”. - > > Section 7.2.1: “the key used by for authentication” should be “the key > used for > > authentication”. - Section 7.2.2: “It is therefore advised to not follow > this > > practice” could be “This practice is NOT RECOMMENDED.” - Section 11: > expand > > SSAC on first use. > > > > > > _______________________________________________ > > DNSOP mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > -- > Like our community service? 💛 > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Möckernstraße 74 > 10965 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
