Re: [yang-doctors] Yangdoctors early review of draft-ietf-opsawg-mud-08

Martin Bjorklund <mbj@tail-f.com> Thu, 24 August 2017 07:13 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8864D132BE7; Thu, 24 Aug 2017 00:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 42i0uv4smUjt; Thu, 24 Aug 2017 00:12:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 26EE4132B9F; Thu, 24 Aug 2017 00:12:59 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 311C71AE033A; Thu, 24 Aug 2017 09:12:58 +0200 (CEST)
Date: Thu, 24 Aug 2017 09:11:30 +0200
Message-Id: <20170824.091130.889626202711647501.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: yang-doctors@ietf.org, draft-ietf-opsawg-mud.all@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHQznpgCYssekPz+-EjST13tisrdeuv_k6PppW0XpONA0w@mail.gmail.com>
References: <150340909415.6001.14045177084948571272@ietfa.amsl.com> <20170823.100659.305891042923397070.mbj@tail-f.com> <CABCOCHQznpgCYssekPz+-EjST13tisrdeuv_k6PppW0XpONA0w@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/QBvtoOtrVUFrBCBMzVsPeSOdE6A>
Subject: Re: [yang-doctors] Yangdoctors early review of draft-ietf-opsawg-mud-08
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Aug 2017 07:13:01 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Aug 23, 2017 at 1:06 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> > Hi,
> >
> > I would like to direct the YANG doctors attention to one design choice
> > in this document:
> >
> > The document defines a normal "config true" data model, but this data
> > model is not intended to be implemented by a server, but rather it
> > defines the file format of a "MUD file".
> >
> > This idea is not new, it is used e.g. in the anima voucher document.
> > Normally, we would require that they use "rc:yang-data" to define such
> > a structure.
> >
> > However, the MUD file is supposed to contain some top-level nodes
> > defined in the MUD YANG module, and also some /acl:access-lists
> > nodes.  So even if the MUD document could define a rc:yang-data
> > structure for the top-level nodes defined in the MUD document, it
> > cannot get the access lists into this rc:yang-data structure.
> >
> > So the question to the YANG doctors is if this is ok, or if there is a
> > better way to define this file format.
> >
> >
> Why is it a problem to use a grouping in rc:yang-data?

That's not the issue here - I agree it is perfectly fine to use a
grouping in yang-data.

The issue is that they would like to define a file format that
contains "/acl:access-lists" nodes.  The acl module is NOT defined as
a grouping or anything.


> This clearly needs to be rc:yang-data, not a real module with config=true
> objects.
> I think the artifact can contain data that matches the structure of config
> data.

Not sure I follow this.  They would like to re-use the definition of
access lists in ietf-access-control-list.  But they want this data in
a file.

> It is an implementation detail to convert the artifact to config data in a
> datastore.

Yes, this part is actually clear in their draft.


/martin