Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

[Andy Bierman <[e-mail]>]

On Sun, Nov 17, 2019 at 7:57 PM Balázs Lengyel <[e-mail]>
wrote:

> See below BALAZS4.
>
>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* 2019. november 18., hétfő 7:12
> *To:* Balázs Lengyel <[e-mail]>
> *Cc:* Martin Bjorklund <[e-mail]>; NetMod WG <[e-mail]>
> *Subject:* Re: [netmod] comments on
> draft-ietf-netmod-yang-instance-file-format-04
>
>
>
>
>
>
>
> On Sun, Nov 17, 2019 at 10:01 AM Balázs Lengyel <
> [e-mail]> wrote:
>
> See below BALAZS3.
>
>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* 2019. november 18., hétfő 0:58
> *To:* Balázs Lengyel <[e-mail]>
> *Cc:* Martin Bjorklund <[e-mail]>; NetMod WG <[e-mail]>
> *Subject:* Re: [netmod] comments on
> draft-ietf-netmod-yang-instance-file-format-04
>
>
>
> On Sun, Nov 17, 2019 at 6:19 AM Balázs Lengyel <
> [e-mail]> wrote:
>
>  *From:* Andy Bierman <[e-mail]>
> *Sent:* 2019. november 7., csütörtök 23:58
> *To:* Martin Bjorklund <[e-mail]>
> *Cc:* Balázs Lengyel <[e-mail]>; NetMod WG <
> [e-mail]>
> *Subject:* Re: [netmod] comments on
> draft-ietf-netmod-yang-instance-file-format-04
>
>
>
> It seems strange that the details that don't matter at all (like the
> filename) have lots
>
> of rules that MUST be followed and the details that actually add standards
> value are left unspecified.
>
> Andy
>
> BALAZS2: Actually what is missing, unspecified?
>
>
>
> The inline-schema is under-specified.
>
> There is no way for the file reader to know what to expect as the child
> nodes of inline-schema.
>
>
>
> The file writer can put anything there and a 3rd party reader tool is
> expected to support it.
>
>
>
>            anydata inline-schema {
>
>              mandatory true;
>
>              description
>
>                "Instance data corresponding to the YANG modules
>
>                 specified in the inline-module nodes defining the set
>
>                 of content defining YANG modules for this
>
>                 instance-data-set.";
>
>            }
>
>
>
>
>
> Andy
>
>
>
> BALAZS3:
>
> IMO the anydata is specified.  The leaf-list inline-module defines the
> modules that define how anydata inline-schema should look like.
>
>            anydata inline-schema {
>
>              mandatory true;
>
>              description
>
>                "*Instance data corresponding to the YANG modules*
>
> *                specified in the inline-module* ...
>
>
>
> The fileReader/fileWriter shall look at the ‘*leaf-list inline-module*’
> and from that it knows what to read/write.
>
>
>
> I wanted to state that inline-schema anydata always follows the
> ietf-yang-library and maybe some YAMs augmenting it. However Juergen
> insisted in a more flexible solution.
>
>
>
>
>
> I think the following text (or similar) should be added to the
> description-stmt above
>
>
>
>     This node SHOULD contain a single container instance which represents
> either the /yang-library
>
>      or /modules-state subtree.
>
>
>
> This allows for exceptions but still provides interoperability
> instructions.
>
>
>
>
>
> Andy
>
>
>
> BALAZS4: Others (e.g., Juergen) explicitly asked for not restricting this
> to ietf-yang-library.
>
> I would be happy with your proposals, but the group decided otherwise
> sometime back.
>
>
>


A tool has to be coded to understand the contents of the anydata node.
Just parsing it is not enough.

Is there an email thread this is discussed and resolved?
The term SHOULD allows the rule to be broken with a good reason.
What other data structures are needed now (or soon) other than
/modules-state or /yang-library?
I do not see how this file is interoperable if the reader does not know
what to expect.
Flexibility without interoperability is not success.

Also I foresee there might be (there will be)  YANG modules that augment
> yang-library  with information needed here.
>
> I am thinking about yang-versioning that plans to add the version-label,
> which will help determining which versions of the of the YANG module are
> compatible with the originally used schema defining modules.
>
>
>

I do not see how augment is relevant to this interoperability issue.


Andy


>
>
>
>
>
>
>
>
>