Return-Path: 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 7F048130E0A for ; Mon, 19 Nov 2018 12:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com 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 QEdhneyUADhq for ; Mon, 19 Nov 2018 12:54:01 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44121130E5A for ; Mon, 19 Nov 2018 12:54:01 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id u18so22330216lff.10 for ; Mon, 19 Nov 2018 12:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=csKo1cGXew/IOgikcMenGRSL1zEORFavcJK6duaelYk=; b=cE7NXhscmZJ2dUMSBmRVplAZV1vTPqCvGz+QyvDM30rXcHeniQEoP6Yw9xyzfNjjbN agFueLb1uvF7nVEae2tf8NM7Qiz08i5oaIUxwvWrPOFmuIL8/rZ4ZbXPcVlFjqmaPEHU 4HU7PjUxXBD2v8vg7JE1N6gZ/Zz020xTMgy3Zex65HQdV87Ta7d5uH5/eJsIdWMhNUpL RBqcXw18HG8SLFLn4OzPGekbRy6W/4GL/U2suDsuI6PQTunXtCLG/oHKB0n2G5biOzb+ OUB0o0KWEag+FzuMKjqYn6/QXTzc6wbqDcoWYd9z/CQLEY7jnSk/TLIoIeGddll2If/C raeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=csKo1cGXew/IOgikcMenGRSL1zEORFavcJK6duaelYk=; b=kGFYRPK8qal2DeYJHc0U+q9uIe5Ez5vQ1UXvFvm36g/USfLyU/arQffQjCrFeu7hhR ucfEHXjRoIXHlskt56yzojuCo2dz/HKizfnu22KlkTmbPYUpQneefJ6vtezXrj4jMD/2 +1j1gftHavgBvxqzNBoI5pKMSKElrlMaG4HegrfgjRSWq36Xwklmz86OwpsNr9k61F9d mYVMYfPqI8lFU8b8kjSKdirAIVYirpTAmn96XWDGDAd+YPJLzN+SdJLvEgHCyN+32zC1 McZyf6fuUPo9AM5rEkCH45lRIDL1vCIy+tUJ8HkkGH3ZuoQHZlF3WqjoBQfhAKOKynXm VPlw== X-Gm-Message-State: AGRZ1gLQnEchTVqtOcXuT6TKOdGmwpYrNpjJuIrpvDm67JZKZ/0g59T3 F0VGhoUd4Y1VIanRjye/jEv4hyatm0d0/NQ/Zyod0lmf X-Google-Smtp-Source: AJdET5cmqblm/4C61OVocSRysoj1jhooLERsa3LutXQsDrw5bxtWo9j3pURXIkcMuePPIbEqEOpQppgRHQSwxFbocg4= X-Received: by 2002:a19:690d:: with SMTP id e13mr11590717lfc.84.1542660839242; Mon, 19 Nov 2018 12:53:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Mon, 19 Nov 2018 12:53:47 -0800 Message-ID: To: "Sterne, Jason (Nokia - CA)" Cc: NetMod WG Content-Type: multipart/alternative; boundary="0000000000005513c9057b0ab7f0" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 20:54:11 -0000 --0000000000005513c9057b0ab7f0 Content-Type: text/plain; charset="UTF-8" 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. 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 > --0000000000005513c9057b0ab7f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:

Hi all,

=C2=A0

If we have a YANG model with a = leaf:

=C2=A0

MODEL VERSION 1:<= /span>

container my-model {<= /u>

=C2=A0=C2=A0=C2=A0 leaf a { typ= e string; }

}

=C2=A0

And then later we produce anoth= er version of the model where that leaf is placed into a choice construct:<= u>

=C2=A0

MODEL VERSION 2:<= /span>

container my-model {<= /u>

=C2=A0=C2=A0=C2=A0 choice some-= choice {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 case x {

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0leaf a { type string; }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0 }<= /u>

}

=C2=A0

Is that considered a non-backwa= rds-compatible change?







<= div class=3D"m_-71832675242669823m_6141564456552465457WordSection1">

MODEL VERSION 3:<= /span>

container my-model {<= /u>

=C2=A0=C2=A0=C2=A0 choice some-= choice {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 case x {

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0leaf a { type string; }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 case y {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf b { type string; }<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0 }<= /u>

}

=C2=A0

A client 'foo' using VE= RSION 1 would still be able to set & read back leaf a in the same way a= s it always did.

=C2=A0

But if another client 'bar&= #39; (using VERSION 3) sets leaf 'b', then leaf 'a' would d= isappear. That could be surprising to client 'foo' although perhaps= no more surprising than if another client simply deletes leaf 'a' = (using VERSION 1).

=C2=A0

Jason

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--0000000000005513c9057b0ab7f0--