It is perhaps worth noting that the NETCONF copy-config allows for the configuration to be specified using any URI, but the server capabilities announce which URI schemes are supported.
Hence, I think that it is okay for the YANG model to use URI, but I think the draft, and data node description should constrain the URI schemes that allowed (perhaps file:// and https://). This would allow support for future URI schemes to be added in a future revision of the YANG instance data module, if required. Regards, Rob From: Balázs Lengyel <balazs.leng...@ericsson.com> Sent: 08 July 2021 10:17 To: Andy Bierman <a...@yumaworks.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 See inline, Balazs From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>> Sent: 2021. július 7., szerda 20:50 To: Balázs Lengyel <balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>> Cc: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de<mailto:j.schoenwael...@jacobs-university.de>>; Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.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 Hi, I have some questions about the same-schema-as-file leaf: leaf same-schema-as-file { type inet:uri; description "A reference to another YANG instance data file. This instance data file uses the same content schema as the referenced file."; } The type is an unconstrained URI. Is this the intent? The tool that writes the file can pick any scheme - any valid URI at all. The reader must support every known URI scheme in existence? Is that the intent here? BALAZS: As the number of URI schemes is growing with new URI schemes introduced from time to time, that is clearly impossible. On the other hand, we don’t want to constrain URI schemes. This draft is not about selecting the best URI schemes for referencing a file, it only about providing a common format for metadata about instance files. The set of usable/used URI schemes will have to be communicated using some other method. You could ask a similar question: does a Netconf client need to be prepared for any YANG model? No just for the ones he is interested in. Sec. 4 contains this line: The header part is not security sensitive. Is this really true if a URI is present in this leaf that contains a username and password in cleartext? BALAZS: Clear text passwords are not the intention. Shall I add a statement about this to the security considerations? Andy 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. 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 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) Regards Balazs 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>>
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod