On Wed, Nov 6, 2019 at 2:40 PM Balázs Lengyel <[email protected]> wrote:
> See below! Balazs > > > > *From:* netmod <[email protected]> *On Behalf Of *Andy Bierman > *Sent:* 2019. október 10., csütörtök 17:34 > *To:* Martin Bjorklund <[email protected]> > *Cc:* NetMod WG <[email protected]> > *Subject:* Re: [netmod] comments on > draft-ietf-netmod-yang-instance-file-format-04 > > > > > > > > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund <[email protected]> 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. 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. > > > I confused this file with names of modules in the data. IMO it would be useful to have an extension for XML and JSON representations of a YANG instance file, but we can leave that out of the standard. > > 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), > > > 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.) > Andy > Andy > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
