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

[Balázs Lengyel <[e-mail]>]

1 comment accepted, 1 explained. See below BALAZS2. 

 

From: Andy Bierman <[e-mail]> 
Sent: 2019. november 7., csütörtök 7:15
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 Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund <[e-mail] <mailto:[e-mail]> > 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:[e-mail]> [e-mail]

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
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/netmod