Hi Roman, Thank you for your review. You raise a very valid point.
Indeed, there are some defining features of DS automation without which one doesn't really have an implementation. I've scanned the document for those, and elevated them from SHOULD to MUST. I believe that this is in effect a no-op change, as claiming conformance otherwise would be somewhat dubious, that is, serious implementers would adhere to those anyway. For a list of changes and further explanations see my response to Donald Eastlake who had originally raised this: https://mailarchive.ietf.org/arch/msg/dnsop/fKCJftrUql1Jtatp_l0rvXpjSdo/ I've pushed a new revision with these improvements. Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-ds-automation-08 I hope this removes the concerns that led to your ABSTAIN! Best, Peter On 5/18/26 22:42, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-ds-automation-07: Abstain 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: ---------------------------------------------------------------------- Thank you to Thomas Fossati for the GENART review. # Summary Thank you for the efforts of the WG in producing this draft and finding consensus on the recommendations. I am filing an ABSTAIN because it isn’t clear to me how an entirely optional document can guide interoperability. Practically, any behavior is conformant according to recommendations in the draft. # Details ** Section 3 Deployments of DS automation SHOULD follow the recommendations set out in this document, both to achieve a more uniform treatment across suffixes — minimizing user surprise — and to prevent disruption of DNS and DNSSEC functionality. The recommendations are intended to provide baseline safety and uniformity of behavior across parents. -- These recommendations will fail to provide “baseline safety or uniformity” because there is no mandatory conformance specified in this document. All individual recommendations statements are “SHOULD (NOT)” or “(NOT) RECOMMENDED”. If there was any confusion, the first sentence reminds operators that this entire document is not mandatory. An operator can ignore these thoughtful recommendations and be fully conformant to this BCP. -- Given the interoperability is not being specified, it isn't clear why this document isn't being published with informational status. -- The editorial construction of this document relying on BCP14 language seems like it would hamper future efforts by other RFCs or outside policy guidance to make the recommendations (or subsets of them) mandatory since each recommendation is framed as optional (not mandatory). _______________________________________________ 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]
