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 protected]> 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 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
