I agree with Kent and Qiufang that we do not need to change the Security Considerations section.
NETCONF [RFC6241] and RESTCONF[RFC8040] already talk about authentication, integrity, and confidentiality, and the Security Considerations section is reiterating the state as it exists today (though the language could be improved), not stipulating a new normative requirement. Thanks. > On Jun 10, 2026, at 3:17 AM, Kent Watsen <[email protected]> wrote: > > I disagree with the s/have to/MUST/ change. > > The paragraph’s intent is to state that which exists, without the auspice of > creating new normative rules. > > Kent > > >> On Jun 10, 2026, at 2:43 AM, maqiufang (A) >> <[email protected]> wrote: >> >> Hi, Magnus, >> >> Thanks a lot for the review. >> >> Your points make sense to me, and also are consistent with what has already >> stated in sec.2.2 of RFC 6241 >> (https://datatracker.ietf.org/doc/html/rfc6241#section-2.2) and sec.2.1 of >> RFC8040 (https://datatracker.ietf.org/doc/html/rfc8040#section-2.1). The >> authors have proposed a PR to address them: >> https://github.com/netmod-wg/immutable-flag/pull/25/changes. >> >> However, please also note that the paragraph you commented on is inherited >> from the Security Considerations template in RFC 9907. I have CC-ed Mahesh >> and also the WG to see if there is any intention to update the global >> template (https://wiki.ietf.org/group/ops/yang-security-guidelines) for >> future security considerations with YANG data models as well. >> >> Best Regards, >> Qiufang // co-author >> >> -----Original Message----- >> From: Magnus Nyström via Datatracker [mailto:[email protected]] >> Sent: Tuesday, June 9, 2026 4:29 AM >> To: [email protected] >> Cc: [email protected]; [email protected]; >> [email protected] >> Subject: draft-ietf-netmod-immutable-flag-11 ietf last call Secdir review >> >> Document: draft-ietf-netmod-immutable-flag >> Title: YANG Metadata Annotation for Immutable Flag >> Reviewer: Magnus Nyström >> Review result: Has Nits >> >> The netmod-immutable-flag I-D is well written as is it's Security >> Considerations section. However, I do have one suggestion which is to >> specify not just that secure transport layer "have to" (which BTW is not >> RFC2119) be used, but also the actual requirements of that layer - e.g., is >> confidentiality required? Is integrity? E.g., the need for mutual >> authentication is proscribed, but without integrity protection that could >> prove less valuable. >> >> >> -- >> last-call mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
