Re: [netmod] choice statements and trim vs explicit default handling

Ladislav Lhotka <lhotka@nic.cz> Wed, 12 April 2017 13:28 UTC

Return-Path: <lhotka@nic.cz>
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 B5FBB1294A6 for <netmod@ietfa.amsl.com>; Wed, 12 Apr 2017 06:28:30 -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] 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 E2417UjMrsOB for <netmod@ietfa.amsl.com>; Wed, 12 Apr 2017 06:28:28 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 073AA1294B3 for <netmod@ietf.org>; Wed, 12 Apr 2017 06:28:28 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 684F9182000E; Wed, 12 Apr 2017 15:28:21 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>, Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
In-Reply-To: <HE1PR07MB084391FD4DD8667A311E2D069B030@HE1PR07MB0843.eurprd07.prod.outlook.com>
References: <HE1PR07MB08433E9459870BCF06F754349B0C0@HE1PR07MB0843.eurprd07.prod.outlook.com> <e77ea6c1-fe1d-f511-9c84-b34b4bd399cb@cisco.com> <HE1PR07MB084391FD4DD8667A311E2D069B030@HE1PR07MB0843.eurprd07.prod.outlook.com>
Date: Wed, 12 Apr 2017 15:28:25 +0200
Message-ID: <m260i9u552.fsf@birdie.labs.nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/1UBkq3JgKOX3pwVQvUJZa0u2s5s>
Subject: Re: [netmod] choice statements and trim vs explicit default handling
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: Wed, 12 Apr 2017 13:28:31 -0000

"Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> writes:

> Thanks Rob.
>
> You may be right here but it isn't what I would have expected.  You're saying that any existing config in case bb is removed by the *act* of writing to a leaf of case aa, even if that write (setting some-bool to its default value) results in no config existing in case aa (for 'trim' servers).
>
> If I had a must statement for leaf some-num like this: must ". != 55";
> and a client sets some-num to 55 I suppose that would clear out
> (delete) any previous config of some-bool, even though the
> validate/commit later would fail.  After the failure it is "too late"
> and some-bool would have already lost its value.  So case bb would be
> 'selected' even though it is a config that will fail validation.

Yes, but note that the situation would be different if you used

when ". != 55";

for "some-num" instead - setting "some-num" to 55 silently discards this
case and the default value for "some-bool" takes effect. Similar
interactions between "when" and default values (and auto-deletion) make
implementations brittle and prone to race conditions.

It is not difficult to understand why some people (mainly in XML
circles) always insisted that modifying the data, e.g. by adding
defaults, while validating the same data was a terrible idea.

Lada

>
> You mention "would be ignored".  That is true for the particular model I show below, but default values for child nodes under a case don't require a default for the overall choice in order to be relevant.  If I had other leafs in those cases, then the defaults could be used/relevant even without a default for the choice (when another leaf of the same case is configured).  >From 7.9.3. :
>
>     Default values for child nodes under a case are only used if one of
>        the nodes under that case is present or if that case is the default
>        case.
>
> Rgds,
> Jason
>
>
> From: Robert Wilton [mailto:rwilton@cisco.com]
> Sent: Monday, April 10, 2017 5:19
> To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>; netmod@ietf.org
> Subject: Re: [netmod] choice statements and trim vs explicit default handling
>
>
> Hi Jason,
>
> Your default statement in your YANG snippet below would be ignored, as per section 7.9.3 of RFC 7950.
>
> But, if you changed your YANG to this:
> choice foo {
>   default aa;
>
>   case aa {
>     leaf some-bool { type Boolean; default "false"; }
>   {
>   case bb {
>     leaf some-num { type int32; }
>   }
> }
>
>
> Then answering both (A) and (B): I would assume that setting "some-bool" to "true" or "false" would cause "bb" to be deleted regardless of what default mode the server was using.  If neither some-bool or some-num had been set to an explicit value then some-bool semantically exists with value "false" due to the two default statements.
>
> I might be wrong, but I have always assumed that the with-defaults extension is really concerned with the presentation/encoding of default values, and isn't intended to change the underlying semantics of YANG's handling of default values.
>
> Thanks,
> Rob
>
> On 07/04/2017 23:50, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> Hi all,
>
> When a server operates in 'trim' mode (rfc6243), setting a leaf to its default value removes it from the config (i.e. it is indistinguishable from the case where that leaf was never configured or the case where that leaf was deleted/removed).
>
> (A)
> Does setting a leaf in one case of a choice to its default value (in a 'trim' mode server) cause leafs in other cases to be implicitly deleted ?  I assume not.
>
> For example:
>
> choice foo {
>   case aa {
>     leaf some-bool { type Boolean; default "false"; }
>   {
>   case bb {
>     leaf some-num { type int32; }
>   }
> }
>
> If some-num is currently set to 50, and then an edit-config sets some-bool to "false", does that clear the some-num leaf ?
> (i.e. does it select case aa ?)
>
> RFC 7950 says: "the creation of a node from one case implicitly deletes all nodes from all other cases".
> RFC 6243 section 2.2.3 describes that a leaf set to default (in a trim server) doesn't exist.
>
> (B)
> Now how about if the server operates in 'explicit' mode ?  Does setting some-bool to "false" clear some-num ?  I assume it does (but it just seems a little funny that the behavior on this changes between trim and explicit servers).
>
>
> Regards,
> Jason
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> netmod mailing list
>
> netmod@ietf.org<mailto:netmod@ietf.org>
>
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67