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

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 7 Apr 2017 22:50:28 +0000

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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 10 Apr 2017 10:19:20 +0100

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 {

   }

}

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 {
>
> 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 ?
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 12 Apr 2017 03:43:14 +0000

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.

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:[email-masked]]
Sent: Monday, April 10, 2017 5:19
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
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.

  case aa {

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

(A)

For example:

choice foo {
  case aa {

(B)

Regards,
Jason

netmod mailing list

[email-masked]<mailto:[email-masked]>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 12 Apr 2017 15:28:25 +0200

"Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]> writes:

> 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

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