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]
