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 believe it is the only option that does not have too much complexity. The inline form seems to imply that the NMDA version of the YANG library is used. Only 1 module set is ever shown, but of course the actual schema allows for much more complex instances than that, which the reader must support. Does this mean NMDA must be used or else a YANG data file cannot be saved? So the reader is expected to look for the 'current' /yang-library and then the 'deprecated' /modules-state? And then fish the anydata for whatever non-standard solution is in use? The procedures should be explained better so there is a better chance of interoperability. For the URI method, the reader must check for a broken chain of reference and loops. The draft should say the uri references across N files MUST NOT create a loop (similar language is in YANG wrt import loops). For conformance purposes, I think YANG features are appropriate. IMO simplified-inline is mandatory-to-implement but the rest should be optional. This way a tool can claim conformance and also the standard will provide a minimum level of interoperability. Andy > 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. > > This can be done with augment if and when the versioning draft reaches RFC > 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://www.jacobs-university.de/> >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
