Hi Jason, Because pyang and libyang have different explanation to ‘property’ of statement, I have talked about this with martin last year, he thought it’s unclear in RFC7950, but he didn’t point out what is correct.
So I want to get a clarification from WG, it’s very helpful for industry. 发件人: Jason Sterne (Nokia) [mailto:[email protected]] 发送时间: 2023年5月14日 3:02 收件人: Fengchong (frank) <[email protected]>; [email protected] 主题: RE: Clarify the meaning of property in RFC7950 Hi Frank, The table just after the text has this: +--------------+--------------+-------------+ | substatement | section | cardinality | +--------------+--------------+-------------+ | config | 7.21.1 | 0..1 | | default | 7.6.4, 7.7.4 | 0..n | | mandatory | 7.6.5 | 0..1 | | max-elements | 7.7.6 | 0..1 | | min-elements | 7.7.5 | 0..1 | | must | 7.5.3 | 0..n | | type | 7.4 | 0..1 | | unique | 7.8.3 | 0..n | | units | 7.3.3 | 0..1 | +--------------+--------------+-------------+ The deviate's Substatements That implies to me (since it says “deviate’s substatements”, not just “delete substatements”) that only those items can be added/changed/deleted. That table is the list of “properties”. But the other part of your question here isn’t so clear to me either. Every node does have a config true or false property associated with them (either explicitly, by default, or inherited from an ancestor). But does that mean it “exists” (from the ‘replace’ paragraph)? Does that mean it “matches a corresponding keyword in the targer node (from the ‘delete’ paragraph)? In some ways maybe either add or replace should just work in this case since it isn’t really ambiguous what the result should be. Jason From: netmod <[email protected]<mailto:[email protected]>> On Behalf Of Fengchong (frank) Sent: Monday, May 8, 2023 2:15 AM To: [email protected]<mailto:[email protected]> Subject: [netmod] Clarify the meaning of property in RFC7950 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi all, In RFC7950 sec 7.20.3.2<https://datatracker.ietf.org/doc/html/rfc7950#section-7.20.3.2>: The argument "add" adds properties to the target node. The properties to add are identified by substatements to the "deviate" statement. If a property can only appear once, the property MUST NOT exist in the target node. The argument "replace" replaces properties of the target node. The properties to replace are identified by substatements to the "deviate" statement. The properties to replace MUST exist in the target node. The argument "delete" deletes properties from the target node. The properties to delete are identified by substatements to the "delete" statement. The substatement's keyword MUST match a corresponding keyword in the target node, and the argument's string MUST be equal to the corresponding keyword's argument string in the target node. What’s the meaning of property? Is it a sub-statement? I see pyang and libyang have two different explanation. Pyang treat ‘config’ property as always exist property, because ‘config’ statement has default value (true or derived from parent). But libyang think if there is no ‘config’ sub-statement, then the ‘config’ property will be not exist. So there is a conflict when using pyang/libyang to parse YANG module. For example, Module a { Container a { Leaf b { Type string; } } } Module a-dev { Deviation “/a:a/a:b” { Deviate add { Config false; } } } This example, pyang will report error, because pyang think ‘config’ property is always exist, so this propery should not be added. But libyang think it’s valid. If we change the type of deviate from ‘add’ to ‘replace’. Module a-dev { Deviation “/a:a/a:b” { Deviate replace { Config false; } } } Pyang will think it’s valid. But libyang think it’s invalid. So I think WG should clarify what’s the meaning of property. Ref: Issue on pyang: https://github.com/mbj4668/pyang/issues/815 Issue on libyang: https://github.com/CESNET/libyang/issues/2010
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
