On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder < 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> 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/> >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
