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.
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.
(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.
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.
(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.
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