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 <[email protected]> > Sent: 08 July 2021 12:48 > To: Rob Wilton (rwilton) <[email protected]>; Juergen Schoenwaelder > <[email protected]> > Cc: Andy Bierman <[email protected]>; [email protected]; Benoit Claise > <[email protected]> > 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) <[email protected]> > Sent: 2021. július 8., csütörtök 12:59 > To: Juergen Schoenwaelder <[email protected]>; Balázs > Lengyel <[email protected]> > Cc: Andy Bierman <[email protected]>; [email protected]; Benoit Claise > <[email protected]> > 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 <[email protected]> > > Sent: 08 July 2021 11:35 > > To: Balázs Lengyel <[email protected]> > > Cc: Andy Bierman <[email protected]>; Rob Wilton (rwilton) > > <[email protected]>; [email protected]; Benoit Claise > > <[email protected]> > > 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 <[email protected]> > > > Sent: 2021. július 7., szerda 21:26 > > > To: Andy Bierman <[email protected]> > > > Cc: Balázs Lengyel <[email protected]>; Rob Wilton > > > (rwilton) <[email protected]>; [email protected]; Benoit Claise > > > <[email protected]> > > > 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
