Subject: Re: [netmod] [OPSAWG] please see draft-lear-opsawg-ol on licensing

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Jun 2021 13:43:59 +0200

On 2021-06-04, at 13:21, L Jean Camp <[email-masked]> 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.

> 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.

(But we sure can try to be consistent with license description schemes employed by SBOMs.  Please tell us more about those.)

Grüße, Carsten

---

From: L Jean Camp <[email-masked]>
Date: Fri, 4 Jun 2021 07:21:24 -0400

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.

SHOULD would create  a conflict with the extension unless there is an
alternative in the SBoM extension data.

On Thu, May 27, 2021 at 6:04 AM Eliot Lear <[email-masked]> wrote:

> [CC netmod]
>
> Hi everyone,
>
> Based on Carsten's concerns about licensing of MUD files we wrote a very
> short extension to RFC 8520 to allow statements to be added.  I note it
> misses an Updates: header, but we should probably add that so people
> know they SHOULD use this extension.
>
> The extension is written as a grouping that is then 'used' to augment a
> 'mud' container.  The intent here is that if you find the need to use
> the extension for other purposes, you can.  I wonder if some yang
> doctors would like to take a look. We'd like to move on this one quickly.
>
> Eliot
>
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: L Jean Camp <[email-masked]>
Date: Fri, 4 Jun 2021 09:40:52 -0400

If MUD is only used to obtain the SBoM then there is already a license of
the MUD-File (and a place to seek updates) in that case because the
MUD-File that is obtained is itself a bom.  So including licensing
information about the MUD-File is a structure that will require repeating
information that is already embedded in the file itself, and thus increase
the chance of conflict.

The component licensing in the (why are there 2? I do not know) data
structures are just YANG specifications to enable consistent XML or JSON
descriptions of licensing requirements, enabling a list to  point to
licensing of the SBoM itself as well as any level of specific per-component
or sub-component licenses.

On Fri, Jun 4, 2021 at 7:44 AM Carsten Bormann <[email-masked]> 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
> The current discussion is about the license under which a MUD file is
> offered, not about the licenses governing the components of an SBOM.
>
> (But we sure can try to be consistent with license description schemes
> employed by SBOMs.  Please tell us more about those.)
>
> Grüße, Carsten
>
>
>

---

From: L Jean Camp <[email-masked]>
Date: Fri, 4 Jun 2021 13:08:52 -0400

Pardon the formatting, my responses are now in-line.

> 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.

> 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.

> 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.