Re-, I hear Ketan's point but other reviewers also appreciated that appendix. For example, Thomas shared this feedback [1]:
"The condensed guidance in Appendix A (Recommendations Overview) is a really nice addition." I tend to suggest to keep it for convenience of having one single place to point to for the complete list of recos. Cheers, Med [1] https://datatracker.ietf.org/doc/review-ietf-dnsop-ds-automation-05-genart-lc-fossati-2026-04-28/ > -----Message d'origine----- > De : Peter Thomassen <[email protected]> > Envoyé : jeudi 21 mai 2026 15:28 > À : Ketan Talaulikar <[email protected]>; The IESG > <[email protected]> > Cc : [email protected]; [email protected]; draft-ietf-dnsop-ds- > [email protected] > Objet : [iesg] Re: [DNSOP] Ketan Talaulikar's No Objection on > draft-ietf-dnsop-ds-automation-08: (with COMMENT) > > > Hi Ketan, > > Thank you for your review! Please see below. > > On 5/21/26 15:18, Ketan Talaulikar via Datatracker wrote: > > ---------------------------------------------------------------- > > 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! > > This recommendation was developed in consultation with Scott > Hollenbeck, who's the author of the RFC 5731, and does not update > another RFC. > > Here's the history if you'd like to trace it: > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > mailarchive.ietf.org%2Farch%2Fbrowse%2Fdnsop%2F%3Fq%3Dlocks%2520ds > - > automation&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C356cef4 > 76d854837b46a08deb73cc1ae%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639149668743511545%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=8XXXeWEw5YHnlipIOPfM53EQCH1F88Qtw4SIQS > EqcIA%3D&reserved=0 > > > 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 > > ;-) > > As there are many recommendations, it seemed useful to have an > implementation overview for those who just want to work through it > without deviating. > > However, I see your point and appreciate the suggestion. I'm not > sure where the consensus lies about that, and will make the change > if other IESG (or DNSOP) members chime in. > > Best, > Peter ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
