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

Reply via email to