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>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
