Hello, * Inline is needed because you might want to specify dozens of YANG modules with all their features and deviations. That is a lot of information, so yes it will take some effort to read and understand it; real life nodes do contain many YAMs, features, deviations. * Simplified-inline is needed, because it is self-contained and often an instance data set only contains info for 1 or 2 YANG modules without deviations or feature issues * URL is required because it is self-describing at least via reference. It might describe big, complicated schemas with a single URI. Most useful when many files with the same complex schema are processed. * External method is needed because in many environments the schema is already known, so it does not need to be included
The workgroup has agreed that all 4 methods are needed for some use-cases. We can restart that debate, but I hope not. Regards Balazs From: Andy Bierman <a...@yumaworks.com> Sent: 2021. július 7., szerda 20:12 To: Balázs Lengyel <balazs.leng...@ericsson.com> Cc: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>; 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 7, 2021 at 1:01 AM Balázs Lengyel <balazs.leng...@ericsson.com <mailto:balazs.leng...@ericsson.com> > wrote: Hello Andy, There are many different use-cases for instance-data-files, each with slightly different requirements. I don't agree that the solution requires 3 ways to do the same thing. Well, 4 if you count External which means Proprietary and Not Standard At All. 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 URL method was requested for the use-case when you generate instance-data-sets repeatedly e.g. every minute with the same schema. You don’t want to include the content-schema in every file, so you just include a single URL reference. (Note the content schema may be a longer piece of text, not just a single YANG module+revision) The solution is very complex and it will not get implemented correctly, or at all. IMO this damages interoperability and prevents some companies from using the solution at all, because a reader tool has so much complexity to implement. The real-world result will be tools that can only read the files they wrote (not written by another tool). Regards Balazs Andy From: Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com> > Sent: 2021. július 6., kedd 21:28 To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de <mailto:j.schoenwael...@jacobs-university.de> >; Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com> >; Rob Wilton (rwilton) <rwil...@cisco.com <mailto:rwil...@cisco.com> >; Balázs Lengyel <balazs.leng...@ericsson.com <mailto:balazs.leng...@ericsson.com> >; netmod@ietf.org <mailto:netmod@ietf.org> ; Benoit Claise <benoit.cla...@huawei.com <mailto:benoit.cla...@huawei.com> > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de <mailto:j.schoenwael...@jacobs-university.de> > wrote: On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote: > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de > <mailto:j.schoenwael...@jacobs-university.de> > wrote: > > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > > > > > IMO the 4 separate ways to identify the schema are 3 too many, but that > > > is what the WG wants. It seems obvious that any reader of the file > > > has to implement all 4 methods and any writer of the file is free to pick > > > just one. > > > So the feature does not really help. > > > > > > > The feature statements declare that implementation won't work > > together. Back in a day, the IETF was all about interoperability (and > > implementation costs). Nowadays we seem to be fine if implementations > > declare that they won't work together. Well, still slightly better > > than having implementations fail arbitrarity. > > > > > > This is a text file stored on a USB stick. > There is no client or server. Just readers and writers. > So how does a YANG feature work here? > The reader is supposed to know how to find out if this feature is set > before opening the file? > > I don't see how server capabilities discovery is relevant to a > YANG instance file. > The reader code will simply attempt to read the file and fail if it > encounters > a format that is not implemented. I assumed that the features are carried in the instance file, i.e., the file declares that it uses way X to announce the schema and then the parser can fail with a suitable error message. If the features are not carried in the file, then they indeed seem to be useless. Perhaps there are Y different ways to announce the features of the instance file as well, I did not check. ;-) Now you made re-read the entire draft :-( I cannot find any text how the reader knows if this feature is set before reading the file and finding out. I do not see any significant use-case for the Inline method and none for the Uri method. Nor do I see any reason why the Simplified-Inline method should not be mandatory to use and always present. If the use-case is offline server validation then the YANG library details need to be known. The entire YANG library for the server (or relevant parts) are recorded in the Inline method. Except it is complicated to store the info about how to interpret YANG schema by reading instance files and guessing what the "anydata" contains. I actually prefer a simple string based on RFC 6020 URI method, since it can be easily integrated into the Simplified Inline form and can be parsed without guessing anything about the contents of anydata. https://datatracker.ietf.org/doc/html/rfc6020#section-5.6.4 e,g, OLD: case simplified-inline { leaf-list module { type module-with-revision-date; ... } } NEW: case simplified-inline { leaf-list module { type union { type module-with-revision-date; type string; } ... } } Example module leaf-list entry: ietf-interfaces?revision=2018-02-20&features=if-mib,arbitrary-names&deviations=acme-deviations IMO Simplified Inline SHOULD be the only format, and the other methods can be removed. /js Andy -- 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/ <https://protect2.fireeye.com/v1/url?k=1b82dc7c-4419e639-1b829ce7-867b36d1634c-3d395fcf11781013&q=1&e=ce6dbbb8-8693-4ac8-abbf-4a2014b77b32&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
