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

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: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