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

Martin Bjorklund <mbj@tail-f.com> Thu, 22 November 2018 13:37 UTC

Return-Path: <mbj@tail-f.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 1F481130EE0 for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 05:37:49 -0800 (PST)
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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 v8l15tbYsEuU for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 05:37:47 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D815C130EDC for <netmod@ietf.org>; Thu, 22 Nov 2018 05:37:46 -0800 (PST)
Received: from localhost (h-39-108.A165.priv.bahnhof.se [213.136.39.108]) by mail.tail-f.com (Postfix) with ESMTPSA id D25371AE018C; Thu, 22 Nov 2018 14:37:45 +0100 (CET)
Date: Thu, 22 Nov 2018 14:37:45 +0100 (CET)
Message-Id: <20181122.143745.956867478908279019.mbj@tail-f.com>
To: jason.sterne@nokia.com
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <DB7PR07MB3978A22EA0FFF32725E37B639BDB0@DB7PR07MB3978.eurprd07.prod.outlook.com>
References: <VI1PR07MB3981A171F18213B030D289A79BD80@VI1PR07MB3981.eurprd07.prod.outlook.com> <CABCOCHQM9Y_+ENB_sFGDQ6NufGm=mBRU-Ns4xiLXddMWXTUO6w@mail.gmail.com> <DB7PR07MB3978A22EA0FFF32725E37B639BDB0@DB7PR07MB3978.eurprd07.prod.outlook.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/tKmrATkvO-gyI95kxk67H3W6LpY>
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 22 Nov 2018 13:37:49 -0000

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> 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 <andy@yumaworks.com>
> Sent: Monday, November 19, 2018 3:54 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
> Cc: NetMod WG <netmod@ietf.org>
> 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)
> <jason.sterne@nokia.com<mailto:jason.sterne@nokia.com>> 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
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod