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

Robert Wilton <rwilton@cisco.com> Thu, 03 May 2018 10:39 UTC

Return-Path: <rwilton@cisco.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 3B40B12D947 for <netmod@ietfa.amsl.com>; Thu, 3 May 2018 03:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.52
X-Spam-Level:
X-Spam-Status: No, score=-12.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 LuYm0TWF7ZQj for <netmod@ietfa.amsl.com>; Thu, 3 May 2018 03:39:55 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2537212D889 for <netmod@ietf.org>; Thu, 3 May 2018 03:39:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25784; q=dns/txt; s=iport; t=1525343995; x=1526553595; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=YTqU7qJ8x6tb4R18ALVcbp0ZCYt5TXwH2vNV3YV0e1s=; b=Vwk2ebreIfkxwb1Bddey0zf92MwVTcSpn4BqvSUDZt4x1SQ2byjyKnU9 VthZ7Nia6cO7I+dPCoFpxtuMeu8+7Q7CV5O/hLdV+Ez1K5hPnZPbsEqAb 23UgKa4jgrQYof470R2k/xaWEzBJT0N9Z5dpxOk1rq5b2Onth8yjnX1R3 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQAT5upa/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNgVcXYyiMTY1dKYEPkxoUgWQLGAEJhARGAoJONRcBAgE?= =?us-ascii?q?BAQEBAQJsHAyFKAEBAQECAQEBK0EQCwsYIA4nMAYBDAYCAQEQhHMID6ppH4Q?= =?us-ascii?q?5g3CCQolvP4EPI4JogxEBAQKBKwESAQmFagKYFwiFZIJShhAGgXGFXoUKiT+?= =?us-ascii?q?BX4UjgSUdATZhcTMaCBsVO4JDCYVzhRSFPz4wAQEKjhkNFweCGQEB?=
X-IronPort-AV: E=Sophos;i="5.49,358,1520899200"; d="scan'208,217";a="3534780"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 May 2018 10:39:53 +0000
Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w43AdqNo026702; Thu, 3 May 2018 10:39:53 GMT
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <AM0PR07MB38442E8CF930E0D216C218459B800@AM0PR07MB3844.eurprd07.prod.outlook.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <903d8476-9e01-2ad7-cfe1-fe02283bb076@cisco.com>
Date: Thu, 3 May 2018 11:39:52 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <AM0PR07MB38442E8CF930E0D216C218459B800@AM0PR07MB3844.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------EDFBF04F7A6AD250CE8F95BE"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Uqb12yresyRGJmbMJIhfNRxcaEw>
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:39:58 -0000

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