Hi Balazs, Thanks. That sounds fine. Please can you add a sentence to the description of the simplified-inline in the YANG model to state this, which I think may be something like:
"YANG modules that are only required to satisfy import-only dependencies MAY be excluded from the leaf-list. If they are excluded then the consumer of the instance data file can choose any versions of the YANG modules that satisfy the import dependency." Regards, Rob > -----Original Message----- > From: Balázs Lengyel <balazs.leng...@ericsson.com> > Sent: 09 July 2021 08:25 > To: Rob Wilton (rwilton) <rwil...@cisco.com>; Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> > Cc: Andy Bierman <a...@yumaworks.com>; netmod@ietf.org; Benoit Claise > <benoit.cla...@huawei.com> > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format > > Hello, > A single line is enough. > As long as ietf-yang-types is change in a backward compatible way, I don't > care which version of yang-types is imported. Also, we only use a single > type 'yang:xpath1.0' from yang-types. The rules for this type are described > by W3C and not changing. > Balazs > > -----Original Message----- > From: Rob Wilton (rwilton) <rwil...@cisco.com> > Sent: 2021. július 8., csütörtök 15:49 > To: Balázs Lengyel <balazs.leng...@ericsson.com>; Juergen Schoenwaelder > <j.schoenwael...@jacobs-university.de> > Cc: Andy Bierman <a...@yumaworks.com>; netmod@ietf.org; Benoit Claise > <benoit.cla...@huawei.com> > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format > > Hi Balazs, > > Would your inline schema not also need to specify the ietf-yang-types > dependency? > > E.g., should it be: > ietf-netconf-acm@2018-02-14 > ietf-yang-types@2013-07-15 > > Thanks, > Rob > > > > -----Original Message----- > > From: Balázs Lengyel <balazs.leng...@ericsson.com> > > Sent: 08 July 2021 12:48 > > To: Rob Wilton (rwilton) <rwil...@cisco.com>; Juergen Schoenwaelder > > <j.schoenwael...@jacobs-university.de> > > Cc: Andy Bierman <a...@yumaworks.com>; netmod@ietf.org; Benoit > Claise > > <benoit.cla...@huawei.com> > > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format > > > > Hello, > > I would like to keep simplified inline. If I ask my developers (not > > experts) which one do they want? I am pretty sure they opt for the > > shorter/simpler one. > > > > <module>ietf-netconf-acm@2018-02-14<module> > > > > OR > > > > <yang-library> > > <module-set> > > <name>m</name> > > <module> > > <name>ietf-netconf-acm</name> > > <revision>2018-02-14</revision> > > <namespace>uri1</namespace> > > </module> > > <import-only-module> > > <name>ietf-yang-types</name> > > <namespace>uri2</namespace> > > <revision/> > > </import-only-module> > > </module-set> > > <schema> > > <name>s</name> > > <module-set>m</module-set> > > </schema> > > <datastore> > > <name>running</name> > > <schema>s</schema> > > </datastore> > > </yang-library> > > > > Regards Balazs > > > > -----Original Message----- > > From: Rob Wilton (rwilton) <rwil...@cisco.com> > > Sent: 2021. július 8., csütörtök 12:59 > > To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>; > > Balázs Lengyel <balazs.leng...@ericsson.com> > > Cc: Andy Bierman <a...@yumaworks.com>; netmod@ietf.org; Benoit > Claise > > <benoit.cla...@huawei.com> > > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format > > > > Hi Juergen, > > > > I believe that having the simple form is worth the extra complexity. > > > > I think that you are right to be concerned that it should not expand > > into a separate parallel format. Overtime, I would like the simple > > form to be able to use revision labels instead of revision dates, but > > beyond this I think that it should just be a flat list of modules that > > defines the schema. If a subset of features, or datastores, or > > import-only modules are needed then the YANG library version (or URIs) > can > and should be used. > > > > Another example of where I expect it to be useful is in YANG packages. > > Looking at the examples at the end of > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, > > then some of those files (which currently aren't defining any schema, > > but should) would almost double in size if they represented the schema > > inline using YANG library, which I think would make the files harder > > for humans to read/parse. > > Using URIs could help mitigate this, but then we would need to find a > > place to publish the file containing the YANG package schema > > (presumably somewhere in IANA), and it not obvious to me that adding > > the dependency on the URL is really as helpful. > > > > Regards, > > Rob > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> > > > Sent: 08 July 2021 11:35 > > > To: Balázs Lengyel <balazs.leng...@ericsson.com> > > > Cc: Andy Bierman <a...@yumaworks.com>; Rob Wilton (rwilton) > > > <rwil...@cisco.com>; netmod@ietf.org; Benoit Claise > > > <benoit.cla...@huawei.com> > > > Subject: Re: AD review of > > > draft-ietf-netmod-yang-instance-file-format > > > > > > The question I asked is "how much simpler is it and does that saving > > > justify the introduction of a new rather limited format (that may > > > risk to grow over time and become a second citizen)". > > > > > > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > > > from ietf-yang-types (at the time of publication that resolves to > > > ietf-yang-types@2013-07-15. So the YANG Library instance data would > > > roughly look this (please correct what I messed up, I am writing > > > this by hand): > > > > > > <yang-library> > > > <module-set> > > > <name>m</name> > > > <module> > > > <name>ietf-netconf-acm</name> > > > <revision>2018-02-14</revision> > > > <namespace>uri1</namespace> > > > </module> > > > <import-only-module> > > > <name>ietf-yang-types</name> > > > <namespace>uri2</namespace> > > > <revision/> > > > </import-only-module> > > > </module-set> > > > <schema> > > > <name>s</name> > > > <module-set>m</module-set> > > > </schema> > > > <datastore> > > > <name>running</name> > > > <schema>s</schema> > > > </datastore> > > > </yang-library> > > > > > > Yes, this is a bit longer, but it also conveys more information > > > (note that your datastore leaf in the header would likely not be > > > needed anymore). > > > > > > I am concerned that we start creating another format to define > > > schemas that is very limited and people later come with extension > > > proposals to address some of the limits and at the end we have > > > multiple formats to maintain and deal with. So the question is > > > whether people think this is worth it. (Note that the felt overhead > > > goes down with every additional module used by your instance file, > > > so the example above is really the most extreme case. And if you > > > have many modules defining NACM rules, then you put the above into a > > > separate file and use the URI to point to the schema, no? > > > > > > /js > > > > > > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Balázs Lengyel wrote: > > > > Hello Jurgen, > > > > Inline: > > > > This complex form of inline was requested and not objected earlier > > > > by > > > other > > > > reviewers. > > > > Based on Rob's and others' proposal inline will be simplified to > > > > use only > > > > ietf-yang-library@2019-01-04 as you suggest. > > > > > > > > Simplified inline: > > > > In Ericsson we already use simplified inline a lot, it is the most > > > > common format. > > > > If you are providing data only for one or a few YANG modules and > > > > don't > > > have, > > > > > > > > don't care about features/deviations it is the easiest, shortest > > > > method to use. > > > > Our most common use-case is to provide preconfigured access > > > > control > > > rules > > > > for new nodes. > > > > When a YANG modeler designs a new module, he immediately provides > > > > a > > > set of > > > > NACM rules > > > > for the readOnly and the SystemAdmin roles/groups. > > > > In this case you only need to specify "ietf-neconf-acm@2012-02-22" > > > > No deviations, no features to indicate. > > > > Regards Balazs > > > > > > > > Regards Balazs > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> > > > > Sent: 2021. július 7., szerda 21:26 > > > > To: Andy Bierman <a...@yumaworks.com> > > > > Cc: Balázs Lengyel <balazs.leng...@ericsson.com>; Rob Wilton > > > > (rwilton) <rwil...@cisco.com>; netmod@ietf.org; Benoit Claise > > > > <benoit.cla...@huawei.com> > > > > Subject: Re: AD review of > > > > draft-ietf-netmod-yang-instance-file-format > > > > > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > > > > > Inline method is needed, if you want to indicate that the file > > > > > > was generated by someone who uses some YANG modules with > > > > > > deviations > > > and > > > > > > some features are not-supported. There is no way to indicate > > > > > > feature-support and deviations with the simplified-inline method. > > > > > > > > > > The Inline anydata solution is very heavyweight. > > > > > Before the YANG library there was a simple URI that is easier to > > > > > use and takes up much less storage. > > > > > > > > > > > > > The inline content schema is super generic since it supports an > > > > open ended set of schema defining modules. While you can use it > > > > with say ietf-yang-library@2019-01-04, you can use anything else > > > > as well. In other words, two implementations supporting inline > > > > content schema may not interoperate. I do not think there is a > > > > schema format that is mandatory to implement for inline content > schema. > > > > > > > > So here is my assessment of what we have in terms of interoperability: > > > > > > > > - Simplified-Inline comes with notable restrictions, interoperable > > > > - Inline is an open ended content schema, not necessarily > > > > interoperable > > > > - URI method pushes the problem to another instance file, > > > > interoperable > > > > - External is by desing not interoperable > > > > > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has > > > > some complexity that is useful for supporting large servers with > > > > multiple datastores and not needed for small instance files (I > > > > understand that an instance file is always tied to a single > datastore?). > > > > > > > > To me, it feels that reusing RFC 8525 design is actually a good > > > > thing. Being able to dump a live server datastore into an instance > > > > file seems like a very valid use case to me and ideally this is > > > > possible without having to rewrite the schema part. Well, you > > > > could go and trim unused datastore schemas > > > and > > > > from there unused module sets etc but that can all be done by an > > > > external tool trimming the schema part, i.e., it does not need to > > > > be done by a tool that just dumps a server datastore. > > > > > > > > What is the actual value of simplified inline? How much do you > > > > really save compared to the simplest equivalent RFC 8525 > > > > representation? And does > > > that > > > > saving justify to start engineering another schema specification > format? > > > > > > > > I guess my choice would have been to just have > > > > > > > > +-- content-schema > > > > | +-- (content-schema-spec)? > > > > | +--: (yang-library) > > > > | +--: (uri) > > > > > > > > but others obviously want much more choice (but lets note that > > > > everything sits in a choice, so everything is extensible in case > > > > other schema definition formats are out there). > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > Fax: +49 421 200 3103 > > > > <https://protect2.fireeye.com/v1/url?k=fe85c8e6-a11ef1cd-fe85887d- > > > 866038973a > > > > 15-19e5dad375af0063&q=1&e=3637406d-f774-4073-80ee- > > > a7431111e9bc&u=https%3A%2F > > > > %2Fwww.jacobs-university.de%2F> > > > > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > Fax: +49 421 200 3103 > > <https://protect2.fireeye.com/v1/url?k=7edafb8e-2141c2bf-7edabb15- > > 86e2237f51 > > fb-eceadf4f1dc08461&q=1&e=09140141-b70c-44c9-9909- > > 048d736efebf&u=https%3A%2F > > %2Fwww.jacobs-university.de%2F> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
