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

Ladislav Lhotka <lhotka@nic.cz> Thu, 22 November 2018 13:35 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 621F6130EE0 for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 05:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 921rMcWWrqiq for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 05:35:06 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DE13C130EDC for <netmod@ietf.org>; Thu, 22 Nov 2018 05:35:05 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 29A93182113B; Thu, 22 Nov 2018 14:42:32 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id AD2E7182113A; Thu, 22 Nov 2018 14:42:28 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, "Sterne\, Jason \(Nokia - CA\)" <jason.sterne@nokia.com>
Cc: NetMod WG <netmod@ietf.org>
In-Reply-To: <CABCOCHQM9Y_+ENB_sFGDQ6NufGm=mBRU-Ns4xiLXddMWXTUO6w@mail.gmail.com>
References: <VI1PR07MB3981A171F18213B030D289A79BD80@VI1PR07MB3981.eurprd07.prod.outlook.com> <CABCOCHQM9Y_+ENB_sFGDQ6NufGm=mBRU-Ns4xiLXddMWXTUO6w@mail.gmail.com>
Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, "Sterne\, Jason \(Nokia - CA\)" <jason.sterne@nokia.com>, NetMod WG <netmod@ietf.org>
Date: Thu, 22 Nov 2018 14:35:00 +0100
Message-ID: <87wop5kzgb.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/AhANiIiTVVMzsWrDO-XudNS134o>
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:35:09 -0000

Andy Bierman <andy@yumaworks.com> writes:

> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> 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.

This is not correct. A leafref path is a special XPath, and as such
includes only data nodes, i.e. NOT choice and case nodes.

What does change are schema node identifier. This could be significant
in an augment statement, but not ini this example because a leaf cannot
be augmented anyway.

I don't see anything else that could break, so Jason's change seems
backward compatible to me.

Lada

>
>
> 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
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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