Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Martin Bjorklund <[e-mail]>]

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]> wrote:
> Thanks Andy.
> 
> I didn't realize that leafref paths would contain the choice & case
> names as segments of the path.

The choice and case nodes are not present in the leafref's path, since
it's an XPath expression that works on the data tree.

Section 9.9.2 says about the context:

   o  If the "path" statement is defined within a typedef, the context
      node is the leaf or leaf-list node in the data tree that
      references the typedef.

   o  Otherwise, the context node is the node in the data tree for which
      the "path" statement is defined.

Note that it says "data tree", not "schema tree".

Also, note how leafref can match on keys:

  path "/interface/interface[name=current()/../mgmt-if-name]/name";

This won't work in the schema tree.

> But now that you pointed that out it
> clarified what this meant in section 7.9 of RFC7950:
>    The identifier is used to identify the choice
>    node in the schema tree.  A choice node does not exist in the data
>    tree.
> 
> Is the same thing true for XPaths in 'must' and 'when' expressions?
> Would those contain choice & case names when referring to a node? Or
> do those refer to the *data* tree rather than the *schema* tree?

All XPath evaluations are done towards a data tree.  So no choice or
state nodes are present there.


/martin

> I'm
> sure it is in there somewhere but I couldn't quite figure that out
> from looking around 7950.
> 
> Jason
> 
> From: Andy Bierman <[e-mail]>
> Sent: Monday, November 19, 2018 3:54 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>
> Cc: NetMod WG <[e-mail]>
> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' -
> NBC change?
> 
> 
> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa)
> <[e-mail]<mailto:[e-mail]>> wrote:
> Hi all,
> 
> If we have a YANG model with a leaf:
> 
> MODEL VERSION 1:
> container my-model {
>     leaf a { type string; }
> }
> 
> And then later we produce another version of the model where that leaf
> is placed into a choice construct:
> 
> MODEL VERSION 2:
> container my-model {
>     choice some-choice {
>         case x {
>             leaf a { type string; }
>         }
>     }
> }
> 
> Is that considered a non-backwards-compatible change?
> 
> 
> yes -- even though the data node /my-model/x did not change,
> the schema node /my-model/a changed to /my-model/some-choice/x/a.
> Any leafref path pointing at this leaf will break.
> 
> 
> Andy
> 
> 
> Does the answer depend on whether the choice contains other cases (or
> other cases that are the default case)?
> 
> 
> no
> 
> MODEL VERSION 3:
> container my-model {
>     choice some-choice {
>         case x {
>             leaf a { type string; }
>         }
>         case y {
>             leaf b { type string; }
>         }
>     }
> }
> 
> A client 'foo' using VERSION 1 would still be able to set & read back
> leaf a in the same way as it always did.
> 
> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> 'a' would disappear. That could be surprising to client 'foo' although
> perhaps no more surprising than if another client simply deletes leaf
> 'a' (using VERSION 1).
> 
> Jason
> 
> 
> 
> _______________________________________________
> netmod mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netmod