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

Ladislav Lhotka <lhotka@nic.cz> Thu, 22 November 2018 13:59 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 47F32130ED9 for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 05:59:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 udo7xuDOdySK for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 05:59:11 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D80112EB11 for <netmod@ietf.org>; Thu, 22 Nov 2018 05:59:11 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 7F17A64235 for <netmod@ietf.org>; Thu, 22 Nov 2018 14:59:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542895148; bh=jBdeLLC7vFhBQR9blNfXu1+q3xNZ0hlQo3KThlgJfOg=; h=From:To:Date; b=pJGqK7mnO56hnB81S48TaDE+0O1Xt6sAu8k7/ei8EqdU9mGczJ/ulP1HmBnCLipDs gBooxK/aZbr4X2Bju9z9xy7bdRHz7mNJ+USanUCCIWijrG+jJotm7u8QJFTmbOTk2t GNS1S6HTjoN4Qu+2duHEt6cE3f+0ROsLpj32mFHY=
Message-ID: <378d35ce154cb00c390a55e6b88ceb21ca74ebf2.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: NETMOD WG <netmod@ietf.org>
Date: Thu, 22 Nov 2018 14:59:08 +0100
In-Reply-To: <20181122.143948.1543843065251732639.mbj@tail-f.com>
References: <VI1PR07MB3981A171F18213B030D289A79BD80@VI1PR07MB3981.eurprd07.prod.outlook.com> <CABCOCHQM9Y_+ENB_sFGDQ6NufGm=mBRU-Ns4xiLXddMWXTUO6w@mail.gmail.com> <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Wou1f8L4RfUgNs6coWI8Jc1Fi5I>
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:59:14 -0000

On Thu, 2018-11-22 at 14:39 +0100, Martin Bjorklund wrote:
> Hi,
> 
> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > 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.
> 
> Since it does change the schema tree, this is not legal according to
> 7950.  So in that sense it is not backwards compatible.  The rules in
> 7950 protect both clients and other modules that import the module.

Section 11 does not explicitly forbid changes that change schema node
identifiers. On the other hand, it contains this item:

   o  Any set of data definition nodes may be replaced with another set
      of syntactically and semantically equivalent nodes.  For example,
      a set of leafs may be replaced by a "uses" statement of a grouping
      with the same leafs.

I think this applies nicely to the current case: the modified schema is arguably
semantically equivalent to the old one.

Lada


> 
> /martin
> 
> 
> 
> > 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
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67