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

[Martin Bjorklund <[e-mail]>]

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