Subject: [netmod] NETCONF server handling of 'when' statements

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 2 May 2018 15:21:02 +0000

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://test.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://dummy.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

Is the result the same if the red-value and foo-type leafs were reversed in the XML above ?

(B) Assume the candidate is empty initially.  Does the following edit-config to the candidate return an error ?

<root xmlns=http://dummy.com>
  <red-value>23</red-value>
  <foo-type>green</foo-type>
</root>

Does it also return an error if the red-value and foo-type leafs were reversed in the XML 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 ?

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) ?

Rgds,
Jason

---

From: Robert Wilton <[email-masked]>
Date: Thu, 3 May 2018 11:39:52 +0100

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).
>
>    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 {
>
> (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>
>
Yes.

> 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>
>
I think that it depends on if/when candidate is validated.
Certainly it is not valid in this state.

> 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-masked]
> https://secure-web.cisco.com/1fuFv0na4qfxbvBYug9IKC-mmyzxu1yP8GNikD9y4MUBFLzTufk-XIyIkQQrHLymAFnh5O5vcA-QoCWAFDfBuEsJQy0DpHJfhfVL3yhtZ6B9hHa0OI17Q2MfqLXBvRC3wylOGP9A2ZzeMn9DMara96FtuGPOLmNufjx3D1jE01LjrKo8uu22WTQMoo0Mn2E9HYQcZIL1UA4WJRTDVY7B3mtjkfWXKRQyGBI0ydzAZKkRO1JVLreMh5cv3ste_WLHzwx7LRVLUxNReQ7Lx4_fe5jRlkjJm8oEjVowunA5cLYRCfIgbGu7DJjhGoh4X1oP4yt7U9imcXzfwjGaHFvrtLRKn7YXWyIwWwkA-bzMFPchPR0MkfiYcZkI9LP3mBmcF/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 03 May 2018 12:53:23 +0200 (CEST)

Yes.

Yes.

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

Yes.

> No, I don't think that should be required.

Agreed.

/martin

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 03 May 2018 13:27:47 +0200 (CEST)

[...]

> this behaviour in a future version of YANG. :-)

This has been discussed quite a lot in the past...  Think of "when" as
a generalized version of "choice".  If you don't want the
auto-deletion aspects of "when", then use "must".  I agree that it is
a sharp tool; so use it with care.  But as with many sharp tools, it
is quite handy when used properly.

/martin