Jason, Scott,
Thanks for the follow-up
I understand that the impact on the schema path is causing the change to be
NBC, even if the impact on existing clients is minimal, and therefore the
guidance in appendix B.2 should be updated accordingly
However, as far as I can understand section 11 of RFC7951, removing the
mandatory statement from an existing leaf is considered a BC change:
o A "mandatory" statement may be removed or changed from "true" to
"false".
Therefore, it seems that a BC alternative option, pending some clarification
based on WG LC comments, is to add a when statement, as described in appendix
B.2:
container rlt-mode {
when "not(../mode)";
leaf num-bonded-carriers {
type uint32;
mandatory true;
}
leaf num-protecting-carriers {
type uint32;
mandatory true;
}
}
In this way, it is possible to indicate that the new leaf nodes are mandatory
only when the old leaf node is not present
An alternative possibility that has just jumped into my mind, is to allow both
old and new leaves to be reported (at least in the operational data store), by
adding a must statement instead of a when statement:
container rlt-mode {
must "../mode or ./num-bonded-carriers";
leaf num-bonded-carriers {
type uint32;
}
leaf num-protecting-carriers {
when ../num-bonded-carriers;
type uint32;
mandatory true;
}
}
In this case, when both old and new leaves are present, some consistency has to
be provided to avoid inconsistent information
What do you think/suggest?
Could these (or one of these) options be considered a BC change?
Thanks, Italo
From: Scott Mansfield <[email protected]>
Sent: venerdì 10 giugno 2022 21:36
To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>; Italo Busi
<[email protected]>; [email protected]
Cc: '[email protected]' <[email protected]>
Subject: RE: Another comment/question on appendix B.2 of
draft-ietf-netmod-yang-module-versioning-05
I don't want to re-litigate what backward compatible means.
In my case...
I have two modules: Module A and Module A'
I have instance data that works with module A and also with module A' (so the
new yang will support my current configuration).
When I leverage the new capabilities of module A', I can start from my
instances made for Module A and just add the stuff, that instance file will
only work if Module A' is supported (obviously).
But that has nothing to do with whether or not the YANG itself is considered BC
or NBC.
If mandatory is added, I understand that would be NBC, because there could be
working instance data that now no longer works because it is missing a
mandatory leaf. I also see the issue you bring up with the tree changing
depending on where the choice is used.
I think the exercise is to just get used to the terminology, and the draft does
a good job of clearly pointing out when something needs to be marked NBC.
Regards,
-scott.
From: Sterne, Jason (Nokia - CA/Ottawa)
<[email protected]<mailto:[email protected]>>
Sent: Monday, June 6, 2022 6:56 PM
To: Scott Mansfield
<[email protected]<mailto:[email protected]>>; italo.busi
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: '[email protected]' <[email protected]<mailto:[email protected]>>
Subject: RE: Another comment/question on appendix B.2 of
draft-ietf-netmod-yang-module-versioning-05
Another reason just occurred to me why moving the old leaf inside a "choice" is
NBC: it may not affect the data tree path to that element of instance data, but
it does affect the schema path to that element.
So if it was a container, for example, and some other module was augmenting
that container, the augmentation path would be broken if it was moved inside a
choice. I'm not certain that maintaining compatibility with an augmenting
module is a fundamental criteria but it certain is an impact to an ecosystem of
modules.
Of course all the above is for a fairly "strict" manner of defining backwards
compatibility. The actual impacts to a client of moving an old leaf into a new
"choice" (where other cases of the choice contain purely new elements that
didn't exist before) are often going to be minor to nothing. But the users of
the module would need to take a look at it.
This discussion is also making me realize that our text in B.2.3.1 may have a
mistake. An author can't stick the old leaf into a "choice" and be 100% BC so
we should probably remove that option.
Jason
From: Scott Mansfield
<[email protected]<mailto:[email protected]>>
Sent: Friday, June 3, 2022 3:06 PM
To: Sterne, Jason (Nokia - CA/Ottawa)
<[email protected]<mailto:[email protected]>>; italo.busi
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: '[email protected]' <[email protected]<mailto:[email protected]>>
Subject: RE: Another comment/question on appendix B.2 of
draft-ietf-netmod-yang-module-versioning-05
So basically, deprecating a leaf and adding a new leaf/container that replaces
the deprecated leaf will always be NBC.
Still the guidance in B.2 has the least impact and is easy to explain, and has
the added benefit that the tree doesn't change and existing (old schema)
instance data will work with the new schema.
-scott.
From: CCAMP <[email protected]<mailto:[email protected]>> On Behalf
Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: Thursday, June 2, 2022 5:03 PM
To: Italo Busi
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Cc: '[email protected]' <[email protected]<mailto:[email protected]>>
Subject: Re: [CCAMP] Another comment/question on appendix B.2 of
draft-ietf-netmod-yang-module-versioning-05
Hi Italo,
One problem I see with this change is that in the old data model, the leaf
"mode" had to exist in the instance data. But with the new model, it is valid
to have instance data with no "mode" leaf at all. That instance data would not
validate against the old YANG model.
I do see your point that any valid data that could be generated using the old
model is still accepted in the new model. But for the YANG versioning work
we've been pretty hesitant to diverge far from RFC 7950 for the list of what is
NBC vs BC (mainly just cleanup of the status deprecated & obsolete), and
clarifying
There are other possible cases that might meet a definition of "any old config
would be accepted by the new model" but we still don't label them as BC in our
YANG versioning work, e.g.:
- moving a pre-existing leaf into a new choice along with new elements in other
cases (like yours below but without any additional complications of "mandatory"
statements)
- changing the type of a uint8 to a union of uint8 and other types
Jason
From: netmod <[email protected]<mailto:[email protected]>> On
Behalf Of Italo Busi
Sent: Wednesday, June 1, 2022 6:07 PM
To: [email protected]<mailto:[email protected]>
Cc: '[email protected]' <[email protected]<mailto:[email protected]>>
Subject: [netmod] Another comment/question on appendix B.2 of
draft-ietf-netmod-yang-module-versioning-05
The example (in particular in point 3.1), assumes that it is possible to put
the old deprecated leaf and the new leaf within a choice to ensure that the new
node is not used when the old node is used
In the context of an update to RFC8561 (-00 I-D still under preparation) we
have found a similar care where the choice could also be beneficial to express
the requirement that the new node is mandatory when the old node is not used
(in other words either the old node or the new node MUST be configured)
You can find a simplified example of the change we were considering here:
https://github.com/samans/testing-yang/tree/main/mw-option<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-dc62b26de858ae3b&q=1&e=885085f0-90e5-462d-827c-73bc1e45f9fc&u=https%3A%2F%2Fgithub.com%2Fsamans%2Ftesting-yang%2Ftree%2Fmain%2Fmw-option>
The original (using the old style mode) is in
[email protected]<mailto:[email protected]>. the new version of
mode (rlt-mode) is in
[email protected]<mailto:[email protected]>
However, when we use pyang to check backward compatibility we get an error
message (see the nbc.out file in github):
[email protected]:47<mailto:[email protected]:47>: error: the
leaf 'mode', defined at
[email protected]:40<mailto:[email protected]:40> is illegally
removed
[email protected]:50<mailto:[email protected]:50>: error: the
mandatory node mode-option is illegally added
However, we have checked that the xml file mw-option.xml, which uses the
deprecated style of mode, works fine also with the new
[email protected]<mailto:[email protected]>. We therefore think
this type of change can be considered backward compatible since an old client
would not break when trying to configure a new server which implements the
deprecated node
We are therefore not sure whether this is a tooling issue or a specification
issue
Reviewing clause 11 of RFC7950 and draft-ietf-netmod-yang-module-versioning-05,
it seems that moving an existing leaf under a choice is not listed as a
backward compatible change
We are wondering whether draft-ietf-netmod-yang-module-versioning-05 could
clarify that this type of change can be considered backward compatible
We would appreciated any clarification by Netmod WG expert about whether this
change can be considered backward compatible or not
Thanks, Italo (on behalf of co-authors working on a new I-D for updating
RFC8561)
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
