Hi,
On Thu, Jan 18, 2024 at 12:34 PM Jason Sterne (Nokia) 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
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,
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 v
Hi all,
RFC8526 NETCONF NMDA extensions includes a max-depth parameter described as
follows:
description
"For each node selected by the filters, this parameter
selects how many conceptual subtree levels should be
returned in the reply. If the d
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/diff
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).
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, Ja
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
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
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
Sent: giovedì 18 gennaio 2024 10:33
To: Italo Busi
Cc: netmod@ietf.org
Subject:
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 no
11 matches
Mail list logo
