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

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
>