See below! Balazs
From: netmod <netmod-boun...@ietf.org> On Behalf Of Andy Bierman Sent: 2019. október 10., csütörtök 17:34 To: Martin Bjorklund <m...@tail-f.com> Cc: 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. Except a new file extension SHOULD be used. Suggest: .yif == YANG Instance File Obviously it would be a horrible idea to use .yang since that extension is already used to identify a YANG schema file. BALAZS: The leaf-list lists not the instance data files but the content defining YANG modules, so IMO “.yang” is an appropriate extension. It is really a YANG schema file we are listing. o Data node naming. The current structure of the model is: +--rw (content-schema-spec)? | +--:(simplified-inline) | +--rw module* string | +--:(inline) | | +--rw inline-spec* string | | +--rw inline-content-schema <anydata> | +--:(uri) | +--rw schema-uri? inet:uri ... +--rw content-data? <anydata> To make the instance document more understandable, I suggest the following structure, which adds a wrapping container for the schema, and renames the inline and uri nodes: +--rw content-schema +--rw (content-schema-spec)? | +--:(simplified-inline) | +--rw module* string | +--:(inline) | | +--rw inline-module* string | | +--rw inline-schema <anydata> | +--:(uri) | +--rw same-schema-as-file? inet:uri ... +--rw content-data? <anydata> +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), 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
