Re: [OPSAWG] Source attribution in MUD files (RFC 8520)

[Hassan Habibi Gharakheili]

We have now added that suggested line (SPDX-License-Identifier: MIT-0).
Please check: https://iotanalytics.unsw.edu.au/mudprofiles


Regards,
Hassan

From: Carsten Bormann 
Date: Friday, 4 June 2021 at 8:10 pm
To: Hassan Habibi Gharakheili 
Cc: Eliot Lear , opsawg@ietf.org , Ayyoob Ahamed 
Hamza 
Subject: Re: [OPSAWG] Source attribution in MUD files (RFC 8520)
Great!

The only other thing I could suggest is adding the line:
SPDX-License-Identifier: MIT-0
Between the word “license” and the copyright line.

Grüße, Carsten




On 4. Jun 2021, at 12:00, Hassan Habibi Gharakheili 
mailto:h.hab...@unsw.edu.au>> wrote:

Done.
Please check: https://iotanalytics.unsw.edu.au/mudprofiles

Regards,
Hassan

From: Carsten Bormann mailto:c...@tzi.org>>
Date: Friday, 4 June 2021 at 7:19 pm
To: Hassan Habibi Gharakheili 
mailto:h.hab...@unsw.edu.au>>
Cc: Eliot Lear mailto:l...@lear.ch>>, 
opsawg@ietf.org 
mailto:opsawg@ietf.org>>, Ayyoob Ahamed Hamza 
mailto:m.ahamedha...@unsw.edu.au>>
Subject: Re: [OPSAWG] Source attribution in MUD files (RFC 8520)
On 2021-06-04, at 10:41, Hassan Habibi Gharakheili 
mailto:h.hab...@unsw.edu.au>> wrote:
>
> Sure. We are happy to put up a LICENSE file in our repository 
> (https://iotanalytics.unsw.edu.au/mudprofiles).  It would be great if you 
> could provide us with a simple template of such license, or we should develop 
> one?

Licenses are like crypto algorithms: They are better developed by specialized 
individuals and heavily cross-checked before being employed.  I would go for 
OSI-approved licenses only.

> Once we put up the license, we can also augment the “systeminfo” field of 
> every MUD profile with the URL of the license.
>
> For example,
> · systeminfo: "lifxbulb",
> becomes something like this:
> · systeminfo: "lifxbulb 
> (https://iotanalytics.unsw.edu.au/mud/license.txt)",
> Your thoughts?

3.7.  systeminfo

   This is a textual UTF-8 description of the Thing to be connected.
   The intent is for administrators to be able to see a brief
   displayable description of the Thing.  It SHOULD NOT exceed 60
   characters worth of display space.

I don’t think the admins want to be bothered with this in the place where they 
expect info about the Thing.

That’s exactly why I suggested adding something to MUD.

For now, as Eliot said, an SPDX-Identifier is the easiest way to reference a 
license.  Choose between heavily used and sufficiently permissive licenses, 
e.g., 0BSD, MIT, BSD-3-Clause.  Licenses that require the copier to copy the 
copyright as well are currently a bit icky, as that copyright cannot be 
reasonably put into the MUD file yet.  0BSD and especially MIT-0 look quite 
good from this perspective.

https://spdx.org/licenses/

TL;DR:
Just copy the text at https://spdx.org/licenses/MIT-0.html (after filling in 
the variables) and place it (the whole text) on 
https://iotanalytics.unsw.edu.au/mudprofiles for now.

Grüße, Carsten


>
> Regards,
> Hassan
>
>
> From: Carsten Bormann mailto:c...@tzi.org>>
> Date: Friday, 4 June 2021 at 5:04 pm
> To: Hassan Habibi Gharakheili 
> mailto:h.hab...@unsw.edu.au>>
> Cc: Eliot Lear mailto:l...@lear.ch>>, 
> opsawg@ietf.org 
> mailto:opsawg@ietf.org>>
> Subject: Re: [OPSAWG] Source attribution in MUD files (RFC 8520)
>
> On 2021-05-22, at 03:00, Hassan Habibi Gharakheili 
> mailto:h.hab...@unsw.edu.au>> wrote:
> >
> > If I understood correctly, the two statements (you mentioned below) are 
> > expected to be included in every published MUD profile. Right?
> >
> > That makes sense to me -- happy to help.
>
> Please do — even if you can’t put this into the files before the detailed 
> YANG syntax is agreed, please put up a LICENSE file or some such now so that 
> we can use your files in our curated repo.
>
> Grüße, Carsten
>

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[L Jean Camp]

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


On Fri, Jun 4, 2021 at 7:44 AM Carsten Bormann  wrote:

> On 2021-06-04, at 13:21, L Jean Camp  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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Source attribution in MUD files (RFC 8520)

[Hassan Habibi Gharakheili]

Done.
Please check: https://iotanalytics.unsw.edu.au/mudprofiles

Regards,
Hassan

From: Carsten Bormann 
Date: Friday, 4 June 2021 at 7:19 pm
To: Hassan Habibi Gharakheili 
Cc: Eliot Lear , opsawg@ietf.org , Ayyoob Ahamed 
Hamza 
Subject: Re: [OPSAWG] Source attribution in MUD files (RFC 8520)
On 2021-06-04, at 10:41, Hassan Habibi Gharakheili  wrote:
>
> Sure. We are happy to put up a LICENSE file in our repository 
> (https://iotanalytics.unsw.edu.au/mudprofiles).  It would be great if you 
> could provide us with a simple template of such license, or we should develop 
> one?

Licenses are like crypto algorithms: They are better developed by specialized 
individuals and heavily cross-checked before being employed.  I would go for 
OSI-approved licenses only.

> Once we put up the license, we can also augment the “systeminfo” field of 
> every MUD profile with the URL of the license.
>
> For example,
> · systeminfo: "lifxbulb",
> becomes something like this:
> · systeminfo: "lifxbulb 
> (https://iotanalytics.unsw.edu.au/mud/license.txt)",
> Your thoughts?

3.7.  systeminfo

   This is a textual UTF-8 description of the Thing to be connected.
   The intent is for administrators to be able to see a brief
   displayable description of the Thing.  It SHOULD NOT exceed 60
   characters worth of display space.

I don’t think the admins want to be bothered with this in the place where they 
expect info about the Thing.

That’s exactly why I suggested adding something to MUD.

For now, as Eliot said, an SPDX-Identifier is the easiest way to reference a 
license.  Choose between heavily used and sufficiently permissive licenses, 
e.g., 0BSD, MIT, BSD-3-Clause.  Licenses that require the copier to copy the 
copyright as well are currently a bit icky, as that copyright cannot be 
reasonably put into the MUD file yet.  0BSD and especially MIT-0 look quite 
good from this perspective.

https://spdx.org/licenses/

TL;DR:
Just copy the text at https://spdx.org/licenses/MIT-0.html (after filling in 
the variables) and place it (the whole text) on 
https://iotanalytics.unsw.edu.au/mudprofiles for now.

Grüße, Carsten


>
> Regards,
> Hassan
>
>
> From: Carsten Bormann 
> Date: Friday, 4 June 2021 at 5:04 pm
> To: Hassan Habibi Gharakheili 
> Cc: Eliot Lear , opsawg@ietf.org 
> Subject: Re: [OPSAWG] Source attribution in MUD files (RFC 8520)
>
> On 2021-05-22, at 03:00, Hassan Habibi Gharakheili  
> wrote:
> >
> > If I understood correctly, the two statements (you mentioned below) are 
> > expected to be included in every published MUD profile. Right?
> >
> > That makes sense to me -- happy to help.
>
> Please do — even if you can’t put this into the files before the detailed 
> YANG syntax is agreed, please put up a LICENSE file or some such now so that 
> we can use your files in our curated repo.
>
> Grüße, Carsten
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[L Jean Camp]

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  wrote:

> On 2021-06-04, at 13:21, L Jean Camp  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
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] RADIUS Extensions for Encrypted DNS

[Eliot Lear]

I don't think this is the right approach.  I would rather see the 
information provided in an EAP method, so that DHCP can be removed 
entirely from the equation.  Otherwise we have multiple, disparate, 
security models in play to trust the information.


Eliot

On 04.06.21 15:00, Alan DeKok wrote:

On Jun 4, 2021, at 8:13 AM, mohamed.boucad...@orange.com wrote:

(sending the message to opsawg as I understood that radext is dormant and 
related matters should be here)

   Officially alive, but in limbo.


We published this new draft as a companion document to some of the work we are 
doing in ADD WG about discovery/provisioning of encrypted DNS servers (DNS over 
TLS, DNS over HTTP, etc.): 
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/

   On quick inspection it looks reasonable.

   The one thing I noted was Encrypted-DNS-ADN TLV, which is in the DNS "compressed 
label" format.  Pretty much every other DNS name in RADIUS is in string format, not the 
compressed label.  I understand why it's done that way, but it should be called out a little more 
clearly, I think.  "note, this is not a humanly readable DNS name".

   The Encrypted-DNS names can be a little misleading.  It might be worth 
reiterating that these attributes are not encrypted as with User-Password or 
Tunnel-Password.

   It's not that the text is wrong, it's that I've seen too many implementors do the 
"obvious" thing, and not what the draft says.  So it's worth talking about the 
"obvious" thing, and explaining why it's wrong.

   But overall, I think it's a good approach.

   Alan DeKok.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg





OpenPGP_signature
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eliot Lear]

On 04.06.21 13:50, mohamed.boucad...@orange.com wrote:


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.


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:c...@tzi.org]
*Envoyé :* vendredi 4 juin 2021 12:13
*À :* BOUCADAIR Mohamed INNOV/NET 
*Cc :* Michael Richardson ; opsawg@ietf.org
*Objet :* Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing

On 4. Jun 2021, at 11:34, > > wrote:


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

_

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.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


OpenPGP_signature
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] RADIUS Extensions for Encrypted DNS

[Alan DeKok]

On Jun 4, 2021, at 8:13 AM, mohamed.boucad...@orange.com wrote:
> (sending the message to opsawg as I understood that radext is dormant and 
> related matters should be here)

  Officially alive, but in limbo.

> We published this new draft as a companion document to some of the work we 
> are doing in ADD WG about discovery/provisioning of encrypted DNS servers 
> (DNS over TLS, DNS over HTTP, etc.): 
> https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/

  On quick inspection it looks reasonable.

  The one thing I noted was Encrypted-DNS-ADN TLV, which is in the DNS 
"compressed label" format.  Pretty much every other DNS name in RADIUS is in 
string format, not the compressed label.  I understand why it's done that way, 
but it should be called out a little more clearly, I think.  "note, this is not 
a humanly readable DNS name".

  The Encrypted-DNS names can be a little misleading.  It might be worth 
reiterating that these attributes are not encrypted as with User-Password or 
Tunnel-Password.

  It's not that the text is wrong, it's that I've seen too many implementors do 
the "obvious" thing, and not what the draft says.  So it's worth talking about 
the "obvious" thing, and explaining why it's wrong.

  But overall, I think it's a good approach.

  Alan DeKok.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] RADIUS Extensions for Encrypted DNS

[mohamed.boucadair]

Hi Alan, Stefan, all,

(sending the message to opsawg as I understood that radext is dormant and 
related matters should be here)

We published this new draft as a companion document to some of the work we are 
doing in ADD WG about discovery/provisioning of encrypted DNS servers (DNS over 
TLS, DNS over HTTP, etc.): 
https://datatracker.ietf.org/doc/draft-boucadair-opsawg-add-encrypted-dns/

Your comments and suggestions are more than welcome.

Thank you.

Cheers,
Med

_

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.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[mohamed.boucadair]

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

De : Carsten Bormann [mailto:c...@tzi.org]
Envoyé : vendredi 4 juin 2021 12:13
À : BOUCADAIR Mohamed INNOV/NET 
Cc : Michael Richardson ; opsawg@ietf.org
Objet : Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing

On 4. Jun 2021, at 11:34, 
mailto:mohamed.boucad...@orange.com>> 
mailto:mohamed.boucad...@orange.com>> wrote:

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


_

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.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

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


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[L Jean Camp]

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  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
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Eliot Lear]

On 04.06.21 12:12, Carsten Bormann wrote:
On 4. Jun 2021, at 11:34, > > wrote:


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.


That's what I would want.

Eliot




OpenPGP_signature
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

On 4. Jun 2021, at 11:34,  
 wrote:
> 
> 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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Source attribution in MUD files (RFC 8520)

[Carsten Bormann]

Great!

The only other thing I could suggest is adding the line:
SPDX-License-Identifier: MIT-0

Between the word “license” and the copyright line.

Grüße, Carsten



> On 4. Jun 2021, at 12:00, Hassan Habibi Gharakheili  
> wrote:
> 
> Done.
> Please check: https://iotanalytics.unsw.edu.au/mudprofiles 
> 
>  
> Regards,
> Hassan
>  
> From: Carsten Bormann mailto:c...@tzi.org>>
> Date: Friday, 4 June 2021 at 7:19 pm
> To: Hassan Habibi Gharakheili  >
> Cc: Eliot Lear mailto:l...@lear.ch>>, opsawg@ietf.org 
>  mailto:opsawg@ietf.org>>, Ayyoob 
> Ahamed Hamza mailto:m.ahamedha...@unsw.edu.au>>
> Subject: Re: [OPSAWG] Source attribution in MUD files (RFC 8520)
> 
> On 2021-06-04, at 10:41, Hassan Habibi Gharakheili  > wrote:
> > 
> > Sure. We are happy to put up a LICENSE file in our repository 
> > (https://iotanalytics.unsw.edu.au/mudprofiles 
> > ).  It would be great if you 
> > could provide us with a simple template of such license, or we should 
> > develop one?
> 
> Licenses are like crypto algorithms: They are better developed by specialized 
> individuals and heavily cross-checked before being employed.  I would go for 
> OSI-approved licenses only.
>  
> > Once we put up the license, we can also augment the “systeminfo” field of 
> > every MUD profile with the URL of the license.
> >  
> > For example,
> > · systeminfo: "lifxbulb",
> > becomes something like this:
> > · systeminfo: "lifxbulb 
> > (https://iotanalytics.unsw.edu.au/mud/license.txt 
> > )",
> > Your thoughts?
> 
> 3.7.  systeminfo
> 
>This is a textual UTF-8 description of the Thing to be connected.
>The intent is for administrators to be able to see a brief
>displayable description of the Thing.  It SHOULD NOT exceed 60
>characters worth of display space.
> 
> I don’t think the admins want to be bothered with this in the place where 
> they expect info about the Thing.
> 
> That’s exactly why I suggested adding something to MUD.
> 
> For now, as Eliot said, an SPDX-Identifier is the easiest way to reference a 
> license.  Choose between heavily used and sufficiently permissive licenses, 
> e.g., 0BSD, MIT, BSD-3-Clause.  Licenses that require the copier to copy the 
> copyright as well are currently a bit icky, as that copyright cannot be 
> reasonably put into the MUD file yet.  0BSD and especially MIT-0 look quite 
> good from this perspective.
> 
> https://spdx.org/licenses/ 
> 
> TL;DR:
> Just copy the text at https://spdx.org/licenses/MIT-0.html 
>  (after filling in the variables) and 
> place it (the whole text) on https://iotanalytics.unsw.edu.au/mudprofiles 
>  for now.
> 
> Grüße, Carsten
> 
> 
> >  
> > Regards,
> > Hassan
> >  
> >  
> > From: Carsten Bormann mailto:c...@tzi.org>>
> > Date: Friday, 4 June 2021 at 5:04 pm
> > To: Hassan Habibi Gharakheili  > >
> > Cc: Eliot Lear mailto:l...@lear.ch>>, opsawg@ietf.org 
> >  mailto:opsawg@ietf.org>>
> > Subject: Re: [OPSAWG] Source attribution in MUD files (RFC 8520)
> > 
> > On 2021-05-22, at 03:00, Hassan Habibi Gharakheili  > > wrote:
> > > 
> > > If I understood correctly, the two statements (you mentioned below) are 
> > > expected to be included in every published MUD profile. Right?
> > > 
> > > That makes sense to me -- happy to help.
> > 
> > Please do — even if you can’t put this into the files before the detailed 
> > YANG syntax is agreed, please put up a LICENSE file or some such now so 
> > that we can use your files in our curated repo.
> > 
> > Grüße, Carsten
> > 
> 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[mohamed.boucadair]

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:c...@tzi.org]
> Envoyé : vendredi 4 juin 2021 08:53
> À : BOUCADAIR Mohamed INNOV/NET 
> Cc : Michael Richardson ; opsawg@ietf.org
> Objet : Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing
> 
> On 2021-05-31, at 10:10, mohamed.boucad...@orange.com 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


_

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.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Source attribution in MUD files (RFC 8520)

[Carsten Bormann]

On 2021-06-04, at 10:41, Hassan Habibi Gharakheili  wrote:
> 
> Sure. We are happy to put up a LICENSE file in our repository 
> (https://iotanalytics.unsw.edu.au/mudprofiles).  It would be great if you 
> could provide us with a simple template of such license, or we should develop 
> one?

Licenses are like crypto algorithms: They are better developed by specialized 
individuals and heavily cross-checked before being employed.  I would go for 
OSI-approved licenses only.
 
> Once we put up the license, we can also augment the “systeminfo” field of 
> every MUD profile with the URL of the license.
>  
> For example,
> · systeminfo: "lifxbulb",
> becomes something like this:
> · systeminfo: "lifxbulb 
> (https://iotanalytics.unsw.edu.au/mud/license.txt)",
> Your thoughts?

3.7.  systeminfo

   This is a textual UTF-8 description of the Thing to be connected.
   The intent is for administrators to be able to see a brief
   displayable description of the Thing.  It SHOULD NOT exceed 60
   characters worth of display space.

I don’t think the admins want to be bothered with this in the place where they 
expect info about the Thing.

That’s exactly why I suggested adding something to MUD.

For now, as Eliot said, an SPDX-Identifier is the easiest way to reference a 
license.  Choose between heavily used and sufficiently permissive licenses, 
e.g., 0BSD, MIT, BSD-3-Clause.  Licenses that require the copier to copy the 
copyright as well are currently a bit icky, as that copyright cannot be 
reasonably put into the MUD file yet.  0BSD and especially MIT-0 look quite 
good from this perspective.

https://spdx.org/licenses/

TL;DR:
Just copy the text at https://spdx.org/licenses/MIT-0.html (after filling in 
the variables) and place it (the whole text) on 
https://iotanalytics.unsw.edu.au/mudprofiles for now.

Grüße, Carsten


>  
> Regards,
> Hassan
>  
>  
> From: Carsten Bormann 
> Date: Friday, 4 June 2021 at 5:04 pm
> To: Hassan Habibi Gharakheili 
> Cc: Eliot Lear , opsawg@ietf.org 
> Subject: Re: [OPSAWG] Source attribution in MUD files (RFC 8520)
> 
> On 2021-05-22, at 03:00, Hassan Habibi Gharakheili  
> wrote:
> > 
> > If I understood correctly, the two statements (you mentioned below) are 
> > expected to be included in every published MUD profile. Right?
> > 
> > That makes sense to me -- happy to help.
> 
> Please do — even if you can’t put this into the files before the detailed 
> YANG syntax is agreed, please put up a LICENSE file or some such now so that 
> we can use your files in our curated repo.
> 
> Grüße, Carsten
> 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Source attribution in MUD files (RFC 8520)

[Eliot Lear]

Hassan, why not trying out one of the SPDX licensing tags, a'la:

"|SPDX-License-Identifier: |0BSD".

See https://spdx.org/licenses/ and pick one you like.



On 04.06.21 10:41, Hassan Habibi Gharakheili wrote:


Sure. We are happy to put up a LICENSE file in our repository 
(https://iotanalytics.unsw.edu.au/mudprofiles 
). It would be great if 
you could provide us with a simple template of such license, or we 
should develop one?


Once we put up the license, we can also augment the “systeminfo” field 
of every MUD profile with the URL of the license.


For example,

·*systeminfo*: "lifxbulb",

becomes something like this:

·*systeminfo*: "lifxbulb 
(https://iotanalytics.unsw.edu.au/mud/license.txt)",


Your thoughts?

Regards,

Hassan

*From: *Carsten Bormann 
*Date: *Friday, 4 June 2021 at 5:04 pm
*To: *Hassan Habibi Gharakheili 
*Cc: *Eliot Lear , opsawg@ietf.org 
*Subject: *Re: [OPSAWG] Source attribution in MUD files (RFC 8520)

On 2021-05-22, at 03:00, Hassan Habibi Gharakheili 
 wrote:

>
> If I understood correctly, the two statements (you mentioned below) 
are expected to be included in every published MUD profile. Right?

>
> That makes sense to me -- happy to help.

Please do — even if you can’t put this into the files before the 
detailed YANG syntax is agreed, please put up a LICENSE file or some 
such now so that we can use your files in our curated repo.


Grüße, Carsten



OpenPGP_signature
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Source attribution in MUD files (RFC 8520)

[Hassan Habibi Gharakheili]

Sure. We are happy to put up a LICENSE file in our repository 
(https://iotanalytics.unsw.edu.au/mudprofiles).  It would be great if you could 
provide us with a simple template of such license, or we should develop one?

Once we put up the license, we can also augment the “systeminfo” field of every 
MUD profile with the URL of the license.

For example,
· systeminfo: "lifxbulb",
becomes something like this:
· systeminfo: "lifxbulb 
(https://iotanalytics.unsw.edu.au/mud/license.txt)",
Your thoughts?

Regards,
Hassan


From: Carsten Bormann 
Date: Friday, 4 June 2021 at 5:04 pm
To: Hassan Habibi Gharakheili 
Cc: Eliot Lear , opsawg@ietf.org 
Subject: Re: [OPSAWG] Source attribution in MUD files (RFC 8520)
On 2021-05-22, at 03:00, Hassan Habibi Gharakheili  wrote:
>
> If I understood correctly, the two statements (you mentioned below) are 
> expected to be included in every published MUD profile. Right?
>
> That makes sense to me -- happy to help.

Please do — even if you can’t put this into the files before the detailed YANG 
syntax is agreed, please put up a LICENSE file or some such now so that we can 
use your files in our curated repo.

Grüße, Carsten
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] LxNM Design Team -- Minutes

[SAMIER BARGUIL GIRALDO]

Dear OPSAWG,

Please find the link of the minutes of the desing team: 
https://codimd.ietf.org/40Dw-yCkQoONcMsYp8e5XQ?both

The latest sesion minutes:

Date: 3-06-2021
Participants

 *   Erez Segev
 *   Raul Arco
 *   Luis Muñoz
 *   Mohamed Boucadair
 *   Oscar Gonzalez de dios
 *   Samier Barguil

Discussion

 *   Merge the pull request 
ESI-284 to support:
*   ESI types
*   DF election method
*   ESI as part of the EVPN Service attributes.
 *   Close the issue 239 
based on the lastest comments of the group. The limit should be at the 
Application layer and outside the scope of the model. We close the issue. 
Roque, if you disagree, please reopen the issue.
 *   Close the isse 237, 
This is part of the network creation.
 *   Review the issue 
301.
*   Erez suggest to simplify the sctructure and remove the Id of the 
VPN Targets.
*   Med suggests to keep it as part of the model and its extensibility.
*   Samier explains the possible usage of VPN targets as boolean 
operators.
*   The action point 1 has been cretaed to explain the usage.
 *   Review the issue 
299. We need to think to 
restructure the connection to be aligned with the one in the L3NM.
*   The L2NM connection container needs to be restructured. The 
“physical-interface” container has information about the speed port, etc. The 
impression is that the configuration of the physical interface impacts 
different services. Hence, L2NM might not be the best place to manage the 
phisycal interface. It is included as it was defined in L2SM
*   L2SM defined:

5.3.2.2.1.  Untagged Interface

   For each untagged interface (untagged-interface), there are basic
   configuration parameters like interface index and speed, interface
   MTU, auto-negotiation and flow-control settings, etc.  In addition,
   and based on mutual agreement, the customer and provider may decide
   to enable advanced features, such as LLDP, IEEE 802.3ah
   [IEEE-802-3ah], or MAC loop detection/prevention at a UNI.  If loop
   avoidance is required, the attribute "uni-loop-prevention" must be
   set to "true".
The advance features shown in L2SM are applicable to both tagged and untagged 
interfaces, so in L2NM, they can be handled separately.


 *   We believe the configuration of physical parameters belongs to the 
interface model and its an action to do in the network creation phase.

Action Points

 *   @Samier create a text to explain the possible usage of the Id under 
the VPN Targets.


Samier Barguil


De: SAMIER BARGUIL GIRALDO 
Enviado: viernes, 30 de abril de 2021 11:48
Para: opsawg@ietf.org 
Cc: Oscar González de Dios 
Asunto: LxNM Design Team -- Minutes

Dear OPSAWG,

The notes of the last design meeting:
Date: 29-04-2021
Participants

 *   Raul Arco
 *   Sergio Belloti
 *   Luis Angel Muñoz
 *   Erez Segev
 *   Mohamed Boucadair
 *   Victor Lopez
 *   Oscar Gonzalez de dios
 *   Samier Barguil

Agenda

 *   Possible Scenarios for the EVPN and the L2NM.
 *   Review the open pull request on the repo.
 *   @Raul has prepared three possible scenarios.

Discussion

 *   The draft expires next week. @Med has prepared a new version to submit.

 *   Review the open pull request on the repo.
– #289: Add VRRP virtual 
address.
 *   Review the latest open issues in the repo.
*   – #288: VPN-ID 
under EVPN-BGP. It is a leaf reference to the service, and the mapping is 1:1, 
so we agree to remove it.
*   – #287: 
Extranets VPNs.
*   – #286: 
Redundancy information. Med has grouped all the redundancy related attributes 
in a shared container.
*   – #283: 
Factorization of data nodes.
 *   Review the possible EVPN implementation scenarios studied by Raul.

Action Points

 *   @Med would like the review of 
#289 and accept the changes.
 *   The work is required to evaluate possible redundancy scenarios 
#286.
 *   Update the service-VPN-id by parent-service-id to provide 

Re: [OPSAWG] Source attribution in MUD files (RFC 8520)

[Carsten Bormann]

On 2021-05-22, at 03:00, Hassan Habibi Gharakheili  wrote:
> 
> If I understood correctly, the two statements (you mentioned below) are 
> expected to be included in every published MUD profile. Right?
> 
> That makes sense to me -- happy to help.

Please do — even if you can’t put this into the files before the detailed YANG 
syntax is agreed, please put up a LICENSE file or some such now so that we can 
use your files in our curated repo.

Grüße, Carsten

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Carsten Bormann]

On 2021-05-31, at 10:10, mohamed.boucad...@orange.com 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

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg