Hi! > Andy Bierman <[email protected]> on Thursday, September 14, 2023 18:40: >> On Thu, Sep 14, 2023 at 9:05 AM Acee Lindem >> <[email protected]<mailto:[email protected]>> wrote: >>> On Sep 13, 2023, at 10:36, Ladislav Lhotka >>> <[email protected]<mailto:[email protected]>> >>> wrote: (...) >>> We have already seen cases that the update rules prevented fixing problems >>> in YANG modules in a straightforward way, and backward-compatible fixes >>> negatively affected module readability. This is inevitable until the >>> ecosystem of YANG modules stabilizes. That's why I think changing update >>> rules from MUST to SHOULD is appropriate - it should have been so from the >>> beginning. >> >> I wholeheartedly agree. We need to be able to fix YANG modules with NBC >> changes. I know of at least one implementation that support NBC changes for >> proprietary models with node-specific translation > > Some of us do not think a bugfix counts as an NBC change. > If the YANG definition is wrong and has been wrong from the start, then BC is > not important. > Fixing the YANG module so the definitions match the intent of the authors is > important.
I don't understand why the motivation for a particular change should come into play. Either the change is NBC or BC, whether it being a bugfix or not, and the text in RFC 7950 states how it should be handled. Although I am on the vendor side in this context, as a user I find it important to be notified if a change is NBC even if it is a bugfix. It is also important to be able to both publish and consume compatibility levels on dependencies and imports, e.g. recommended-min. > IMO this new draft is not really needed at all, since bugfix exceptions > should be allowed > and should have always been allowed. I was not involved when YANG was defined, so I know little to nothing of these discussions. What I follow is the actual text in the standard, and it does not discern between classes of motivation for changes (e.g. bugfix, feature) and how they should be allowed or not. -- Per _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
