Hi Peter and Med, These were non blocking comments. And on the first one, I was not sure if there was a problem; I was just cross-checking.
Thanks for your responses; it looks good to go. Thanks, Ketan On Thu, May 21, 2026 at 7:07 PM <[email protected]> wrote: > 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]
