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

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Jun 2021 08:53:03 +0200

On 2021-05-31, at 10:10, [email-masked] wrote:
> 
> If so, every extension (including modules with augment) would be tagged as updating their base RFC...while this is not the case. There are plenty examples out there. 

This is not a syntactical issue (augment and all that), but a semantic one:
RFC 8520 is updated with a "SHOULD use this".  That is the RFC 8520 update, not the new module.

Grüße, Carsten

---

From: <[email-masked]>
Date: Fri, 4 Jun 2021 09:34:19 +0000

Hi Carsten, 

That's more a profiling thing than updating the base spec. 

Let's consider an example that you are very familiar with: RFC7252. The core WG published RFC8768 which says "New CoAP proxies MUST implement this option and have it enabled by default" without marking this as updating 7252. 

What I'm really concerned about is consistent use of the "update" header.

Cheers,
Med

> -----Message d'origine-----
> De : Carsten Bormann [mailto:[email-masked]]
> Envoyé : vendredi 4 juin 2021 08:53
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : Michael Richardson <[email-masked]>; [email-masked]
> Objet : Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing
> 
> > If so, every extension (including modules with augment) would be
> tagged as updating their base RFC...while this is not the case.
> There are plenty examples out there.
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Jun 2021 12:12:52 +0200

> What I'm really concerned about is consistent use of the "update" header.

That’s the IESG’s job — above my paygrade :-)

What I’m concerned is that 8520 readers find a pointer to the new document.
An “updated by” on the (metadata rich versions of) 8520 raises the likelihood substantially.
Which is more important than any concept of consistency (which we won’t really have until the IESG is done with Mirja’s proposals).

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Fri, 4 Jun 2021 12:17:07 +0200

On 04.06.21 12:12, Carsten Bormann wrote:
> On 4. Jun 2021, at 11:34, <[email-masked] 
> <mailto:[email-masked]>> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>

That's what I would want.

Eliot

---

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: 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: <[email-masked]>
Date: Fri, 4 Jun 2021 11:50:26 +0000

Re-,

It is also ours as participants, Carsten.

If you really want to make sure that extension is considered by a MUD implementer (and this is really about the augment thing), you can consider defining version 2 of the mud module in the ol I-D. This is a much more clean design to convey the message you want.

Cheers,
Med

Envoyé : vendredi 4 juin 2021 12:13

On 4. Jun 2021, at 11:34, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Fri, 4 Jun 2021 15:11:12 +0200

On 04.06.21 13:50, [email-masked] wrote:
> If you really want to make sure that extension is considered by a MUD 
> implementer (and this is really about the augment thing), you can 
> consider defining version 2 of the mud module in the ol I-D. This is a 
> much more clean design to convey the message you want.
>
I don't know that we want to tell v1 implementations that they SHOULD 
NOT parse the rest of the file because of this.

Eliot

> Cheers,
>
> Med
>
> *De :*Carsten Bormann [mailto:[email-masked]]
> *Envoyé :* vendredi 4 juin 2021 12:13
> *À :* BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> *Cc :* Michael Richardson <[email-masked]>; [email-masked]
> *Objet :* Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing
>
> Which is more important than any concept of consistency (which we 
> won’t really have until the IESG is done with Mirja’s proposals).
>
> Grüße, Carsten
>

---

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.