Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07
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
> wrote:
>
>
>
> -Original Message-
> From: Kent Watsen
> Sent: 2020. március 18., szerda 21:07
> To: Balázs Lengyel
> Cc: netmod@ietf.org
> Subject: Re: [netmod] WG Last Call:
> draft-ietf-netmod-yang-instance-file-format-06 to -07
>
> 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 .";
> }
> 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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07
-Original Message-
From: Kent Watsen
Sent: 2020. március 18., szerda 21:07
To: Balázs Lengyel
Cc: netmod@ietf.org
Subject: Re: [netmod] WG Last Call:
draft-ietf-netmod-yang-instance-file-format-06 to -07
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 .";
}
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
smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07
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 .";
}
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 wrote:
>
>
> Hi Balazs,
>
>
>> 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
>
> Okay.
>
>
>> 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 ?
>
> 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.
>
>
>> 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
>
> Did you check all the other references too? (I’m trying to save having to do
> another roundtrip when I do the shepherd writeup...)
>
>
>> 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
>
> Again, all the “import” statements in the YANG module are missing a
> “reference” statement.
>
>
>> 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.
>
> I the "reference” statements mentioned above had been added, then s3.9
> applies.
>
>
>> 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.
>
> Either way but, per https://tools.ietf.org/html/rfc8407#section-3.5, the
> statement should be in the Introduction section.
>
>
>> 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.
>
> I was looking at the “+—rw”, which can’t be right because yang-data is not
> “configuration”...
>
>
>> 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.
>
> `pyang` supports the old/RFC8040 “rc:yang-data” statement; it hasn’t been
> updated to support the new "sx:structure” statement.
>
>
>> 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. :-(
>
> 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.
>
>
>> 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) at the “verbose output”
>>
>> level and correct any issues found, or explain why they shouldn’t
>>
>> be corrected.
>>
>> BALAZS: OK, corrected
>
> Thanks! (this is almost always the cause for needing another draft
Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07
Hi Balazs, > 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 Okay. > 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 ? 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. > 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 Did you check all the other references too? (I’m trying to save having to do another roundtrip when I do the shepherd writeup...) > 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 Again, all the “import” statements in the YANG module are missing a “reference” statement. > 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. I the "reference” statements mentioned above had been added, then s3.9 applies. > 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. Either way but, per https://tools.ietf.org/html/rfc8407#section-3.5, the statement should be in the Introduction section. > 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. I was looking at the “+—rw”, which can’t be right because yang-data is not “configuration”... > 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. `pyang` supports the old/RFC8040 “rc:yang-data” statement; it hasn’t been updated to support the new "sx:structure” statement. > 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. :-( 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. > 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) at the “verbose output” > > level and correct any issues found, or explain why they shouldn’t > > be corrected. > > BALAZS: OK, corrected 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) ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07
Juergen, Does the update address all your concerns? Do you feel there is a need for another LC Hi Balazs, Did you mean to send this to the netmod-chairs alias? Oh well, as long we’re here, following are some questions/comments: Have the YANG modules been validated and tested for formatting? (i.e., pyang -f yang --keep-comments --yang-line-length 69 filename) Have the examples in the draft validated against the YANG module? 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? All of the “import” statements in the YANG module are missing a “reference” statement. Please add a paragraph to Section 5.2 preceding the YANG module indicating all the aforementioned Normative references. The copyright in the YANG module needs to be 2020 (not 2019) Please ensure a blank line between paragraphs in the “description" statements. Please add a statement to the Introduction regarding why the module Isn’t compliant with NMDA. The tree diagram does not adhere to the syntax described in draft-ietf-netmod-yang-data-ext. Please update the first sentence in Section 5.1 to also reference draft-ietf-netmod-yang-data-ext. Please ensure that the planning-text version of the draft passes IDNITS (https://www6.ietf.org/tools/idnits) at the “verbose output” level and correct any issues found, or explain why they shouldn’t be corrected. Thanks, Kent // shepherd > On Feb 14, 2020, at 11:03 AM, Balázs Lengyel > 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=1=b8630aed-b037-42b0-a579-0e6e8067e0eb=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-netmod-yang-instance-file-format-07 > Regards Balazs > > -Original Message- > From: netmod On Behalf Of Kent Watsen > Sent: 2020. február 9., vasárnap 20:23 > To: netmod@ietf.org > 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 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 >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > ___ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call: draft-ietf-netmod-yang-instance-file-format-06 to -07
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=1=b8630aed-b037-42b0-a579-0e6e8067e0eb=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-netmod-yang-instance-file-format-07 Regards Balazs -Original Message- From: netmod On Behalf Of Kent Watsen Sent: 2020. február 9., vasárnap 20:23 To: netmod@ietf.org 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 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod smime.p7s Description: S/MIME cryptographic signature ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
