Tom,
> On Feb 9, 2022, at 12:07 PM, t petch <ie...@btconnect.com> wrote: > > On 07/02/2022 17:42, Jeffrey Haas wrote: >> If an implementation, for whatever reason, couldn't support the items that >> were covered under the new if-feature, they would have already deviated them >> away. > > I do not understand. The case that concerns me is an implementation written > to RFC9127 that knows the rules for backwards compatibility and so knows what > it can rely on when a revised module of the same name is found. Except, > AFAICT, it cannot because we are breaking the rules and giving the user > little or no help in this I-D to work out why their software no longer works. Actual implementations need to ship modules that document their augmentations and deviations. This is the current state of things. If a mythical implementation of a module was unable to support a given leaf in this module, a deviation would have been created for it. In the specific example we're discussing, the only thing changing is how optionality based on a given implementation's support or lack of support of those leafs can be done: - If that implementation previously supported all of the newly conditional if-feature nodes in its uses of that module, it will need to announce the feature. - If that implementation previously didn't support the newly conditional leafs, it would have already had a deviation module for them. Now it does not need the deviations, but needs to NOT announce the feature. It is right to call out that the announcement of the feature could have impact since it's a change of behavior. But so is the simple fact that an implementation would have had to adjust what it ships for its deviations as well. No ecosystem of yang modules for a given implementation is going to ship without the understanding that it's the entire bundle of things - including features announced in the protocol - that make up how the schema are used. Original bundle: You deviated, if you needed to. New bundle: You advertise the feature, or not. A given implementation may change its mechanism from one bundle to the next, but in this specific example the outcome is the same. Had this been to change actual schema nodes from one bundle to the next, the case would have been interesting. > > As Jan said, we have not done this before and are in uncharted territory. I > think we should be more helpful. And the NETMOD WG or the YANG doctors, or > both, need to produce guidelines ready for the next time. The guidance suggested in prior working group meetings years ago largely still apply: No module lives in isolation. The interesting dialog will continue to be about how you handle versioning of the sets of interdependent modules along with mechanisms like features which are dynamic. -- Jeff
