Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt

<mohamed.boucadair@orange.com> Wed, 24 January 2018 11:54 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 D108D12DA2C for <opsawg@ietfa.amsl.com>; Wed, 24 Jan 2018 03:54:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 4ROiqnE9CJkS for <opsawg@ietfa.amsl.com>; Wed, 24 Jan 2018 03:54:31 -0800 (PST)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FC4120454 for <opsawg@ietf.org>; Wed, 24 Jan 2018 03:54:31 -0800 (PST)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id C120D1013D3; Wed, 24 Jan 2018 12:54:29 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 8DC5240069; Wed, 24 Jan 2018 12:54:29 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0382.000; Wed, 24 Jan 2018 12:54:29 +0100
From: mohamed.boucadair@orange.com
To: Eliot Lear <lear@cisco.com>
CC: Mahesh Jethanandani <mjethanandani@gmail.com>, "opsawg@ietf.org" <opsawg@ietf.org>, Mark Nottingham <mnot@mnot.net>, "Saswat Praharaj (saspraha)" <saspraha@cisco.com>
Thread-Topic: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt
Thread-Index: AQHTlO4ijwfw7fdn00+sxY/M7KbCAqOCvqXQ///8YYCAABDhAA==
Date: Wed, 24 Jan 2018 11:54:29 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A0C612A@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <151678258073.24096.1546664821566754428@ietfa.amsl.com> <74177d27-9a95-c791-db77-be5bafee957d@cisco.com> <787AE7BB302AE849A7480A190F8B93300A0C5FDD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <f3706db8-1dcf-1efa-5f4b-746166ae97e4@cisco.com>
In-Reply-To: <f3706db8-1dcf-1efa-5f4b-746166ae97e4@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.4]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0C612AOPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/dzeWwRlD-X9yKEnY8w5pZjU7ou0>
Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 24 Jan 2018 11:54:34 -0000

Re-,

Thank you Eliot for the prompt follow-up.

Please see some comments inline.

Cheers,
Med

De : Eliot Lear [mailto:lear@cisco.com]
Envoyé : mercredi 24 janvier 2018 11:05
À : BOUCADAIR Mohamed IMT/OLN
Cc : Mahesh Jethanandani; opsawg@ietf.org; Mark Nottingham; Saswat Praharaj (saspraha)
Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt


Hi Med,

On 24.01.18 10:52, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:
Hi Eliot,


Some quick comments:

* Please note that "acl-type" should be “type” and "rule-name" should be changed to “name”. This can be easily fixed in the examples.

My understanding from draft-ietf-netmod-acl-model-14 is that acl-type remains acl-type.  acl-name became name.  But you're right- rule-name became name as well.  I will adjust the text accordingly.
[Med] I guess you meant -15. I confirm that acl-type is to be changed too. Below an excerpt of the acl tree structure:

     +--rw access-lists
        +--rw acl* [name]
        |  +--rw name    string
        |  +--rw type?   acl-type


* This sentence should be carefully updated as well: “With the exceptions of "name", "acl-type", "rule-name", and TCP and”.

* I guess the examples should be checked to align with the new ACL structure. For example,

 - “ipv6-acl” entries should be updated to “ipv6”.

Which is the text I adjusted ;-)
[Med] Yes. I was referring to the examples.


 - add “l3” entry before “ipv4” and “ipv6”.

I think this is done in the normative text but you're right- it needs to be corrected in the examples.



* It would useful to add a justification why it is not recommended to support 'reject' action.

Ok, I'll add some text.

[Med] Thank you. BTW, wouldn’t you need a rate-limit action to “protect” against exhausting Thing resources?

If so, feel free to grab from the following:


==

   augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" +
           "/ietf-acl:ace/ietf-acl:actions" {
     description
       "Augments ACL module with a rate-limit action.";
     leaf rate-limit {

       when "derived-from-or-self(/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/" +
            "ietf-acl:ace/ietf-acl:actions/ietf-acl:forwarding, 'ietf-acl:accept')";
       type decimal64 {
         fraction-digits 2;
       }
      description
        "rate-limit traffic. This action is valid only when accept action is used.";
      }
   }
==


* Unless I’m mistaken, the mud use case does not require the support of interfaces as an attachment point. It may be useful to add something among those lines:

   Given that MUD does not deal with interfaces, the
   support of the "ietf-interfaces" module [RFC7223<https://tools.ietf.org/html/rfc7223>] is not
   required. Specifically, the support of interface-related
   features and branches (e.g., interface-attachment and interface-stats)
   of the ACL YANG module is not required.

ok.


In addition, I have received the following requests for data elements to be added to the core model:

  *   Manufacturer-Name
  *   Device-Type
  *   Model-Number
  *   Software-version

Unless I hear objections, I am disposed to add these as non-mandatory leaf-nodes as strings underneath the top-level MUD object.

Eliot




Cheers,

Med

De : OPSAWG [mailto:opsawg-bounces@ietf.org] De la part de Eliot Lear
Envoyé : mercredi 24 janvier 2018 09:34
Cc : Mahesh Jethanandani; opsawg@ietf.org<mailto:opsawg@ietf.org>; Mark Nottingham
Objet : Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-14.txt


This update primarily focuses on two elements that were agreed during WGLC:

  *   The update to the ACL model.  That update has taken longer than I would have liked, but it is now at least close to finished.  Note: the MUD model does not yet match the published ACL model, but it does match the agreed changes that will be produced in the next ACL draft.
  *   Mark Nottingham had commented that it is not appropriate to have versioning information in the MUD-URL itself, but that it should be in the model.  We agreed on this change, as well as some wording around how HTTP is handled.

Based on these changes, I would like to move this document forward to IETF LC.

Eliot

On 24.01.18 09:29, internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> wrote:



A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Operations and Management Area Working Group WG of the IETF.



        Title           : Manufacturer Usage Description Specification

        Authors         : Eliot Lear

                          Ralph Droms

                          Dan Romascanu

 Filename        : draft-ietf-opsawg-mud-14.txt

 Pages           : 56

 Date            : 2018-01-24



Abstract:

   This memo specifies a component-based architecture for manufacturer

   usage descriptions (MUD).  The goal of MUD is to provide a means for

   Things to signal to the network what sort of access and network

   functionality they require to properly function.  The initial focus

   is on access control.  Later work can delve into other aspects.



   This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an

   LLDP TLV, a URL suffix specification, an X.509 certificate extension

   and a means to sign and verify the descriptions.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-opsawg-mud-14

https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-14



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-14





Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

OPSAWG mailing list

OPSAWG@ietf.org<mailto:OPSAWG@ietf.org>

https://www.ietf.org/mailman/listinfo/opsawg