Hi Deb, Thanks for the review.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Deb Cooley via Datatracker <nore...@ietf.org> > Envoyé : mardi 1 avril 2025 01:05 > À : The IESG <i...@ietf.org> > Cc : draft-ietf-netmod-acl-extensi...@ietf.org; netmod- > cha...@ietf.org; netmod@ietf.org; lber...@labn.net; > lber...@labn.net > Objet : Deb Cooley's No Objection on draft-ietf-netmod-acl- > extensions-15: (with COMMENT) > > > Deb Cooley has entered the following ballot position for > draft-ietf-netmod-acl-extensions-15: 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.) > > > ------------------------------------------------------------------ > COMMENT: > ------------------------------------------------------------------ > > Thank you to Sean Turner and Linda Dunbar for their secdir > reviews: > > Section 5, para 2: Please replace the second (and last sentence) > with "The > YANG-based management protocols require the use of a secure [Med] The rationale is to focus on the actual use rather than reasoning about MTI. I will keep the current wording. As a side note, YANG data can be transported over other protocols (including those defined outside the IETF) and I don't think we can make a claim about what they require. > transport layer > such as SSH [RFC4252], TLS [RFC8446], or QUIC [RFC9000]. The > YANG-based > management protocols also require mutual authentication." [Med] Idem as above. We spent some cycles on this in the WG and decided to emphasis on the actual use, which is more important from a deployment standpoint. Will keep the current wording. Thanks > > Section 5, para 4: Please define 'reasonably sensitive or > vulnerable' and [Med] This is coming from the template ;-) More seriously, the intent here is to remind that all configurable nodes may be misused. There might be some cases such as "description" or "comment" like data nodes, but even those, they are used sometimes by operators to enclose operational data (and thus case feed other misuses). We don't want the authors of YANG documents to list every data node in the security section, but only focus on those that particularly sensitive. > 'particular sensitivities/vulnerabilities. Alternatively, delete > the words > 'reasonably' and 'particular'. [Med] "Particular" is used on purpose as we focus on those that may lead to major disruption. FWIW, this mirrors the this part of RFC8407: * Writable data nodes that could be **especially** disruptive if abused MUST be explicitly listed by name, and the associated security risks MUST be explained. > > Section 5, para 5: Perhaps the second to last sentence should say > 'The former > may result in the exposure of sensitive data, or compromise a > device. > [Med] "Exposure of sensitive data" is not a vulnerability of a writeable parameter. The OLD is more accurate as this is about issues with writeable data node, not readable ones. I will keep the current text as it is. Thanks. > Section 5, para 7: Please delete the word 'particular'. [Med] Idem as above. This is important as we don't list every node, but only those that matches this part from 8407: "Readable data nodes that contain **especially** sensitive information or that raise significant privacy concerns MUST be explicitly listed by name, and the reasons for the sensitivity/privacy concerns MUST be explained." ____________________________________________________________________________________________________________ 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. _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
