Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
Martin Bjorklund wrote:
> Hi,
>
> "Sterne, Jason (Nokia - CA/Ottawa)" 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?
>
> Not accordning to current RFC 7950 rules, since it changes the schema
^
I meant, "Yes, accordning to current RFC 7950 rules this is not
allowed". But I think you got that.
/martin
> node path (suppose the leaf was a container, and someone had augment
> /my-model/a).
>
> > 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).
>
>
>
> /martin
>
> ___
> 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
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.ste...@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
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
Thanks. I forgot that the choice is in the *schema* path (was thinking about
the instance data path which doesn't include the choice or case statements).
> -Original Message-
> From: Martin Bjorklund
> Sent: Monday, November 19, 2018 3:46 PM
> To: Sterne, Jason (Nokia - CA/Ottawa)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC
> change?
>
> Hi,
>
> "Sterne, Jason (Nokia - CA/Ottawa)" 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?
>
> Not accordning to current RFC 7950 rules, since it changes the schema
> node path (suppose the leaf was a container, and someone had augment
> /my-model/a).
>
> > 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).
>
>
>
> /martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
Hi,
"Sterne, Jason (Nokia - CA/Ottawa)" 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?
Not accordning to current RFC 7950 rules, since it changes the schema
node path (suppose the leaf was a container, and someone had augment
/my-model/a).
> 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).
/martin
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
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?
Does the answer depend on whether the choice contains other cases (or other
cases that are the default case)?
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
