Balázs Lengyel <[email protected]> wrote: > > > -----Original Message----- > From: Martin Bjorklund <[email protected]> > Sent: 2019. november 18., hétfő 0:53 > To: Balázs Lengyel <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [netmod] comments on > draft-ietf-netmod-yang-instance-file-format-04 > > > > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund <[email protected] > > > <mailto:[email protected]> > 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? > > > I would like to keep the file extension because > > [email protected] 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: > > container inline-modules { > list module { > key name; > leaf name { ... } > leaf revision { ... } > } > } > > /martin > > BALAZS3: People explicitly asked for a short, simple solution, so > reusing the well-known module-file-naming format seemed logical, and > nobody misunderstood it till now. > I would really like to avoid creating a list with 2 separate leaf's: > longer, more complex. It goes against the express wishes of other > group members. > If you prefer we can drop the file extension.
Yes I think this is better. > IMHO it will look strange. Perhaps this document will set the standard for future references to modules, so that this short-hand notation is used in more places, rather than separate name / revision leafs... BTW, you mentioned in your presentation of draft-ietf-netconf-notification-capabilities that this doc will be impacted by changes in draft-ietf-netmod-yang-instance-file-format. I think that this is ok and we continue the process for this document. The RFC editor won't publish it until instance-file-format is done, so there is time to fix the examples. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
