Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07

From: Balázs Lengyel <[email-masked]>
Date: Fri, 6 Mar 2020 14:44:31 +0000

From: Kent Watsen <[email-masked]> 
Sent: 2020. február 14., péntek 20:15
To: Balázs Lengyel <[email-masked]>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07

Have the YANG modules been validated and tested for formatting?

(i.e., pyang -f yang --keep-comments --yang-line-length 69 filename) 

BALAZS: yes. With pyang offline and yangvalidator.com

Have the examples in the draft validated against the YANG module?

BALAZS: Only manually. How do you validate samples conforming to a yang data structure ?

Please review the Normative/Informative status of the references.

Not looking carefully, but RFCs 2119 and 8174 should be Normative, 

and I think RFCs 3688 and 6020 should be Informative, right?

BALAZS: OK, changed in rev 08 

All of the “import” statements in the YANG module are missing a

“reference” statement.

BALAZS: 

Added:

rfc6991 for types added. 

Already present: 

rfc8342 for datastores

ietf-netmod-yang-data-ext for ietf-yang-structure-ext

Please add a paragraph to Section 5.2 preceding the YANG module

indicating all the aforementioned Normative references.

BALAZS: OK, I did it, but 

this is not what is required by https://tools.ietf.org/html/rfc8407#section-3.9.

I also see no value in this statement.

The copyright in the YANG module needs to be 2020 (not 2019)

BALAZS: OK

Please ensure a blank line between paragraphs in the “description"

statements.

BALAZS: OK

Please add a statement to the Introduction regarding why the module

Isn’t compliant with NMDA.

BALAZS: Sorry, don’t understand. Why is this not compliant with NMDA ? 

IMHO it is NMDA compliant, or rather it  has nothing to do with NDMA.

The tree diagram does not adhere to the syntax described in 

draft-ietf-netmod-yang-data-ext.  

BALAZS: OK I try, but what actually is the problem? Any help would be really appreciated.

Sadly 

pyang -p ../ietfYams ietf-yang-instance-data\@2020-03-06.yang -f tree --tree-print-yang-data --tree-print-yang-data

doesn’t print out anything, so I am handcrafting.

I just updated pyang from git. Any idea why this doesn’t work for me?

It would be good if YangValidator would print out the tree. At some point it did. Not now. :-(

Please update the first sentence  in Section 5.1 to also reference draft-ietf-netmod-yang-data-ext.

BALZS: OK

Please ensure that the planning-text version of the draft passes

IDNITS (https://www6.ietf.org/tools/idnits <https://protect2.fireeye.com/v1/url?k=e5cfab15-b91ba273-e5cfeb8e-8610d8a762ca-c786959c5f6d65dc&q=1&e=9a66002a-9006-4173-87aa-d650b9cbdf03&u=https%3A%2F%2Fwww6.ietf.org%2Ftools%2Fidnits> ) at the “verbose output”

level and correct any issues found, or explain why they shouldn’t

be corrected.

BALAZS: OK, corrected

Thanks,

Kent  // shepherd

On Feb 14, 2020, at 11:03 AM, Balázs Lengyel <[email-masked] <mailto:[email-masked]> > wrote:

Hello Chairs,
I replied to Juergen, and exchanged some additional mails with him. I updated the draft to draft-ietf-netmod-yang-instance-file-format-07. Please take it forward in the process.

https://protect2.fireeye.com/v1/url?k=ed368c2e-b1bcaefa-ed36ccb5-0cc47ad93e6a-1bf0817821133165 <https://protect2.fireeye.com/v1/url?k=ed368c2e-b1bcaefa-ed36ccb5-0cc47ad93e6a-1bf0817821133165&q=1&e=b8630aed-b037-42b0-a579-0e6e8067e0eb&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-netmod-yang-instance-file-format-07> &q=1&e=b8630aed-b037-42b0-a579-0e6e8067e0eb&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-netmod-yang-instance-file-format-07
Regards Balazs

-----Original Message-----
From: netmod <[email-masked] <mailto:[email-masked]> > On Behalf Of Kent Watsen
Sent: 2020. február 9., vasárnap 20:23
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06

This message closes the WGLC.

Authors, please respond to Juergen’s message from Jan 20, ultimately posting an update to the draft.

Thanks,
Kent // as shepherd

On Jan 7, 2020, at 7:41 AM, Kent Watsen <[email-masked] <mailto:[email-masked]> > wrote:

This begins a two-week Working Group Last Call (WGLC) on draft-ietf-netmod-yang-instance-file-format-06.  The WGLC ends on Jan 21.  Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors.  Objections, concerns, and suggestions are also welcomed at this time.

Thank you,
NETMOD Chairs

_______________________________________________
netmod mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netmod <https://protect2.fireeye.com/v1/url?k=89fe7c6a-d52a750c-89fe3cf1-8610d8a762ca-ab9209e107d110d3&q=1&e=9a66002a-9006-4173-87aa-d650b9cbdf03&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod> 

_______________________________________________
netmod mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/netmod <https://protect2.fireeye.com/v1/url?k=ef180575-b3cc0c13-ef1845ee-8610d8a762ca-c0ef022d895b1910&q=1&e=9a66002a-9006-4173-87aa-d650b9cbdf03&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Mar 2020 02:57:51 +0000

Hi Balazs,

> BALAZS: yes. With pyang offline and yangvalidator.com

Okay.

> BALAZS: Only manually. How do you validate samples conforming to a yang data structure ?

Hmmm, seeing that the examples are still not valid, here goes:

	Until such time as tools support validating structure-data-ext, 
	one can rewrite the YANG module via s/sx:structure/container/ 
	and perform the validation against the resulting YANG module.

> BALAZS: OK, changed in rev 08

Did you check all the other references too?  (I’m trying to save having to do another roundtrip when I do the shepherd writeup...)

> ietf-netmod-yang-data-ext for ietf-yang-structure-ext

Again, all the “import” statements in the YANG module are missing a “reference” statement.

> I also see no value in this statement.

I the "reference” statements mentioned above had been added, then s3.9 applies.

> IMHO it is NMDA compliant, or rather it  has nothing to do with NDMA.

Either way but, per https://tools.ietf.org/html/rfc8407#section-3.5, the 
statement should be in the Introduction section.

> BALAZS: OK I try, but what actually is the problem? Any help would be really appreciated.

I was looking at the “+—rw”, which can’t be right because yang-data is not “configuration”...

> doesn’t print out anything, so I am handcrafting.

`pyang`  supports the old/RFC8040 “rc:yang-data” statement; it hasn’t been updated to support the new "sx:structure” statement.

> It would be good if YangValidator would print out the tree. At some point it did. Not now. :-(

First, use the s/sx:structure/container/ trick mentioned above.

Then s/+--rw/+—/.

Then review https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-05#section-3 and tweak accordingly until all is good.

> IDNITS (https://www6.ietf.org/tools/idnits) at the “verbose output”
> 

Thanks!  (this is almost always the cause for needing another draft update when doing the shepherd writeup)

NEW: looking at the new "format-version”, please add a pattern statement to constrain the string values appropriately.  Hint, it’s half a "date-and-time” type...

Kent  // contributor (and shepherd)

---

From: Kent Watsen <[email-masked]>
Date: Wed, 18 Mar 2020 20:07:10 +0000

One more thing, for non-mandatory nodes that don’t have a default value specified, please ensure the “description” statement states what it means for the node to be set or not set (whichever is easier)?   For instance:

OLD:

       leaf name {
         type string;
         description
           "Name of the YANG instance data set.";
       }

NEW (assuming this makes sense):

       leaf name {
         type string;
         description
           “An arbitrary name for the YANG instance data set.  This
            value is primarily used for descriptive purposes.  However,
            when the instance data set is saved to a file, then the
            filename MUST encode the name’s value, per Section 3 
            of RFC XXXX.";
       }

BTW, should the requirement of it needing to be encoded into the
filename place constraints on the “string” type?  Should a “pattern”
statement be added?

Kent

> On Mar 17, 2020, at 10:57 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> Hi Balazs,
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 19 Mar 2020 12:08:48 +0000

-----Original Message-----
From: Kent Watsen <[email-masked]> 
Sent: 2020. március 18., szerda 21:07
To: Balázs Lengyel <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07

OLD:

       leaf name {
         type string;
         description

       leaf name {
         type string;
         description
           “An arbitrary name for the YANG instance data set.  This
            value is primarily used for descriptive purposes.  However,
            when the instance data set is saved to a file, then the
            filename MUST encode the name’s value, per Section 3 
            of RFC XXXX.";
       }
BALAZS: OK
BTW, should the requirement of it needing to be encoded into the filename place constraints on the “string” type?  Should a “pattern”
statement be added?
BALAZS: IMHO defining a pattern for a filename string (that may be dependent on the used filesystem) is out of scope for this draft.

Extended description of content-schema.
IMHO contact, description, revision, timestamp does not need to explain what does it mean if they are not present. It only means: no information available.
Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 27 Mar 2020 14:58:07 +0000

All,

The current -10 draft appears to have addressed all issues raised during the last call.  Thank you to everyone that participated.

I will start the shepherd review now.  Hopefully it will go smoothly, as a number of issues that I raised during the WGLC were related to things that are typically discovered during the shepherd review.

Kent // co-chair and shepherd

> On Mar 19, 2020, at 8:08 AM, Balázs Lengyel <[email-masked]> wrote:
> 
> 
>