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

Andy Bierman <andy@yumaworks.com> Wed, 06 November 2019 23:15 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 01E3B120180 for <netmod@ietfa.amsl.com>; Wed, 6 Nov 2019 15:15:13 -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, 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] 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 EZ-tJUQ2xORz for <netmod@ietfa.amsl.com>; Wed, 6 Nov 2019 15:15:10 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 79210120052 for <netmod@ietf.org>; Wed, 6 Nov 2019 15:15:09 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id k15so95706lja.3 for <netmod@ietf.org>; Wed, 06 Nov 2019 15:15:09 -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=Pvyd96XMNK2cL1Il0/avHeUb7waNolcM4FtTcHUAoAA=; b=xV75fwaaiX7fmG570a7IsW7jP8lEHi1eRt0oouwGRaJwvG2vVpUfwhuZra6/Wmdt9V xlRL70k5iTXQzaRM8eGx9Q/AsUYzjm5lnz74yl1M4pVeN68QRQUIdlze+XwGbUnNieDo q9Hsl/IUeEsY8BaqAuG80dI47ly5cLiN2N1R0UI+HIsbHZIXOTp0uE0rHLT4U4B24uTS KSYdBYqtUlou7x/fOt4K+wVAf+MWMe6wkvqRZAPSg7JwTJFmklLyhg9gmV2WZej4P8Pi HAkCRd4O63aNx9g3FrH1v/VnMl5u1AI7tVaYy0sZnGK29Xd5PKoZBeUpw6/wawaiV+ZQ hdNw==
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=Pvyd96XMNK2cL1Il0/avHeUb7waNolcM4FtTcHUAoAA=; b=dDmi8bJ7dmya6225D0AlyzQjTDDxnh1aJPeX7+L476/yCktByZMOy/Ora7tkselhQF 6XNiV3svXIrVIhevdGQflv1pNDBHAY4zA+KkF7YiXVQOrn9NGV+33+f0+6blauU2Huo3 XuG3S1H5t8wYQtUJKSVnUz9xQ//oaIY0jwE+STvmHSEJKIttCUzpQuawDtYKOx/AX4Uy +4VQMeOtrlBOe8AlUTnEx4herpBGQF3LZp4ccF/0nRdWHcjDiC8Dh1SyyvivWMLm7Ywn OKctWotXVIHJxgf3kdCWPb2x54KAhNp1+1lQMfWvsnjBlkg/8U2haF5+w3v1ad172cWg Au2A==
X-Gm-Message-State: APjAAAVkMfbC7c+FlKtXiYgCYT98mXqD9S9UWxWF5RlQmN3Q8LeF3wnZ c8T2kAMnCX8FhAE9b6fR7Yeufnb8mTGoKWx5ISfmCg==
X-Google-Smtp-Source: APXvYqwGwlFEO00e6rHrbrgk7J1iLqu7LSAgY949ntFInQi7Xg12F0N3HdBDVzVCeXfVdzWER3i5FfVM7u9Qanm+7E4=
X-Received: by 2002:a2e:7319:: with SMTP id o25mr3306773ljc.207.1573082107404; Wed, 06 Nov 2019 15:15:07 -0800 (PST)
MIME-Version: 1.0
References: <20191010.140525.904627955349075516.mbj@tail-f.com> <CABCOCHShFd41gcGLTSjJQMWCA4Ak_QX2iHpng_6DBqLRf23vqw@mail.gmail.com> <AM7PR07MB62148A605167BD4D046A2E3DF0790@AM7PR07MB6214.eurprd07.prod.outlook.com>
In-Reply-To: <AM7PR07MB62148A605167BD4D046A2E3DF0790@AM7PR07MB6214.eurprd07.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 6 Nov 2019 15:14:56 -0800
Message-ID: <CABCOCHT0G+4zT2ApvRA1rgO3j4BR0gEbeiP4XDWV0nq4rxjxGQ@mail.gmail.com>
To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= <balazs.lengyel@ericsson.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000036f6180596b5b81f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FrQIpFLe_5xliREF6V9Wq9qc6Ok>
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: Wed, 06 Nov 2019 23:15:13 -0000

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  leaf-list module
>
>     The type of this leaf-list is a string with:
>
>       pattern '.+@\d{4}-\d{2}-\d{2}\.yang';;
>
>     I think the revision needs to be optional, and the suffix ".yang"
>     dropped, since it doesn't add any value:
>
>       pattern '.+(@\d{4}-\d{2}-\d{2})?';
>
>    (same for inline-spec).
>
>
>
> IMO the filespec SHOULD follow the pattern in
> https://tools.ietf.org/html/rfc7950#section-5.2
>
> BALAZS: It does follow the pattern except that I made the revision date
> mandatory. It is needed to properly understand the instance data.
>
>
>

The representation (.yang vs .yin) is not relevant here.
Revision statements are optional in a YANG module, so what fake date string
do you
use if the module has no revision?  Seems prudent to make the date-string
optional in the filename.

Except a new file extension SHOULD be used.
>
> Suggest: .yif == YANG Instance File
>
>
>
> Obviously it would be a horrible idea to use .yang since that extension
>
> is already used to identify a YANG schema file.
>
> BALAZS: The leaf-list lists not the instance data files but the content
> defining YANG modules, so IMO “.yang” is an appropriate extension. It is
> really a YANG schema file we are listing.
>
>
>
I confused this file with names of modules in the data.
IMO it would be useful to have an extension for XML and JSON representations
of a YANG instance file, but we can leave that out of the standard.


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

The inline-content-schema object looks broken because a YANG file is a text
string.
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
>