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

Martin Bjorklund <mbj@tail-f.com> Thu, 03 May 2018 10:53 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E4112D947 for <netmod@ietfa.amsl.com>; Thu, 3 May 2018 03:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMxPquTi7Ztd for <netmod@ietfa.amsl.com>; Thu, 3 May 2018 03:53:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 83E9312D877 for <netmod@ietf.org>; Thu, 3 May 2018 03:53:26 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 65AE11AE030D; Thu, 3 May 2018 12:53:24 +0200 (CEST)
Date: Thu, 03 May 2018 12:53:23 +0200 (CEST)
Message-Id: <20180503.125323.783664077417511029.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: jason.sterne@nokia.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <903d8476-9e01-2ad7-cfe1-fe02283bb076@cisco.com>
References: <AM0PR07MB38442E8CF930E0D216C218459B800@AM0PR07MB3844.eurprd07.prod.outlook.com> <903d8476-9e01-2ad7-cfe1-fe02283bb076@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BIDJBWF09NityHwwXTjBX0hJLxw>
Subject: Re: [netmod] NETCONF server handling of 'when' statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 May 2018 10:53:29 -0000

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