Hi Eliot, Thanks. I’ll initiate IETF LC on -14. It is possible that the “necessarily” may mean that the SEC ADs will want more of the regular YANG security considerations to be included, but we can cross that bridge during the IESG review, if needed.
Regards, Rob From: Eliot Lear <l...@lear.ch> Sent: 27 February 2023 13:25 To: Rob Wilton (rwilton) <rwil...@cisco.com>; draft-ietf-opsawg-sbom-access....@ietf.org Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-sbom-access-12 Rob: I think it's appropriate to accept all of your proposed changes with one caveat: On 07.02.23 14:50, Rob Wilton (rwilton) wrote: Hi Eliot, The only thing that I think that we need to tweak is the security section, where I think that we need to be more explicit that this module is not designed to be used by NETCONF/RESTCONF specifically to exempt you for needing regular YANG security considerations template text (which you don't have). Possibly, something like this: OLD: This document describes a schema for discovering the location of information relating to software transparency, and does not specify the access model for the information itself. NEW: This document describes a schema for discovering the location of information relating to software transparency, and does not specify the access model for the information itself. In particular, the YANG module specified in this document is not necessarily intended to be accessed via regular network management protocols, such as the NETCONF [RFC6241] or RESTCONF [RFC8040], and hence the regular security considerations for such usage are not considered here. That is, if someone wants to play around with this with NETCONF/RESTCONF, there's nothing there to stop them. Your point about intent is key, tho. Eliot
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg