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

[Andy Bierman <[e-mail]>]

On Sun, Nov 17, 2019 at 8:52 AM Martin Bjorklund <[e-mail]> wrote:

> Hi,
>
> Balázs Lengyel <[e-mail]> wrote:
> > See below BALAZS2.
> > -----Original Message-----
> > From: Martin Bjorklund <[e-mail]>
> > Sent: 2019. november 7., csütörtök 16:17
> > To: Balázs Lengyel <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [netmod] comments on
> draft-ietf-netmod-yang-instance-file-format-04
> >
> > Balázs Lengyel <[e-mail]> wrote:
> > > See below!    Balazs
> > >
> > >
> > >
> > > From: netmod <[e-mail]> On Behalf Of Andy Bierman
> > > Sent: 2019. október 10., csütörtök 17:34
> > > To: Martin Bjorklund <[e-mail]>
> > > Cc: NetMod WG <[e-mail]>
> > > Subject: Re: [netmod] comments on
> > > draft-ietf-netmod-yang-instance-file-format-04
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund <[e-mail]
> <mailto:[e-mail]> > 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.
> > >
> > >
> > >
> > > 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.
> >
> > No, you are not listing a file name, you are listing the name and,
> optionally, the revision of a YANG *module*.  It can internally be stored
> as a .yang file a .yin file, or as a blob in a database.
> >
> > Hence, we should not have the ".yang" suffix here.
> > BALAZS2:
> > OK, I will add the '.yin' possibility.
>
> IMO this is even worse.  Which suffix should I use?  What difference
> does it make?
>
>
+1



> > I would like to keep the file extension because
> > [e-mail]
> > looks more familiar
>
> I think it is a bad idea to use something that looks familiar but
> change the meaning of it.  It is *not* a filename, it is a pair
> modulename + optional revision; an identifier for the module.
>
> , will be easier to understand, than just
> > ietf-yang-types@2019-12-07
> > IMHO in practice systems might very well use it for file lookup.
>
> But if I use this for file lookup, and I use YIN, and I try to use an
> instance file that lists the modules as ".yang", this won't work.
>
>
> Perhaps solve this by changing the leaf-list into:
>
>

I think your original proposal is the correct solution:

   mod-name [ @revision ]

The YANG module files (.yang or .yin) are not actually available, so unlike
<get-schema>,
they do not matter.  The file reader app needs to be capable of finding
module files on its own.



>   container inline-modules {
>     list module {
>       key name;
>       leaf name { ... }
>       leaf revision { ... }
>     }
>   }
>
>
> /martin
>

Andy