Robert Wilton <[email protected]> wrote: > Hi Jason, > > The Cisco email security filter has somewhat mangled the URLs in your > message, but my thoughts below ... > > On 02/05/2018 16:21, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > > > Hi all, > > > > I've seen some older threads about 'when' handling and they ended up > > creating a lot of debate about behavior & intentions (and about how > > well the text is written in the specs). > > > > I'm hoping that the community out there is in agreement on yes vs no > > for the questions below. > > > > Given the following module: > > > > module test { > > > > namespace > > "http://secure-web.cisco.com/17Y2QIXhS6SlnAYxG6R_JjTzP7pmTwW1F-Eg06Aa0sRalUV5358LN3CjHP-LR-MfD47g80JiIgIbUuGpUaYFKxvKv8b5HzDwNkX2Sizzw2gbUBkOvOFtkxCUSgoQl-AM9bU0UjNWmE4Nnrk64L3Zt9pjxyqprJte6HWPQGzLZVx-xey27lchO_GWT4LsmlDt494XoVJOQtcHR5XUjvU-O_mqdXHjgLpZMEG7rsmjru7hXkB6nsDPmlUBD5nwJmP6x1MsX1EluBkJtB0MWNSl3-L78RroFr_dUDcynq2yTyfa5uN_QCCB_kzbe8aPu_pZ9s1i1JslD0GtYrOXCjTpiizC5CJWdMcl3AgN-s-MZ6gI/http%3A%2F%2Ftest.com";; > > > > prefix "test"; > > > > container foo { > > > > leaf foo-type { > > > > type enumeration { > > > > enum "green"; > > > > enum "red"; > > > > } > > > > } > > > > leaf green-value { > > > > when "../foo-type = 'green'"; > > > > type uint32; > > > > } > > > > leaf red-value { > > > > when "../foo-type = 'red'"; > > > > type uint32; > > > > } > > > > } > > > > } > > > > (A) Assume the candidate is empty initially. Does the following > > edit-config to the candidate return "OK" ? (only showing the content > > of the <config></config> section): > > > > <root > > xmlns=http://secure-web.cisco.com/1n6yL9gbGW5LZ4loJr_sHzGl3dtOeXtZbr_ymSNNbpnqNC9Uq6XuyUfrAG66jKqWX_DEISNUHnmEoF2yzN01A_ALB4dkI9L6QFnl-aVTS_-M_C5AGJJfI_VulyFBaraLRbIwPKrYvSiG2GR9gto_t6Lh96bdU0ikARiUKQVE2D2UUceA6RypW01ha5ccW6X6GLmU47VUKZ2Q2LS9q-okCyLrkNktXcrYDf_E4Fb1-0Ab0rI4eBHQMKu6YvoSNe0MlCL745ZS9l5qi1busBxlNVt8PZKrxYXRGD3s0Ur7NBP6GQq789J-3GfRuzJL-ks5NqqUwNLLRUe9hgYCfySSzMQjfezZ9lR6EiFVVidvdQa4/http%3A%2F%2Fdummy.com> > > > > <red-value>23</red-value> > > > > <foo-type>red</foo-type> > > > > </root> > > > > Does the candidate contain the following after the edit-config ? > > > > foo-type = red > > > > red-value = 23 > > > Yes.
Yes. > > Is the result the same if the red-value and foo-type leafs were > > reversed in the XML above ? > > > Yes, I don't think that ordering matters. Logically you construct a > updated config tree with all the config changes applied and then check > that the new tree is valid. Yes. > > (B) Assume the candidate is empty initially. Does the following > > edit-config to the candidate return an error ? > > > > <root > > xmlns=http://secure-web.cisco.com/1n6yL9gbGW5LZ4loJr_sHzGl3dtOeXtZbr_ymSNNbpnqNC9Uq6XuyUfrAG66jKqWX_DEISNUHnmEoF2yzN01A_ALB4dkI9L6QFnl-aVTS_-M_C5AGJJfI_VulyFBaraLRbIwPKrYvSiG2GR9gto_t6Lh96bdU0ikARiUKQVE2D2UUceA6RypW01ha5ccW6X6GLmU47VUKZ2Q2LS9q-okCyLrkNktXcrYDf_E4Fb1-0Ab0rI4eBHQMKu6YvoSNe0MlCL745ZS9l5qi1busBxlNVt8PZKrxYXRGD3s0Ur7NBP6GQq789J-3GfRuzJL-ks5NqqUwNLLRUe9hgYCfySSzMQjfezZ9lR6EiFVVidvdQa4/http%3A%2F%2Fdummy.com> > > > > <red-value>23</red-value> > > > > <foo-type>green</foo-type> > > > > </root> > > > I think that it depends on if/when candidate is validated. > Certainly it is not valid in this state. 'when' expressions are not evaluated at validate time, but in at edit-config processing time. See 8.3.2 in RFC 7950. Our server gives the following error in this case: <rpc-error> <error-type>application</error-type> <error-tag>unknown-element</error-tag> <error-severity>error</error-severity> <error-path xmlns:test="http://test.com";> /rpc/edit-config/config/test:foo/test:red-value </error-path> <error-message xml:lang="en">/foo/red-value: the 'when' expression ".../foo-type = 'red'" failed</error-message> <error-info> <bad-element>red-value</bad-element> </error-info> </rpc-error> > > Does it also return an error if the red-value and foo-type leafs were > > reversed in the XML above ? > > > Yes, same answer as above. Yes. > > > (C) Does the presence of 'when' in a YANG model ever create the need > > for a NETCONF client to specifically order nodes within a single > > edit-config to achieve some desired behavior ? > > > No, I don't think that should be required. Agreed. /martin > > Or do 'when' statements purely put the onus on the server to build a > > dependency tree with the scope of a single edit-config (to ensure that > > the input leafs to a 'when' statement are processed before the when > > statement itself is evaluated, i.e. evaluate the when statements at > > the end) ? > > > I think that the required logic steps (when the change being > committed) is: > > 1) Construct a new config tree based purely on the <edit-config> > change. > 2) Check whether any when statements (anywhere in the config tree) are > now false, and if so remove the config associated with them. > 3) Keep repeating step (2) until there are no more changes to be done. > 4) Check that the final "complete config change" is still a valid > config tree and then continue processing as if this is what had been > provided by the client in the first place. > > Personally, I really dislike the implicit delete behaviour of when > statements in steps (2) and (3) because I think that it adds a lot of > unnecessarily complexity in the processing, and has a very surprising > interaction with NACM. I would much rather that the client was forced > to delete everything explicitly. I.e. rather than auto deleting some > config due to an invalid when expression, instead just reject the > config change with an appropriate error. I would be all for changing > this behaviour in a future version of YANG. :-) > > Thanks, > Rob > > > > Rgds, > > > > Jason > > > > > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://secure-web.cisco.com/1fuFv0na4qfxbvBYug9IKC-mmyzxu1yP8GNikD9y4MUBFLzTufk-XIyIkQQrHLymAFnh5O5vcA-QoCWAFDfBuEsJQy0DpHJfhfVL3yhtZ6B9hHa0OI17Q2MfqLXBvRC3wylOGP9A2ZzeMn9DMara96FtuGPOLmNufjx3D1jE01LjrKo8uu22WTQMoo0Mn2E9HYQcZIL1UA4WJRTDVY7B3mtjkfWXKRQyGBI0ydzAZKkRO1JVLreMh5cv3ste_WLHzwx7LRVLUxNReQ7Lx4_fe5jRlkjJm8oEjVowunA5cLYRCfIgbGu7DJjhGoh4X1oP4yt7U9imcXzfwjGaHFvrtLRKn7YXWyIwWwkA-bzMFPchPR0MkfiYcZkI9LP3mBmcF/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
