Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

Martin Bjorklund <mbj@tail-f.com> Thu, 07 November 2019 08:25 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB025120122 for <netmod@ietfa.amsl.com>; Thu, 7 Nov 2019 00:25:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tkPzWoxuIY-x for <netmod@ietfa.amsl.com>; Thu, 7 Nov 2019 00:25:11 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 22B3912004F for <netmod@ietf.org>; Thu, 7 Nov 2019 00:25:11 -0800 (PST)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 9F7701AE0389; Thu, 7 Nov 2019 09:25:09 +0100 (CET)
Date: Thu, 07 Nov 2019 09:24:40 +0100 (CET)
Message-Id: <20191107.092440.1454377708605915338.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: balazs.lengyel@ericsson.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHT0G+4zT2ApvRA1rgO3j4BR0gEbeiP4XDWV0nq4rxjxGQ@mail.gmail.com>
References: <CABCOCHShFd41gcGLTSjJQMWCA4Ak_QX2iHpng_6DBqLRf23vqw@mail.gmail.com> <AM7PR07MB62148A605167BD4D046A2E3DF0790@AM7PR07MB6214.eurprd07.prod.outlook.com> <CABCOCHT0G+4zT2ApvRA1rgO3j4BR0gEbeiP4XDWV0nq4rxjxGQ@mail.gmail.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Qq6wGxU6GJOulzygxjvxpJfJehk>
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 08:25:13 -0000

Andy Bierman <andy@yumaworks.com>; wrote:
> On Wed, Nov 6, 2019 at 2:40 PM Balázs Lengyel <balazs.lengyel@ericsson.com>;
> wrote:
> 
> > See below!    Balazs
> >
> >
> >
> > *From:* netmod <netmod-bounces@ietf.org>; *On Behalf Of *Andy Bierman
> > *Sent:* 2019. október 10., csütörtök 17:34
> > *To:* Martin Bjorklund <mbj@tail-f.com>;
> > *Cc:* NetMod WG <netmod@ietf.org>;
> > *Subject:* Re: [netmod] comments on
> > draft-ietf-netmod-yang-instance-file-format-04
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund <mbj@tail-f.com>; wrote:

[...]

> >   o  Data node naming.
> >
> >     The current structure of the model is:
> >
> >         +--rw (content-schema-spec)?
> >         |  +--:(simplified-inline)
> >         |     +--rw module*                 string
> >         |  +--:(inline)
> >         |  |  +--rw inline-spec*            string
> >         |  |  +--rw inline-content-schema   <anydata>
> >         |  +--:(uri)
> >         |     +--rw schema-uri?           inet:uri
> >         ...
> >         +--rw content-data?         <anydata>
> >
> >
> >     To make the instance document more understandable, I suggest the
> >     following structure, which adds a wrapping container for the
> >     schema, and renames the inline and uri nodes:
> >
> >         +--rw content-schema
> >            +--rw (content-schema-spec)?
> >            |  +--:(simplified-inline)
> >            |     +--rw module*                 string
> >            |  +--:(inline)
> >            |  |  +--rw inline-module*          string
> >            |  |  +--rw inline-schema           <anydata>
> >            |  +--:(uri)
> >            |     +--rw same-schema-as-file?    inet:uri
> >         ...
> >         +--rw content-data?         <anydata>
> >
> >
> >
> > +1, except not in favor of so many ways to specify schema.
> >
> > That means the file reader MUST support all of them.
> >
> >
> >
> > BALAZS: All 3 formats have been explicitly requested by earlier
> > commenters. I see a rational for each:
> >
> > Simplified-inline: it is simple and usually enough
> >
> > Inline: if you need to specify not just the modules but also the supported
> > features and deviations you need this full format
> >
> > Uri: if you don’t really want to specify the content-schema in detail,
> > e.g., because you are generating many files with the same schema, all you
> > need is reference that identifies the content-schema
> >
> >
> >
> > Which one would you like to implementing? Maybe we could make the inline
> > method optional with a feature (feature if-feature),
> >
> >
> >
> 
> I will just deviate out the stuff not worth implementing. ;-)
> I prefer the schema-uri approach but simplified-inline is probably easiest
> to implement.
> 
> The schema-uri looks standard but the contents of the referenced YANG
> instance file can be
> anything (as opposed to a pre-defined YANG template like /yang-library).

Note that the name of this leaf is misleading (see my ealrier
comments).  It is really 'same-schema-as-file', which means that it
point to another YANG instance data file, which must specify its
schema in one of the three ways.  Which may be another schema-uri, but
in the end the recursion must stop and you must find a YANG instance
data file that usses 'simplified-inline' or 'inline'.

> The inline-content-schema object looks broken because a YANG file is a text
> string.

It is supposed to be data nodes for /yang-library or perhaps
/module-sets, or perhaps something else.  See the examples in section
3.2.


/martin


> How does one use anydata to encode a text string? (It must be a container
> of YANG data nodes).
> Even the YIN representation is not a set of YANG data nodes, so anydata
> encoding seems wrong.
> Including all the YANG modules in this file seems especially heavyweight.
> (I have no intention of supporting this mode.)
> 
> 
> 
> > Andy
> >
> 
> 
> Andy
> 
> 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >