1 comment accepted, 1 explained. See below BALAZS2.
From: Andy Bierman <a...@yumaworks.com> Sent: 2019. november 7., csütörtök 7:15 To: Balázs Lengyel <balazs.leng...@ericsson.com> Cc: Martin Bjorklund <m...@tail-f.com>; NetMod WG <netmod@ietf.org> Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04 On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund <m...@tail-f.com <mailto:m...@tail-f.com> > wrote: o leaf-list module The type of this leaf-list is a string with: pattern '.+@\d{4}-\d{2}-\d{2}\.yang'; I think the revision needs to be optional, and the suffix ".yang" dropped, since it doesn't add any value: pattern '.+(@\d{4}-\d{2}-\d{2})?'; (same for inline-spec). IMO the filespec SHOULD follow the pattern in https://tools.ietf.org/html/rfc7950#section-5.2 BALAZS: It does follow the pattern except that I made the revision date mandatory. It is needed to properly understand the instance data. The representation (.yang vs .yin) is not relevant here. Revision statements are optional in a YANG module, so what fake date string do you use if the module has no revision? Seems prudent to make the date-string optional in the filename. BALAZS2: OK, date mandatory only if present in the yang module, otherwise absent. I will add .yin as an alternative. I would like to keep the \.((yang)|(yin)) part in the pattern as <mailto:ietf-yang-t...@2015-12-07.yang> ietf-yang-t...@2015-12-07.yang looks more familiar than just ietf-yang-types@2019-12-07 +1, except not in favor of so many ways to specify schema. That means the file reader MUST support all of them. BALAZS: All 3 formats have been explicitly requested by earlier commenters. I see a rational for each: Simplified-inline: it is simple and usually enough Inline: if you need to specify not just the modules but also the supported features and deviations you need this full format Uri: if you don’t really want to specify the content-schema in detail, e.g., because you are generating many files with the same schema, all you need is reference that identifies the content-schema Which one would you like to implementing? Maybe we could make the inline method optional with a feature (feature if-feature), I will just deviate out the stuff not worth implementing. ;-) I prefer the schema-uri approach but simplified-inline is probably easiest to implement. The schema-uri looks standard but the contents of the referenced YANG instance file can be anything (as opposed to a pre-defined YANG template like /yang-library). The inline-content-schema object looks broken because a YANG file is a text string. How does one use anydata to encode a text string? (It must be a container of YANG data nodes). Even the YIN representation is not a set of YANG data nodes, so anydata encoding seems wrong. Including all the YANG modules in this file seems especially heavyweight. (I have no intention of supporting this mode.) BALAZS2: This does not contain the YANG files themselves, rather something like instance data for the ietf-yang-library. So it is anydata. Sometimes specifying deviations and supported features may be needed. Also Jurgen wanted a flexible solution. As a private comment: you may deviate it out (I can’t say this officialy :-) ) Andy Andy _______________________________________________ netmod mailing list netmod@ietf.org <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
