Ketan Talaulikar 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: ---------------------------------------------------------------------- Thanks to the authors and the WG for their work on this document. I have a couple of comments to offer. 1) This is provided as a comment instead of a DISCUSS since I am not familiar with this subject matter. I would request my fellow ADs and the authors/WG to cross-check. Sec 6.1 says: To secure ongoing operations, automated DS maintenance MUST NOT be suspended based on a registrar update lock alone (such as EPP status clientUpdateProhibited [RFC5731]). When performed by the registry, automated DS maintenance MUST NOT be suspended based on a registry update lock alone (such as EPP status serverUpdateProhibited [RFC5731]). Is this in sync with what is specified in RFC5731 (not just letter but also spirit)? Or does it overrule that specification in the context of DS operations? RFC5731 is an Internet Standard. I don't think this document updates that, but well ... just checking! 2) Given that this is a BCP, I would suggest to remove Appendix A to avoid duplication of the text. IMHO it is equally important for readers to go through the analysis that is accompanying the recommendations to grasp the full context. We have AI for summaries ;-) _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
