Different encodings keep different amounts of type information. The RFC 7950 rules were written for the single encoding that did exist when RFC 7950 was published (even though RFC 7951 was on the radar but then the rules go back to RFC 6020 where we only had a stringified representation of values). A great example how collections of well intended extensions (or initial naiveness) results in technical complexity.
/js On Thu, Jan 18, 2024 at 03:58:57PM +0000, Reshad Rahman wrote: > Hi Jason, > I agree for the second case, and IIRC we did discuss that in the > yang-module-versioning context. > But the first case, I don't understand why it's NBC if there's a new type. > Encodings of the OLD types wouldn't change? > Regards,Reshad. > On Thursday, January 18, 2024, 09:36:46 AM EST, Jason Sterne (Nokia) > <[email protected]> wrote: > > > Hi guys, > > > > The second case is NBC. I remember wondering the same thing myself but the > type in OLD is foo which the type in NEW is union. That is NBC (and in some > encodings outside of XML, sending that leaf with type foo vs type union, > member foo would be different). > > > > OLD > > type foo; > > > > NEW > > type union { > > type foo; > > type bar > > } > > > > The first case is NBC if the addition of the new member adds a new type to > the list of members. So it depends on the underlying types of foo, bar and > baz. If they were all strings, for example, then it is BC. But if foo and > bar are “int” and then “baz” is a string, then adding that new member type > into the union is NBC. > > > > Jason > > > > From: netmod <[email protected]>On Behalf Of Jan Lindblad > Sent: Thursday, January 18, 2024 5:13 AM > To: Italo Busi <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] Is changing the type with union a BC change? > > > > | > > | > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > | > > > > > Italo, > > > > Yes, this too would be BC according to the rules. There may be some > situations where this kind of change might be disruptive in the real world, > however, for example if you did this to a list key. > > > > Best Regards, > > /jan > > > > > > > > > Thanks Jan > > > > Following the same logic, also the following change can be considered BC: > > > > OLD > > type foo; > > > > NEW > > type union { > > type foo; > > type bar > > } > > > > Is my understanding correct? > > > > Thanks again > > > > Italo > > > > From: Jan Lindblad <[email protected]> > Sent: giovedì 18 gennaio 2024 10:33 > To: Italo Busi <[email protected]> > Cc: [email protected] > Subject: Re: [netmod] Is changing the type with union a BC change? > > > > Italo, > > > > Yes, in my judgement this change should be considered BC according to YANG > rules. > > > > Note that the BC concept is a sort of *agreement* between client and server > implementors that determines what kind of changes a) are allowed + b) have to > be tolerated. Even when things are BC, that does not guarantee that things > will always keep interoperating properly. > > > > Best Regards, > > /jan > > > > > > > > > > > > > > On 17 Jan 2024, at 23:22, Italo Busi <[email protected]> > wrote: > > > > I have some questions/doubts about whether changing a type with union is a BC > or NBC change > > > > For example, is the following change a BC or NBC change? > > > > OLD > > type union { > > type foo; > > type bar > > } > > > > NEW > > type union { > > type foo; > > type bar; > > type baz > > } > > > > Section 11 of RFC7950 is silent on this case although this change is > expanding the allowed value space and therefore it looks like a BC change > > > > Thanks, Italo > > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
