Re: YANG validation issue in draft-ietf-dmm-fpc-cpdp-06.txt

Hi Lyle,

Let me answer to everybody

1. We added pyang to the submission tool. Note that pyang doesn't check 
xpath
     And yes, we might have some caching issue here when people submit 
multiple interdependent drafts the same day.
2. yangvalidator.org is a best effort tool maintained by Carl Moberg. It 
might not be up to date.
     And yes, we could have some caching issue, because the right way to 
do it is
      - start from scratch,
      - download all the drafts,
      - extract all YANG models
      - include all the RFC YANG modules, and the other YANG modules 
(IEEE, openconfig, etc.) that might be needed
      - compile all these YANG modules with 4 validators (2 opensource, 
2 commercial) that you obviously keep up to date
      - reports bug to the different validators when you find one.
      - wash ... rinse ... repeat
      All this (I skipped some steps to shorten the email :-) ) is what 
I do in 3.
3. I maintain my own tool chain and generate all my reports on 
www.claise.be, once the IETF drafts are posted or when a github repo is 
updated.
     When I see how much time it takes me, no wonder that 2. might not 
be up to date.

See in-line.
> We changed that this morning and tested but got the same response form the yangvalator site.  Thus, it appears we are then fighting a caching bug on yangvaldator site.  Although our I-D toolchains are evolving, I think having multiple toolchains is a bit problematic here as authors are shadowboxing.  We'll make the update but is there a way to get an official toolchain established that authors can point to?
>
> The I-D tool is not using the same tool set others, who are commenting on errors/issue, are.  This makes YANG development a bit more problematic as we go from a 'it worked on this chain but not that one...' situation.  If the answer for now is 'maintain your own toolchain' that is fine
The tool chains above are best effort.  So the best answer at this point 
is : you get what you paid for, so maintain your own toolchain :-)
> but I would encourage public access on how to maintain a good chain (or a github project on the chain) and push awareness, at least once, beyond netmod wg as more working groups pick up YANG.
I've been monitoring every single new YANG module and sending 
appropriate emails to the authors when I spot errors out of my tool chain.
Like this initial email for example.

Regards, Benoit
>    
>
> Lyle
>
> -----Original Message-----
> From: Radek Krejčí [mailto:[email protected]]
> Sent: Monday, March 13, 2017 8:39 AM
> To: Benoit Claise <[email protected]>; Bertz, Lyle T [CTO] <[email protected]>; [email protected]; [email protected]; Per Hedeland <[email protected]>
> Subject: Re: [DMM] YANG validation issue in draft-ietf-dmm-fpc-cpdp-06.txt
>
> Hi,
> some notes to warnings from yanglint:
>
> - each two warnings are actually connected in this case, so let's look to the first issue:
> warn: Schema node "attributetype" not found (../attributetype).
> warn: Invalid when condition "../attributetype = 'Per-MN-Agg-Max-DL-Bit-Rate-type'". (/ietf-dmm-fpc:tenants/tenant/fpc-mobility/contexts/ul/qos-profile-parameters/value/ietf-dmm-fpc-pmip:qos-pmip/attribute-choice/per-mn-agg-max-dl-case)
>
> - attributetype node, used in the when condition as "../attributetype", was not found
> - the when condition is placed in the node with the path printed at the end of the second message in the brackets
> - when you look into the schema, the node with when is actually placed into ietf-dmm-fpc-pmip via uses in one of the augments, used grouping qosattribute is from ietf-pmip-qos
> - so the actual bug is in ietf-pmip-qos schema in grouping qosattribute - instead of ../attributetype there should be ./attributetype because the context node for the when in case statement is the closets ancestor node to the node with the "when" statement that is a data node
>
> Regards,
> Radek
>
>
> Dne 13.3.2017 v 14:19 Benoit Claise napsal(a):
>> Including Radek (developing yanglint) and Per (confd), in case they've got the bandwidth to help you.
>>
>> Regards, Benoit
>>> We will as soon as we can isolate the error.  The error is unhelpful.  Do you have any guidance on it?
>>>
>>> Also, is there any way to rid ourselves of those tailf warnings?  They happen quite often and our developers now ignore most errors coming from confd as noise.
>>>
>>> -----Original Message-----
>>> From: dmm [mailto:[email protected]] On Behalf Of Benoit Claise
>>> Sent: Monday, March 13, 2017 6:17 AM
>>> To: [email protected]; [email protected]
>>> Subject: [DMM] YANG validation issue in draft-ietf-dmm-fpc-cpdp-06.txt
>>>
>>> Dear authors,
>>>
>>> I see that you have posted a new draft version. Great.
>>> Note that [email protected] still fails validation.
>>> See https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.claise.be%2FIETFYANGPageCompilation.html&data=02%7C01%7Clyle.t.bertz%40sprint.com%7C05650ca67a00476a5b9008d46a03b748%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636250011571481523&sdata=RwDlcOxUAxOoCew0qs9nMQsjbtZ0vXQ4HgUKL8ABdn8%3D&reserved=0
>>> Please correct the mistake and post a new version.
>>>
>>> Regards, Benoit
>>>
>>> _______________________________________________
>>> dmm mailing list
>>> [email protected]
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7Clyle.t.bertz%40sprint.com%7C05650ca67a00476a5b9008d46a03b748%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636250011571481523&sdata=u5sSjji78baaTpWJkQWc0Wk2Y1AjtzRhWkSJAn5cgcQ%3D&reserved=0
>>>
>>> ________________________________
>>>
>>> This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
>>> .
>>>