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

Martin Bjorklund <mbj@tail-f.com> Thu, 22 November 2018 14:00 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 5CEAC130ED9 for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 06:00:30 -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 H0XQYTbH5-y5 for <netmod@ietfa.amsl.com>; Thu, 22 Nov 2018 06:00:28 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4863A12EB11 for <netmod@ietf.org>; Thu, 22 Nov 2018 06:00:28 -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 7780F1AE018C; Thu, 22 Nov 2018 15:00:27 +0100 (CET)
Date: Thu, 22 Nov 2018 15:00:27 +0100 (CET)
Message-Id: <20181122.150027.823800945772964674.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: lhotka@nic.cz, jason.sterne@nokia.com, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHS18StYKGC4f7cPWFraKNHRsC9cWfrmfZ0j773awdicvQ@mail.gmail.com>
References: <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com> <CABCOCHS18StYKGC4f7cPWFraKNHRsC9cWfrmfZ0j773awdicvQ@mail.gmail.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/rrMLSBY1ymmyYqDz4DrraGAMM9A>
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 14:00:30 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund <mbj@tail-f.com> 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.
> >
> >
> This text is confusing wrt/ schema tree vs data tree:
> 
> 
> 9.9 <https://tools.ietf.org/html/rfc7950#section-9.9>.  The leafref
> Built-In Type
> 
>    The leafref built-in type is restricted to the value space of some
>    leaf or leaf-list node in the schema tree and optionally further
>    restricted by corresponding instance nodes in the data tree.  The
>    "path" substatement (Section 9.9.2
> <https://tools.ietf.org/html/rfc7950#section-9.9.2>) is used to
> identify the referred
>    leaf or leaf-list node in the schema tree.  The value space of the
>    referring node is the value space of the referred node.

Yes, it should be "data tree" in both occurrences.



/martin


> 
> 
> 
> 
> 
> >
> > /martin
> >
> >
> 
> Andy
> 
> 
> >
> >
> > >
> > > 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
> > >
> >