Pardon the formatting, my responses are now in-line.
On Fri, Jun 4, 2021 at 7:44 AM Carsten Bormann <[email protected]> wrote: > On 2021-06-04, at 13:21, L Jean Camp <[email protected]> wrote: > > > > Given the explicit inclusion of licensing in the data structures of SBoM > I think that SHOULD would be too strong in the case that MUD is extended to > SBoMs. Both SPDX and CyCloneDX are integrating licensing in a more nuanced > and consistent manner. > > The current discussion is about the license under which a MUD file is > offered, not about the licenses governing the components of an SBOM. > This interaction between these two standards is a human factors disaster waiting to happen. There is a good case to be made that SBoM in the EO to be the driver for MUD adoption. > > > SHOULD would create a conflict with the extension unless there is an > alternative in the SBoM extension data. > > Unless you envision an SBOM for the SBOM, I think we are clear. > And it would not be an SBOM for the SBOM because the SBOM license is already in the data standard. > > (But we sure can try to be consistent with license description schemes > employed by SBOMs. Please tell us more about those.) > The only example currently implemented is the medical example. I expect the requirements on these to be defined by a FDA statement. Again, otherwise, there will be a license for the SBoM, the components, the sub-components, etc that are expected to be standard software licenses. Except special cases, of which the most developed SBoM pilot is one of these, and the regulatory constraints I expect for be forthcoming. I think Kevin is focusing on those fairly intensely right now. > Grüße, Carsten > > >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
