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 The original (using the old style mode) is in [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: error: the leaf 'mode', defined at [email protected]:40 is illegally removed [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]. 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
