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

mohamed.boucadair@orange.com Fri, 28 May 2021 09:18 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627393A219B for <opsawg@ietfa.amsl.com>; Fri, 28 May 2021 02:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v26JtO81st21 for <opsawg@ietfa.amsl.com>; Fri, 28 May 2021 02:18:13 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89F43A218E for <opsawg@ietf.org>; Fri, 28 May 2021 02:18:12 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 4Frzcc53m8z5xVC; Fri, 28 May 2021 11:18:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1622193488; bh=OoCBebGq4ZsThkihSiEMAT8L4UpVyGdu72Or8fK5V0Y=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kYBOHSscewXW9+99zitRNM3suM0uz6pD+bhsFMU4ODZOKBGnvSs3xqQ1mNKjWtdeH VAslzDjA9s1Eff0Gb/nlK28id7M3Etx9a5P95mRpcDdKkp/MU2LIhKu6f7CbcLdWPc 0HzS1ePHIoQJ7bCbADiDljKkyT/D0sQ69A1koGlgkTzyxdSKRpGU6IAa+Q+Yq3bN43 lwuXKGX4Ft7ElB6+Hr48rPF2Lmy2FIVorMA8CGSxHjPSUPA/CBZe2sjdTpO2EQgOqW l4A4VKG6O2bh3DioJsinW3xLrsMIGFYDHGGlJ/mgNaH9nzCSc9a3xC7BiPCP0K04Jw AJwXYeHBlX/7g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4Frzcc4QVhz8sYt; Fri, 28 May 2021 11:18:08 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Eliot Lear <lear@lear.ch>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: [OPSAWG] please see draft-lear-opsawg-ol on licensing
Thread-Index: AQHXUt+y++eYI4gOQU6/qboAEWBSIKr4kFxA
Date: Fri, 28 May 2021 09:18:07 +0000
Message-ID: <13971_1622193488_60B0B550_13971_295_1_787AE7BB302AE849A7480A190F8B93303539075F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <340b29f4-e867-6a5d-b45c-8c8b9e45eb47@lear.ch>
In-Reply-To: <340b29f4-e867-6a5d-b45c-8c8b9e45eb47@lear.ch>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/R6NwXAolghXPXu5K1OOjPgTDSUE>
Subject: Re: [OPSAWG] please see draft-lear-opsawg-ol on licensing
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 09:18:17 -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": [
           "Copyright (c) FrobMaster 2021. All Rights Reserved"
         ],
         "spdx-tag": "0BSD"
       },

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

(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:opsawg-bounces@ietf.org] De la part de Eliot Lear
> Envoyé : jeudi 27 mai 2021 12:04
> À : opsawg@ietf.org
> Cc : netmod WG <netmod@ietf.org>
> 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
> doctors would like to take a look. We'd like to move on this one
> quickly.
> 
> Eliot
> 


_________________________________________________________________________________________________________________________

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.