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

From: Eliot Lear <[email-masked]>
Date: Thu, 27 May 2021 12:04:06 +0200

[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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 27 May 2021 19:51:34 -0400

Some WG please adopt.
Probably that's opsawg, iotops or maybe netmod, if netmod thinks this could
be generalized easily.

Eliot Lear <[email-masked]> wrote:
    el> The extension is written as a grouping that is then 'used' to augment
    el> a 'mud' container.  The intent here is that if you find the need to
    el> use the extension for other purposes, you can.  I wonder if some yang
    el> doctors would like to take a look. We'd like to move on this one
    el> quickly.

It looks fine.

On the issue of multiple owners, each would have their own tag, I think that
should be supported.  So, instead of:

       "ol": {
         "owners": [
           "Copyright (c) FrobMaster 2021. All Rights Reserved"
         ],
         "spdx-tag": "0BSD"
       },

I think we need:

       "ol": [
         {
           "owner": "Copyright (c) FrobMaster 2021. All Rights Reserved"
           "spdx-tag": "0BSD"
         }
         ]
       },

> *Issue*: Should this be an owner or an originator?

If by "owner" you mean the of the device, then perhaps you mean manufacturer
or owner?   Or the initial creator of the MUD file, and then I think that
maybe "originator" might be clearer.

>   *  *Issue*: Should we simply say that a URI contains a colon and SPDX
>      license identifier doesn't?

No, I think that I'm happy with different tags.

>   *  *Issue*: Should a single owner possibly have multiple license
>      types?  (Logical or, multi-licensing.)

Uhm, so the Perl ARTISTIC license, which I think is a single license,
is a superposition of two licenses, but it can be represented as a single
license.  So, no.

>   *  *Issue*: Should we give an example for usage outside yang?

if such a situation should present itself in the next 10 weeks, sure.

>   *  *Issue*: Should we maybe point out any specific seccons of 8520?

The only issue I can see is that claiming a copyright might reveal that such
an entity has dealt with such a device.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 May 2021 02:05:46 +0200

> is a superposition of two licenses, but it can be represented as a single

While the Perl artistic license was a goof with a particularly high visibility, there are lots of other situations that call for multi-licensing.
So I’m not sure that Perl is even an good example here.

Grüße, Carsten

---

From: <[email-masked]>
Date: Fri, 28 May 2021 09:18:07 +0000

Hi Eliot, all,

This extension makes sense to me. I support it to be adopted in opsawg (where 8520 was developed).

That's said, this draft does not update 8520. I suggest to remove "Updates: 8520 (if approved)"

Please find below some other comments, fwiw.  

(1)

OLD: 

     import ietf-inet-types {
       prefix inet;
     }

NEW
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types, Section 4";
     }

(2) Use the prefix as defined in 8520:

OLD: 

     import ietf-mud {
       prefix mud;
     }

NEW:

     import ietf-mud {
       prefix ietf-mud;
       reference
         "RFC 8520: Manufacturer Usage Description Specification";
     }

(3)

You may remove the note about normative language in the description of the module given that you don't use it. 

(4)

OLD: 
       reference
         "RFC XXXX: Extension for ownership and licensing";
NEW:
       reference
         "RFC XXXX: Ownership and licensing statements in YANG";

(5)

Rather than using "leaf-list owners", I would define this as a list keyed by owners and which may include a leaf-list of licenses. Rather than defining license as a choice, I would use a "union".

(6)

OLD: 

       "ol": {
         "owners": [

NEW:
       "ietf-ol:ol": {
         "owners": [

(7) Please update the IANA section as follows: 

OLD:
   The IANA is requested to add "ol" to the MUD extensions registry as
   follows:

     Extension Name: ol
     Standard reference: This document

NEW:
   The IANA is requested the following entry to the MUD extensions registry
   available at: https://www.iana.org/assignments/mud/mud.xhtml#mud-extensions 

     Extension Name: ol
     Reference: This document

(8) Please update the IANA section with the following:

NEW

   This document requests IANA to register the following URI in the "ns"
   subregistry within the "IETF XML Registry" [RFC3688]:

         URI: urn:ietf:params:xml:ns:yang:ietf-ol
         Registrant Contact: The IESG.
         XML: N/A; the requested URI is an XML namespace.

   This document requests IANA to register the following YANG module in
   the "YANG Module Names" subregistry [RFC6020] within the "YANG
   Parameters" registry.

         name: ietf-ol
         namespace: urn:ietf:params:xml:ns:yang:ietf-ol
         maintained by IANA: N
         prefix: ol
         reference: RFC XXXX

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[email-masked]] De la part de Eliot Lear
> Envoyé : jeudi 27 mai 2021 12:04
> À : [email-masked]
> Cc : netmod WG <[email-masked]>
> Objet : [OPSAWG] please see draft-lear-opsawg-ol on licensing
> 
> [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

_________________________________________________________________________________________________________________________

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: Eliot Lear <[email-masked]>
Date: Fri, 28 May 2021 13:43:00 +0200

Hi Med,

Thanks for your comments.  Please see below.

>           "RFC 6991: Common YANG Data Types, Section 4";

Sure, thanks.

>           "RFC 8520: Manufacturer Usage Description Specification";

Right.

> You may remove the note about normative language in the description of the module given that you don't use it.

I think we need to discuss this more, because we SHOULD be applying a 
SHOULD on this document to 8520 so that there is no IPR confusion.  And 
that implies an update.

>           "RFC XXXX: Ownership and licensing statements in YANG";

Corrected, thanks.

> Rather than using "leaf-list owners", I would define this as a list keyed by owners and which may include a leaf-list of licenses. Rather than defining license as a choice, I would use a "union".
We're still discussing the substance of this.
>             "Copyright (c) FrobMaster 2021. All Rights Reserved"
Still working on this.
>     available at: https://www.iana.org/assignments/mud/mud.xhtml#mud-extensions
Done.  Thanks.
>           namespace: urn:ietf:params:xml:ns:yang:ietf-ol
What does "maintained by IANA" mean in this context?

Thanks again for the update.

Eliot

---

From: <[email-masked]>
Date: Fri, 28 May 2021 11:59:33 +0000

Re-,

Please see inline. 

Cheers,
Med

> De : Eliot Lear [mailto:[email-masked]]
> Envoyé : vendredi 28 mai 2021 13:43
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>;
> [email-masked]
> Objet : Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing
> 
> Hi Med,
> 

[Med] I guess this is covered by on one of your replies below, but still don't see which part in 8520 is updated here. If you have an excerpt to share, that would be helpful. 

...
> 
> > (3)
> >
> > You may remove the note about normative language in the description
> of the module given that you don't use it.
> 
> SHOULD on this document to 8520 so that there is no IPR
> confusion.  And that implies an update.

[Med] It is fine to mandate that when 8520 is supported, this extension SHOULD be supported. But again, that is not updating 8520. 

So, unless you include such normative statement as part of the module I don't see the need to maintain the note about normative language in the description.

...
> 
> >
> > (5)
> >
> > Rather than using "leaf-list owners", I would define this as a list
> keyed by owners and which may include a leaf-list of licenses. Rather
> than defining license as a choice, I would use a "union".

[Med] Where this discussion is happening? 

> >             "Copyright (c) FrobMaster 2021. All Rights Reserved"

[Med] Sorry, but I don't get your comment. "ol" should be prefixed with the name of the extension as this is different from the parent one. Please check Section 4 of RFC7951.

> >     available at:
> https://www.iana.org/assignments/mud/mud.xhtml#mud-extensions
> >
> >       Extension Name: ol
> >       Reference: This document
> Done.  Thanks.

[Med] This is whether the module will be updated by IANA, e.g., to reflect changes in some IANA-maintained registries. This is not the case for your draft.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 May 2021 10:27:26 -0400

> "Updates: 8520 (if approved)"

It Extends 8520.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 May 2021 10:28:12 -0400

> [Med] I guess this is covered by on one of your replies below, but
    > still don't see which part in 8520 is updated here. If you have an
    > excerpt to share, that would be helpful.

It does not Amend. It Extends.

---

From: <[email-masked]>
Date: Fri, 28 May 2021 14:41:14 +0000

Re-,

Agree it extends, but unless I'm mistaken we don’t have yet those tags (draft-kuehlewind-update-tag).

Cheers,
Med

> De : Michael Richardson [mailto:[email-masked]]
> Envoyé : vendredi 28 mai 2021 16:28
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : Eliot Lear <[email-masked]>; [email-masked]
>     >> > That's said, this draft does not update 8520. I suggest to
> remove
>     >> "Updates: 8520 (if approved)"
>

---

From: tom petch <[email-masked]>
Date: Fri, 28 May 2021 15:52:45 +0000

From: OPSAWG <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: 28 May 2021 15:41

Re-,

<tp>
Well-formed I-D should explain how they update what they claim to update.  This one does, sort of, in the Introduction.  What is missing is text such as
Section.x.y of RFC8520 is updated to include the following paragraph
"Those generating MUD files SHOULD use the owner-license [RFCxxxx] extension unless ...2 

Tom Petch

Cheers,
Med

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 May 2021 18:28:55 +0200

Hi Tom,

What the draft says:

 > Those generating MUD files SHOULD use this extension, and thus this 
extension updates RFC 8520.

Regarding the words, "extends" or "updates", I have no horse in that race.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 May 2021 18:12:57 -0400

> (draft-kuehlewind-update-tag).

They are all variations of "Updates"

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: <[email-masked]>
Date: Mon, 31 May 2021 08:10:21 +0000

Hi Michael, 

Actually, there is no established practice for those. 

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. 

Cheers,
Med

> De : Michael Richardson [mailto:[email-masked]]
> Envoyé : samedi 29 mai 2021 00:13
>     > Agree it extends, but unless I'm mistaken we don’t have yet
> those tags
>     > (draft-kuehlewind-update-tag).
>