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) <[email protected]>
Sent: giovedì 18 gennaio 2024 19:33
To: Reshad Rahman <[email protected]>; Jan Lindblad <[email protected]>; Italo
Busi <[email protected]>
Cc: [email protected]
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
<[email protected]<mailto:[email protected]>>
Sent: Thursday, January 18, 2024 10:59 AM
To: Jan Lindblad <[email protected]<mailto:[email protected]>>; Italo Busi
<[email protected]<mailto:[email protected]>>; Jason Sterne (Nokia)
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [netmod] Is changing the type with union a BC change?
You don't often get email from
[email protected]<mailto:[email protected]>.
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)
<[email protected]<mailto:[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]<mailto:[email protected]>> On
Behalf Of Jan Lindblad
Sent: Thursday, January 18, 2024 5:13 AM
To: Italo Busi <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[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]<mailto:[email protected]>>
Sent: giovedì 18 gennaio 2024 10:33
To: Italo Busi <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
