Hi Yoav, Thank you for the thoughtful review. For your "oddity" point :-), this "style" is inherited from 8407 where we have the following: This section MUST be patterned after the latest approved template (available at <https://trac.ietf.org/trac/ops/wiki/yang-security- guidelines>). Section 3.7.1 contains the security considerations template dated 2013-05-08 and last updated on 2018-07-02. Authors MUST check the web page at the URL listed above in case there is a more recent version available. Having a readily available URL there is more convenient for YANG modules authors. That’s said, I don't have a strong objection to format this as a "normal" reference entry if you think that is better. Thanks. Cheers, Med (as editor) > -----Message d'origine----- > De : Yoav Nir via Datatracker <noreply@xxxxxxxx> > Envoyé : dimanche 25 mai 2025 22:27 > À : secdir@xxxxxxxx > Cc : draft-ietf-netmod-rfc8407bis.all@xxxxxxxx; last-call@xxxxxxxx; > netmod@xxxxxxxx > Objet : draft-ietf-netmod-rfc8407bis-25 telechat Secdir review > > Document: draft-ietf-netmod-rfc8407bis > Title: Guidelines for Authors and Reviewers of Documents Containing > YANG Data Models Reviewer: Yoav Nir Review result: Ready > > Well, this is very meta. I'm reviewing a document about guidelines > for (authors > and) reviewers of documents. In particular, documents contraining > YANG models. > My review is specifically a security (directorate) review, and the > document has a section (3.7) about (writing and) reviewing Security > Considerations sections. > The document, among other things, defines (in section 3.7.1) a > template for the Security Considerations section of documents > containing YANG modules. > > The document has an obligatory Security Consideration section of > its own, that sadly does not follow the template in section 3.7.1, > even though section 5.1 does seem to register the "ietf-template" > and the "iana-template" YANG modules. > However, those only exists as examples, so that is fine. Instead > the section has the usual (and true) statement that the document > does not introduce any new risks. > > Section 3.7 has guidelines for the Security Considerations, > specifically that documents following RFC 8791 (data structure > extensions) are exempt from following the template in 3.7.1, while > others are not. I'm no expert on YANG, but the content of the > template seems fine, discussing the need for authentication and > authorization when writing to writable nodes, and the protection of > sensitive data in the readable nodes. The template does not go into > details about what sensitive data is, but that varies by domain and > cannot be generalized to all uses of YANG. To me, the template > looks fine, and I have seen it or earlier versions of it in > previous documents. > > There is one oddity that I'd like to point out. Section 3.7 gives a > URL for the "official template". The webpage for that URL has the > exact same text as the template in section 3.7.1. That is fine now, > but the text is explicit that the text of the template on the web > page may change - "Authors MUST check the web page at the URL > listed above in case there is a more recent version available". > The template itself does not contain RFC 2119 terminology, and > anyway, the Security Considerations section in any document is > subject to review whether it is based on a template or not. Still, > it is strange for a document to reference like that (and it is not > mentioned in the References section) a web page that is subject to > change. > ____________________________________________________________________________________________________________ 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
