I think it is useful to discuss both: 1. Clarity on what is allowed vs not-allowed by the RFCs (BC vs NBC). There is sometimes a need to make a binary decision (e.g. tool output, or knowing whether to apply the new NBC tag from Module Versioning) 2. Doing changes in a way that has lower impact on clients
Italo’s original questions seemed to be more about #1 so I was trying to make sure that part was clear. But #2 is also worth discussing and I agree that overlap of “old” + “new” is a good way to phase a change (i.e. allows some time where old clients can still access the old definitions, while new clients can start to use the new definitions). But IMO you’d probably want old & new to be mutually exclusive (i.e. server errors if a client tries to explicitly set both, and setting one does *not* cause the server to return the other). Jason From: Andy Bierman <a...@yumaworks.com> Sent: Friday, January 19, 2024 11:25 AM To: Jason Sterne (Nokia) <jason.ste...@nokia.com> Cc: Jason Sterne (Nokia) <jason.sterne=40nokia....@dmarc.ietf.org>; netmod@ietf.org; Italo Busi <italo.b...@huawei.com> 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. On Fri, Jan 19, 2024 at 8:00 AM Jason Sterne (Nokia) <jason.ste...@nokia.com<mailto:jason.ste...@nokia.com>> wrote: A previous post about one of these cases is here: https://mailarchive.ietf.org/arch/msg/netmod/yQSrlqFnrMEibLwuzMkyWt63kXQ/ From: netmod <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> On Behalf Of Jason Sterne (Nokia) Sent: Friday, January 19, 2024 9:16 AM To: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>> Cc: netmod@ietf.org<mailto:netmod@ietf.org>; Italo Busi <italo.b...@huawei.com<mailto:italo.b...@huawei.com>> Subject: Re: [netmod] Is changing the type with union a BC change? You don't often get email from jason.sterne=40nokia....@dmarc.ietf.org<mailto:jason.sterne=40nokia....@dmarc.ietf.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi Andy, What you’re describing here is types of changes that could be less impactful in many cases than other types of changes. And I agree that many of the examples you show are likely low impact for clients, but most of them are still officially NBC by RFC7950 rules IMO. Please see inline. I am interested in the operational impact of NBC changes on NC/RC deployments, not the boolean result: "Is this change BC or NBC according to RFC 7950?" If the YANG authors determine the "old way" is wrong and needs to be replaced, then what is the best way to do that? Can the "old way" and "new way" co-exist, and at what level of granularity? The "old client <--> new server" problem has been around forever. It's easy to clobber the model in a new revision such that "old client" stops working. This prevents a software upgrade on the devices that need the old client to keep working. The WG seems focused on the boolean BC vs. NBC issue, not the operational issues. Jason Andy From: Andy Bierman <a...@yumaworks.com<mailto:a...@yumaworks.com>> Sent: Thursday, January 18, 2024 4:43 PM To: Jason Sterne (Nokia) <jason.ste...@nokia.com<mailto:jason.ste...@nokia.com>> Cc: Italo Busi <italo.b...@huawei.com<mailto:italo.b...@huawei.com>>; Reshad Rahman <res...@yahoo.com<mailto:res...@yahoo.com>>; Jan Lindblad <j...@tail-f.com<mailto:j...@tail-f.com>>; netmod@ietf.org<mailto:netmod@ietf.org> 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<http://nok.it/ext> for additional information. Hi, On Thu, Jan 18, 2024 at 12:34 PM Jason Sterne (Nokia) <jason.sterne=40nokia....@dmarc.ietf.org<mailto:40nokia....@dmarc.ietf.org>> wrote: Hi Italo, IMO RFC7950 Section 11 makes the second case NBC (and I remember it being confirmed on this list in the past). It may not turn out to be impactful depending on the client design (and if only XML is used) but officially it is NBC. The type of the leaf is changing from whatever foo is, to type ‘union’. (even changes from uint8 to uint16 are NBC). I think RFC 7950 addresses only XML encoding of YANG data. CBOR encoding of a union would cause an NBC change only for protocols using CBOR. I prefer to focus on the backward compatibility at run-time. There are "soft" NBC changes that may break compile-time definitions but probably not run-time, especially if old-client and new-client are not both changing the same configuration data structures. The following change is not legal:[>>JTS:] Agree V1: container oldway {} V2: choice wrapper { container oldway {} } The following changes are legal:[>>JTS:] Agree (although there will be subtleties in how oldway behaves once you add newway – if it magically changes values when someone writes to “newway” then it may not really be NBC) V1: choice wrapper { container oldway {} } V2: choice wrapper { container oldway {} container newway {} } This allows old clients and new clients to coexist (better than just removing 'oldway'). But adding the choice wrapper changes the schema node path that may be used in augments or deviations. Creating the choice from the start would clutter YANG modules and add complexity. IMO this compile-time NBC change is worth it if enough deployment of 'oldway' exists. The same applies for a simple type changing to a union type. It is not always transparent. In C the order of the member types is irrelevant, but not in YANG. Safe (except for CBOR):[>>JTS:] It may often be low impact, but this is not allowed according to RFC7950. V1: leaf foo { type int8; } V2: leaf foo { type union { type int8; type declimal64; type string; } } Not safe since no member types after 'string' would ever match:[>>JTS:] And also NBC since the base type changes from string to union. V1: leaf foo { type string; } V2: leaf foo { type union { type string; type declimal64; type binary; } } IMO it should be OK to to place the original type anywhere in the member types. It may not be completely transparent within the implementation or the message encoding. [>>JTS:] NBC since the base type changes from string to union. V1: leaf foo { type string; } new V2: leaf foo { type union { type declimal64; type binary; type string; } } If old-client reads new values set by new-client then it may cause a problem, but probably not if it only reads values set by old-client. Some of those sections of 7950 are really focussed on XML encoding. But YANG is intended to work with other encodings (and some of those may not encode foo in and out of a union in the same way). They only apply to XML. Any extrapolation or new rules are post-7950. Jason Andy From: Italo Busi <italo.b...@huawei.com<mailto:italo.b...@huawei.com>> Sent: Thursday, January 18, 2024 3:19 PM To: Jason Sterne (Nokia) <jason.ste...@nokia.com<mailto:jason.ste...@nokia.com>>; Reshad Rahman <res...@yahoo.com<mailto:res...@yahoo.com>>; Jan Lindblad <j...@tail-f.com<mailto:j...@tail-f.com>> Cc: netmod@ietf.org<mailto:netmod@ietf.org> Subject: RE: [netmod] Is changing the type with union a BC change? Hi Reshad, Jason, Jan, Thanks for your replies I have found these pieces of text in sections 9.12 and 11 which might be interpreted as stating that the changes to the union are BC: When generating an XML encoding, a value is encoded according to the rules of the member type to which the value belongs. When interpreting an XML encoding, a value is validated consecutively against each member type, in the order they are specified in the "type" statement, until a match is found. The type that matched will be the type of the value for the node that was validated, and the encoding is interpreted according to the rules for that type. <…> The lexical representation of a union is a value that corresponds to the representation of any one of the member types. <…> The canonical form of a union value is the same as the canonical form of the member type of the value. <…> o A "type" statement may be replaced with another "type" statement that does not change the syntax or semantics of the type. For example, an inline type definition may be replaced with a typedef, but an int8 type cannot be replaced by an int16, since the syntax would change. Given these definitions I am wondering whether having a different encoding between the union and its member types is a valid encoding according to RFC7950 If this is the case, my feeling is that both examples can be considered BC changes at least when the base types are the same (e.g., type foo, bar and baz are all strings) Italo From: Jason Sterne (Nokia) <jason.ste...@nokia.com<mailto:jason.ste...@nokia.com>> Sent: giovedì 18 gennaio 2024 19:33 To: Reshad Rahman <res...@yahoo.com<mailto:res...@yahoo.com>>; Jan Lindblad <j...@tail-f.com<mailto:j...@tail-f.com>>; Italo Busi <italo.b...@huawei.com<mailto:italo.b...@huawei.com>> Cc: netmod@ietf.org<mailto:netmod@ietf.org> Subject: RE: [netmod] Is changing the type with union a BC change? It was subtle and I can’t remember the exact reasoning (or section of RFC7950) but I think Martin pointed it out. Basically: adding another member to a union that already has members of that same type doesn’t change the possible encodings or storage types. But adding a new member with a new/different type (that wasn’t part of the union previously) suddenly introduces the possibility of a new type for that leaf. So it kinda falls under “don’t change the base type(s)”. From: Reshad Rahman <reshad=40yahoo....@dmarc.ietf.org<mailto:reshad=40yahoo....@dmarc.ietf.org>> Sent: Thursday, January 18, 2024 10:59 AM To: Jan Lindblad <j...@tail-f.com<mailto:j...@tail-f.com>>; Italo Busi <italo.b...@huawei.com<mailto:italo.b...@huawei.com>>; Jason Sterne (Nokia) <jason.ste...@nokia.com<mailto:jason.ste...@nokia.com>> Cc: netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] Is changing the type with union a BC change? You don't often get email from reshad=40yahoo....@dmarc.ietf.org<mailto:reshad=40yahoo....@dmarc.ietf.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for additional information. 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) <jason.sterne=40nokia....@dmarc.ietf.org<mailto:jason.sterne=40nokia....@dmarc.ietf.org>> 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 <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org>> On Behalf Of Jan Lindblad Sent: Thursday, January 18, 2024 5:13 AM To: Italo Busi <italo.b...@huawei.com<mailto:italo.b...@huawei.com>> Cc: netmod@ietf.org<mailto:netmod@ietf.org> 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<http://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 <j...@tail-f.com<mailto:j...@tail-f.com>> Sent: giovedì 18 gennaio 2024 10:33 To: Italo Busi <italo.b...@huawei.com<mailto:italo.b...@huawei.com>> Cc: netmod@ietf.org<mailto:netmod@ietf.org> 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 <Italo.Busi=40huawei....@dmarc.ietf.org<mailto:Italo.Busi=40huawei....@dmarc.ietf.org>> 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 netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
