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

Andy Bierman <andy@yumaworks.com> Thu, 07 November 2019 15:58 UTC

Return-Path: <andy@yumaworks.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 DCEF812093F for <netmod@ietfa.amsl.com>; Thu, 7 Nov 2019 07:58:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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=yumaworks-com.20150623.gappssmtp.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 UlgfUVTXD-AT for <netmod@ietfa.amsl.com>; Thu, 7 Nov 2019 07:58:01 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 3BBD612095B for <netmod@ietf.org>; Thu, 7 Nov 2019 07:58:01 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id q28so1994848lfa.5 for <netmod@ietf.org>; Thu, 07 Nov 2019 07:58:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=70DGSP6vTTUPOKCig5uUqlXb/dU15LTWURQSBH9ALqk=; b=R5WbGTCfh4T9XYBtFlc0T9tuwLgMo+h3uWAgnRET2/dP4n/jhRSjSGVw9y7Fkh/mS3 dawEdYE++lji9b+joM3PWftHAtugVPwl45ueL4vvrPmzxLVzFgPYRXJpuEFV5IkOsdCw ksgqFcPkD7H3OVwZ1qGqyS0tGEaB+NY3d/gvThfjZFMHmxIEE/JnoISfeK7LruC0Bkcu IBS0mz67UT+Oy2lsjZWK5PpFcUNCA+NXmOYgti2WqE1+w/eetMRLqs1Q5HKbQ0d3EZm5 ozCsBwolJA7OeBoNqME2Ccsy2u6/J/d01hHHWpQbrvIok235/KcmDDJWoPste91OCvT7 cFbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=70DGSP6vTTUPOKCig5uUqlXb/dU15LTWURQSBH9ALqk=; b=QIlvNy5FJCLxrP3eM51/cUG3I8dvfZerHlSYIpykCd63D4y20HIMqfNSQeEN47su6D 3p4zGwZQICYOo3CfRER3YBJW1ZJslbg3jqB1WBWN6nBXFB1NHyDx+TGVTp/5xB6ZpaZf PX/f7FTMvO+Ej3POdQdk3m+F5ZMWUt/yTI+u0Rf2szsH2UIm+6tv39em2BZX8c4pR/mu PaFDojzDv1ec/+DSyTKxwKbiAkVC0BM+q0ih5aGh098e2CbFxwLucJuSGCBzul3w1oLs a5Tv6R2hsax8Ob8LAZnXzKK1ONqGYsAn4OH0F8BTeIuzkllxqo2J1M7c40qxZAbAkmMW bxtw==
X-Gm-Message-State: APjAAAW/zdhxjwfBYdVkKGsNQ4/dnPlEwr3XbG79KVxqKv1Ozw+v2ChP AIq/sZ3gBdwR2DvlvKSJS6pVI90HwsexCpocxUKUxQ==
X-Google-Smtp-Source: APXvYqzB48FXaVLkMnqjOUzbTEG/SWe2SxBchj3c1Yeupx6D0wsQYZFDsGU2gT2MtzoozuO9XJGihXZVWUw95KeXOZs=
X-Received: by 2002:ac2:5612:: with SMTP id v18mr2961403lfd.33.1573142279226; Thu, 07 Nov 2019 07:57:59 -0800 (PST)
MIME-Version: 1.0
References: <CABCOCHShFd41gcGLTSjJQMWCA4Ak_QX2iHpng_6DBqLRf23vqw@mail.gmail.com> <AM7PR07MB62148A605167BD4D046A2E3DF0790@AM7PR07MB6214.eurprd07.prod.outlook.com> <CABCOCHT0G+4zT2ApvRA1rgO3j4BR0gEbeiP4XDWV0nq4rxjxGQ@mail.gmail.com> <20191107.092440.1454377708605915338.mbj@tail-f.com>
In-Reply-To: <20191107.092440.1454377708605915338.mbj@tail-f.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 07 Nov 2019 07:57:48 -0800
Message-ID: <CABCOCHSmknTvCXK4e+3Oz2JRR6SNi7zQgj9L3=fxgK2KEBmTOg@mail.gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Balazs Lengyel <balazs.lengyel@ericsson.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bc31c80596c3ba33"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/RtgiO8NS4ymruk_pQckAIbqffCY>
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 15:58:12 -0000

On Thu, Nov 7, 2019 at 12:25 AM Martin Bjorklund <mbj@tail-f.com> wrote:

> 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'.
>
>

OK -- much worse than I thought...


> > 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.
>
>

It seems strange that the details that don't matter at all (like the
filename) have lots
of rules that MUST be followed and the details that actually add standards
value are left unspecified.


>
> /martin
>
>

Andy


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