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

From: Balázs Lengyel <[email-masked]>
Date: Wed, 6 Nov 2019 21:57:49 +0000

Hello Martin,
I will update the draft following most of your comments. See details below.
Regards Balazs

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Martin Bjorklund
Sent: 2019. október 10., csütörtök 14:05
To: [email-masked]
Subject: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

Hi,

I have some mostly cosmetic comments on this draft.
  o  "YANG" should be spelled "YANG".  Not Yang etc.
BALAZS: OK
  o  "NETCONF" should be spelled "NETCONF".
BALAZS: OK
  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).
BALAZS: I disagree, IMHO we need the revision date. We want to know the 
exact version the data was produced against. If the version would be 
unknown it might become very hard to understand whether the instance 
data is correct or not.

  o  schema-uri
    The description says:
          A reference to another YANG instance data file.
          This instance data file will use the same set of target
          YANG modules, revisions, supported features and deviations
          as the referenced YANG instance data file.

   I don't understand what this means.  Does it mean that the schema
   for this document is the same as the schema defined in the
   schema-uri file, or that the schema-uri file defines the schema in
   its content-data?

   I *think* it is the former.  In either case, the name of the leaf
   can perhaps be changed to reflect the semantics, rather than the
   syntax (i.e., don't call it xxx-uri just b/c its type is an uri).
   Perhaps 'same-schema-as-file'.
BALAZS:  OK, I changed the description hope it is easier to understand now.
            description
              "A reference to another YANG instance data file.
               This instance data file will use the same
               content schema as the referenced file.";

  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>
BALAZS: OK, accepted

  o  Format the YANG module
    I suggest you run the YANG module through:
      pyang -f yang --keep-comments --yang-line-length 69
BALAZS: OK (I will do it, but I don't agree with a number of its formatting
changes.

  o  3.2
    The element "<netconf-state>" needs a namespace declaration.
BALAZS: OK

/martin

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 6 Nov 2019 22:40:55 +0000

See below!    Balazs

From: netmod <[email-masked]> On Behalf Of Andy Bierman
Sent: 2019. október 10., csütörtök 17:34
To: Martin Bjorklund <[email-masked]>
Cc: NetMod WG <[email-masked]>
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-masked] <mailto:[email-masked]> > wrote:

  o  leaf-list module

   (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.

        +--rw content-schema

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

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 6 Nov 2019 23:07:43 +0000

See below, Balazs

Sent: 2019. október 10., csütörtök 19:38

On Thu, Oct 10, 2019 at 8:34 AM Andy Bierman <[email-masked] <mailto:[email-masked]> > wrote:

Hi,

  o  leaf-list module

   (same for inline-spec).

 

Sorry about the confusion over this comment.

There should be reusable typedefs defined in rfc6991bis representing the format in 7950, sec. 5.2

There should also be file extensions defined for an XML or JSON file that is expected to

follow the YIF structure.  

Andy

BALAZS: 

For the modules listed in leaf-list module: These are real YANG schema files so IMO the “.yang” extension should be used.

For the instance data files: In the -00 version of the draft it was stated that the files should have their own extension “.yid” . 

“.yid-json” and “.yid-xml” was also discussed.

However, the group requested that I just use .json and .xml  as extensions (as described in section 3.)

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Nov 2019 15:14:56 -0800

On Wed, Nov 6, 2019 at 2:40 PM Balázs Lengyel <[email-masked]>
wrote:

> See below!    Balazs
>
>
>
> *From:* netmod <[email-masked]> *On Behalf Of *Andy Bierman
> *Sent:* 2019. október 10., csütörtök 17:34
> *To:* Martin Bjorklund <[email-masked]>
> *Cc:* NetMod WG <[email-masked]>
> *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-masked]> wrote:
>
>
>   o  leaf-list module
>
> 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.

> 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.

> 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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Nov 2019 15:43:43 -0800

On Wed, Nov 6, 2019 at 3:07 PM Balázs Lengyel <[email-masked]>
wrote:

> *Sent:* 2019. október 10., csütörtök 19:38
> On Thu, Oct 10, 2019 at 8:34 AM Andy Bierman <[email-masked]> wrote:
>
>
>
>
>
> For the modules listed in leaf-list module: These are real YANG schema
> files so IMO the “.yang” extension should be used.
>
> For the instance data files: In the -00 version of the draft it was stated
> that the files should have their own extension “.yid” .
>
IMO section 3 is too specific about the content within the content-data
node.
The only requirement should be that it is valid XML or JSON according to
the schema listed.  All content should be identified, so if you include
or:origin attributes
then ietf-origin MUST be in the schema list.  It is a bad idea to
force tools to accept
invalid XML (e.g., no xmlns for a prefix that is used.

The text about the required file-name structure if timestamps are present
seems rather arbitrary.  What if the tool generating the file is not aware
of
specific YANG objects, so it does not know there are data nodes
representing timestamps?
Why is this needed? The file contains revision and timestamp meta-data.

   If the leaf name is present in the instance data header this MUST
      be used.  Revision-date MUST be set to the latest revision date
      inside the instance data set.

I do not understand the text above.
IMO none of sec. 3 MUST requirements are needed.
Looks like a lot of CLRs to me.

Hard to see what harm to the Internet is caused
by a YID file that is named "incorrectly".  Tools will create their own
file extensions, because
lumping everything in with .xml or .json is shortsighted. Why does the
standard say SHALL
use .xml or .json?  Is this a general requirement for all XML or JSON
content?
If not, then why is being added here?

How does the tool that reads the YID file know what version of the YID
template is being used?
(Or do you think this module is perfect, and will never be updated?)
Seems like the very first leaf should be a "yid-version", similar to
"yang-version" in YANG.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Nov 2019 09:08:06 +0100 (CET)

Hi,

> unknown it might become very hard to understand whether the instance 

The point is that the revision statement is optional in YANG.  If the
module doesn't have a revision statement I can't list it here.

>                content schema as the referenced file.";

Thanks, better.  Perhaps: s/will use/uses/

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Nov 2019 09:16:55 +0100 (CET)

> 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.

No, you are not listing a file name, you are listing the name and,
optionally, the revision of a YANG *module*.  It can internally be
stored as a .yang file a .yin file, or as a blob in a database.

Hence, we should not have the ".yang" suffix here.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Nov 2019 09:24:40 +0100 (CET)

> > On Thu, Oct 10, 2019 at 5:06 AM Martin Bjorklund <[email-masked]> wrote:

[...]

> anything (as opposed to a pre-defined YANG template like /yang-library).

Note that the name of this leaf is misleading (see my ealrier
comments).  It is really 'same-schema-as-file', which means that it
point to another YANG instance data file, which must specify its
schema in one of the three ways.  Which may be another schema-uri, but
in the end the recursion must stop and you must find a YANG instance
data file that usses 'simplified-inline' or 'inline'.

> The inline-content-schema object looks broken because a YANG file is a text

It is supposed to be data nodes for /yang-library or perhaps
/module-sets, or perhaps something else.  See the examples in section
3.2.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Nov 2019 07:57:48 -0800

> data file that usses 'simplified-inline' or 'inline'.

OK -- much worse than I thought...

> /module-sets, or perhaps something else.  See the examples in section

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

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 17 Nov 2019 12:12:28 +0000

1 comment accepted, 1 explained. See below BALAZS2. 

From: Andy Bierman <[email-masked]> 
Sent: 2019. november 7., csütörtök 7:15
To: Balázs Lengyel <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; NetMod WG <[email-masked]>
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

  o  leaf-list module

   (same for inline-spec).

 

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:[email-masked]> [email-masked]

looks more familiar than just

ietf-yang-types@2019-12-07

 

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

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.

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

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 17 Nov 2019 12:44:41 +0000

See below, BALAZS

Sent: 2019. november 7., csütörtök 7:44

IMO section 3 is too specific about the content within the content-data node.

the schema listed.  All content should be identified, so if you include or:origin attributes

then ietf-origin MUST be in the schema list.  It is a bad idea to force tools to accept

BALAZS: Don’t really agree. We intentionally allow the violation of the schema (as described)
-  partial data set are allowed

*	It is allowed to only have config=false data

People requested to explicitly mention UTF-8

IMHO it is good to mention metadata/XML attributes as they are useful and are not regulated by the schema

seems rather arbitrary.  What if the tool generating the file is not aware of

specific YANG objects, so it does not know there are data nodes representing timestamps?

 

BALAZS: To make it easier I will make the inclusion of date/timestamp optional.

These are nearly the exact same rules we have for naming YANG files.

Name+date

Even for a YANG module we require that an internal data element, the module’s argument must match the file name’s beginning.

Even for a YANG module we recommend that an internal data element, the revision’s argument must match the file name’s middle part.

Many people like it that the file’s name immediately tells you what it is and what version.

by a YID file that is named "incorrectly".  Tools will create their own file extensions, because

lumping everything in with .xml or .json is shortsighted. Why does the standard say SHALL

use .xml or .json?  Is this a general requirement for all XML or JSON content?

BALAZS: It was an earlier decision of the netmod group to use just json/xml. I would like a more descriptive extension but was outvoted.

How does the tool that reads the YID file know what version of the YID template is being used?

Seems like the very first leaf should be a "yid-version", similar to "yang-version" in YANG.

BALAZS:  OK, I will add the yid-version. (Otherwise the module is perfect :-)  )

Andy

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 17 Nov 2019 13:52:13 +0000

See below BALAZS2.

-----Original Message-----
From: Martin Bjorklund <[email-masked]> 
Sent: 2019. november 7., csütörtök 16:08
To: Balázs Lengyel <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] comments on

Hi,

> BALAZS: I disagree, IMHO we need the revision date. We want to know 
> the exact version the data was produced against. If the version would 
> be unknown it might become very hard to understand whether the 
> instance data is correct or not.

The point is that the revision statement is optional in YANG.  If the module
doesn't have a revision statement I can't list it here.
BALAZS2: OK, I will update the pattern  to make the date optional, and will
add in the description, that if it is available it must be used.

BALAZS2: OK

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 17 Nov 2019 13:52:15 +0000

See below BALAZS2.
-----Original Message-----
From: Martin Bjorklund <[email-masked]> 
Sent: 2019. november 7., csütörtök 16:17
To: Balázs Lengyel <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

> 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.

No, you are not listing a file name, you are listing the name and, optionally, the revision of a YANG *module*.  It can internally be stored as a .yang file a .yin file, or as a blob in a database.

Hence, we should not have the ".yang" suffix here.
BALAZS2:
OK, I will add the '.yin' possibility.
I would like to keep the file extension because
[email-masked]
looks more familiar, will be easier to understand, than just
ietf-yang-types@2019-12-07
IMHO in practice systems might very well use it for file lookup.

I updated the pattern to: 
              pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*' +
                '(@\d{4}-\d{2}-\d{2})?\.((yang)|(yin))';
/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 17 Nov 2019 14:17:08 +0000

See below BALAZS2.

-----Original Message-----
From: Martin Bjorklund <[email-masked]> 
Sent: 2019. november 7., csütörtök 16:25
To: [email-masked]
Cc: Balázs Lengyel <[email-masked]>; [email-masked]
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04
> instance file can be anything (as opposed to a pre-defined YANG 
> template like /yang-library).

Note that the name of this leaf is misleading (see my ealrier comments).  It is really 'same-schema-as-file', which means that it point to another YANG instance data file, which must specify its schema in one of the three ways.  Which may be another schema-uri, but in the end the recursion must stop and you must find a YANG instance data file that usses 'simplified-inline' or 'inline'.
BALAZS2: leaf name changes following Martin's suggestion

> The inline-content-schema object looks broken because a YANG file is a 

It is supposed to be data nodes for /yang-library or perhaps /module-sets, or perhaps something else.  See the examples in section 3.2.

BALAZS2: The draft includes the text:
" A schema-uri leaf SHALL contain a URI that references another YANG   instance data file."
So just as Martin says: it is a reference to a YANG file but to a yang INSTANCE DATA file: which is yangdata.

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 17 Nov 2019 14:19:51 +0000

From: Andy Bierman <[email-masked]> 
Sent: 2019. november 7., csütörtök 23:58
To: Martin Bjorklund <[email-masked]>
Cc: Balázs Lengyel <[email-masked]>; NetMod WG <[email-masked]>
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?

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 17 Nov 2019 17:52:35 +0100 (CET)

Hi,

> OK, I will add the '.yin' possibility.

IMO this is even worse.  Which suffix should I use?  What difference
does it make?

> looks more familiar

I think it is a bad idea to use something that looks familiar but
change the meaning of it.  It is *not* a filename, it is a pair
modulename + optional revision; an identifier for the module.

, will be easier to understand, than just
> IMHO in practice systems might very well use it for file lookup.

But if I use this for file lookup, and I use YIN, and I try to use an
instance file that lists the modules as ".yang", this won't work.

Perhaps solve this by changing the leaf-list into:

  container inline-modules {
    list module {
      key name;
      leaf name { ... }
      leaf revision { ... }
    }
  }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Nov 2019 08:57:50 -0800

On Sun, Nov 17, 2019 at 6:19 AM Balázs Lengyel <[email-masked]>
wrote:

>
>
>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* 2019. november 7., csütörtök 23:58
> *Cc:* Balázs Lengyel <[email-masked]>; NetMod WG <
> [email-masked]>

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

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 17 Nov 2019 18:01:53 +0000

See below BALAZS3.

Sent: 2019. november 18., hétfő 0:58

On Sun, Nov 17, 2019 at 6:19 AM Balázs Lengyel <[email-masked] <mailto:[email-masked]> > wrote:

 From: Andy Bierman <[email-masked] <mailto:[email-masked]> > 
Sent: 2019. november 7., csütörtök 23:58
To: Martin Bjorklund <[email-masked] <mailto:[email-masked]> >
Cc: Balázs Lengyel <[email-masked] <mailto:[email-masked]> >; NetMod WG <[email-masked] <mailto:[email-masked]> >
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

Andy

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

           } 

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

                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.

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 17 Nov 2019 18:12:33 +0000

-----Original Message-----
From: Martin Bjorklund <[email-masked]> 
Sent: 2019. november 18., hétfő 0:53
To: Balázs Lengyel <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

> OK, I will add the '.yin' possibility.

IMO this is even worse.  Which suffix should I use?  What difference does it make?

> [email-masked] looks more familiar

I think it is a bad idea to use something that looks familiar but change the meaning of it.  It is *not* a filename, it is a pair modulename + optional revision; an identifier for the module.

> IMHO in practice systems might very well use it for file lookup.

But if I use this for file lookup, and I use YIN, and I try to use an instance file that lists the modules as ".yang", this won't work.

/martin

BALAZS3: People explicitly asked for a short, simple solution, so reusing the well-known module-file-naming format seemed logical,  and nobody misunderstood it till now.
I would really like to avoid creating a list with 2 separate leaf's: longer, more complex. It goes against the express wishes of other group members.
If you prefer we can drop the file extension. IMHO it will look strange.

I think a file loader can have the intelligence to look for a yin if yang is not found or vice-versa.
/Balazs

---

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Nov 2019 15:07:08 -0800

On Sun, Nov 17, 2019 at 8:52 AM Martin Bjorklund <[email-masked]> wrote:

> > > BALAZS: It does follow the pattern except that I made the revision
> date mandatory. It is needed to properly understand the instance data.
> > >
> > >
> > >
> > > 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.
> >
> optionally, the revision of a YANG *module*.  It can internally be stored
> as a .yang file a .yin file, or as a blob in a database.
> >
+1

> Perhaps solve this by changing the leaf-list into:

I think your original proposal is the correct solution:

   mod-name [ @revision ]

The YANG module files (.yang or .yin) are not actually available, so unlike
<get-schema>,
they do not matter.  The file reader app needs to be capable of finding
module files on its own.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Nov 2019 15:12:27 -0800

On Sun, Nov 17, 2019 at 10:01 AM Balázs Lengyel <[email-masked]>
wrote:

> *Sent:* 2019. november 18., hétfő 0:58
> *To:* Balázs Lengyel <[email-masked]>
> *Cc:* Martin Bjorklund <[email-masked]>; NetMod WG <[email-masked]>
> On Sun, Nov 17, 2019 at 6:19 AM Balázs Lengyel <
> [email-masked]> wrote:
>
> 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

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 18 Nov 2019 03:57:31 +0000

See below BALAZS4.

Sent: 2019. november 18., hétfő 7:12

On Sun, Nov 17, 2019 at 10:01 AM Balázs Lengyel <[email-masked] <mailto:[email-masked]> > wrote:

See below BALAZS3.

From: Andy Bierman <[email-masked] <mailto:[email-masked]> > 
Sent: 2019. november 18., hétfő 0:58
To: Balázs Lengyel <[email-masked] <mailto:[email-masked]> >
Cc: Martin Bjorklund <[email-masked] <mailto:[email-masked]> >; NetMod WG <[email-masked] <mailto:[email-masked]> >
Subject: Re: [netmod] comments on draft-ietf-netmod-yang-instance-file-format-04

Andy

           anydata inline-schema {
             mandatory true;
             description

           } 

Andy

BALAZS3:

           anydata inline-schema {

             mandatory true;

             description

 

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 

 

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.

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.

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 18 Nov 2019 12:54:29 +0100 (CET)

Balázs Lengyel <[email-masked]> wrote:
> > > content defining YANG modules, so IMO “.yang” is an appropriate
> > > extension. It is really a YANG schema file we are listing.
> > 
> BALAZS3: People explicitly asked for a short, simple solution, so
> reusing the well-known module-file-naming format seemed logical, and
> nobody misunderstood it till now.
> I would really like to avoid creating a list with 2 separate leaf's:
> longer, more complex. It goes against the express wishes of other
> group members.
> If you prefer we can drop the file extension.

Yes I think this is better.

> IMHO it will look strange.

Perhaps this document will set the standard for future references to
modules, so that this short-hand notation is used in more places,
rather than separate name / revision leafs...

BTW, you mentioned in your presentation of
draft-ietf-netconf-notification-capabilities that this doc will be
impacted by changes in draft-ietf-netmod-yang-instance-file-format.  I
think that this is ok and we continue the process for this document.
The RFC editor won't publish it until instance-file-format is done, so
there is time to fix the examples.

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 18 Nov 2019 15:24:20 +0000

Hi Martin,

One comment below.

> Sent: 18 November 2019 19:54
> To: [email-masked]
> Cc: [email-masked]

[RW] <snipped>
> modules, so that this short-hand notation is used in more places, rather
> than separate name / revision leafs...
> 
[RW] 
The module versioning draft (draft-verdt-netmod-yang-module-versioning) allows modules to be identified by their name and revision-label, e.g. from section 3.3:

   If a revision has an associated revision label, then it may be used
   instead of the revision date in two places:

      In an "rev:revision-or-derived" extension statement argument.

      In the filename of a YANG module, where it takes the form: module-
      or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )

Obviously the revision label could be a YANG semver, e.g. it would be nice if we were allowed strings like:
  "[email-masked]" rather than forcing it to use the revision date.

The module versioning draft hasn't been adopted as a WG item yet, but I'm hoping that this can be considered, along with the other drafts soon.

Thanks,
Rob

> BTW, you mentioned in your presentation of draft-ietf-netconf-
> notification-capabilities that this doc will be impacted by changes in
> draft-ietf-netmod-yang-instance-file-format.  I think that this is ok and
> we continue the process for this document.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Nov 2019 16:16:39 -0800

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

> *Sent:* 2019. november 18., hétfő 7:12
> On Sun, Nov 17, 2019 at 10:01 AM Balázs Lengyel <

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