Éric Vyncke has entered the following ballot position for draft-ietf-dnsop-ds-automation-08: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-ds-automation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke INT AD comments for draft-ietf-dnsop-ds-automation-08 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points/nits. Special thanks to Shumon Huque for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. Other thanks to James Gannon, the DNS directorate reviewer: https://datatracker.ietf.org/doc/review-ietf-dnsop-ds-automation-06-dnsdir-telechat-gannon-2026-05-12/ (and I have read the email discussion) I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## COMMENTS (non-blocking) ### Andy's DISCUSS I second Andy Newton's DISCUSS point about the use of `SHOULD` vs. `MUST`. The sentence in section 3 is not enough IMHO `However, not following any requirements designated with the "SHOULD" key word will generally lead to undesirable effects of ambiguity and interoperability issues.` The use of BCP14 is also questionable as it is not really about interoperation. E.g., section 4.2.2 contains `The reduction should be in effect at least for a couple of days` still providing guidance to the operators without the use of BCP14. Same for section 5.2, which has no BCP14 and still useful. See also next issue. ### BCP status Linked to Andy's DISCUSS, whether this document is BCP or 'informational' is also another question. Some BCP-like RFC (e.g., RFC 9099) are informational and do not rely on BCP14, only plain English "should". _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
