On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) <rwil...@cisco.com> wrote:
> 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. > > https://datatracker.ietf.org/doc/html/draft-bierman-netmod-yang-conformance-00 An original use-case in my 2013 draft was to allow a vendor to define a package that represented the entire server. Then the entire <hello> and YANG library can be replaced by one package-id in this case. This is reasonable for embedded devices that have a fixed YANG library (expected for CORECONF). BTW, the main reason I proposed the YANG syntax (your version has a JSON document) is that these files are needed by automation tools, and YANG allows extensions (and other things like augment). Automation tools cannot work without extensions so not sure how JSON package files will be useful to them. Regards, > Rob > Andy > > > > -----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://www.jacobs-university.de/> >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
