Andy Bierman <a...@yumaworks.com> wrote:
> Hi,
>
> On Thu, Jan 18, 2024 at 12:34 PM Jason Sterne (Nokia) <jason.sterne=
> 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.
RFC 7950 defines a "lexical representation" of types. This is not
encoding-specific. However, section 9 says:
The lexical representation of a value of a certain type is used in
the XML encoding and when specifying default values and numerical
ranges in YANG modules.
/martin
> 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:
>
> V1:
>
>
> container oldway {}
>
>
> V2:
>
> choice wrapper {
> container oldway {}
> }
>
>
> The following changes are legal:
>
> 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):
>
> 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:
>
> 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.
>
>
> 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>
> > *Sent:* Thursday, January 18, 2024 3:19 PM
> > *To:* Jason Sterne (Nokia) <jason.ste...@nokia.com>; Reshad Rahman <
> > res...@yahoo.com>; Jan Lindblad <j...@tail-f.com>
> > *Cc:* 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>
> > *Sent:* giovedì 18 gennaio 2024 19:33
> > *To:* Reshad Rahman <res...@yahoo.com>; Jan Lindblad <j...@tail-f.com>;
> > Italo Busi <italo.b...@huawei.com>
> > *Cc:* 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>
> > *Sent:* Thursday, January 18, 2024 10:59 AM
> > *To:* Jan Lindblad <j...@tail-f.com>; Italo Busi <italo.b...@huawei.com>;
> > Jason Sterne (Nokia) <jason.ste...@nokia.com>
> > *Cc:* 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. 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 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> 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> *On Behalf Of *Jan Lindblad
> > *Sent:* Thursday, January 18, 2024 5:13 AM
> > *To:* Italo Busi <italo.b...@huawei.com>
> > *Cc:* 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 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>
> > *Sent:* giovedì 18 gennaio 2024 10:33
> > *To:* Italo Busi <italo.b...@huawei.com>
> > *Cc:* 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> 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
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> >
> > _______________________________________________
> > 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
> >
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
