Balázs, Qin, WG, >> - for each extension statement the following should be described >> + Changing this extension statement is a backwards-compatible change >> yes/no/editorial-only > [Qin Wu] Can you provide an example for this issue or reference document, I > can not find any guideline in RFC7950. > > BALAZS: It is the first question you get from a customer at any model > update/upgrade: are the changes backwards compatible? > The modeler and the customer needs to understand whether a change in the > extension statements is backwards compatible or not. > The new YANG versioning drafts also require this knowledge. > E.g. > Removing the nacm:default-deny-all extension from a leaf is backwards > compatible as all earlier operations will still work > Adding the nacm:default-deny-all extension to a leaf is not backwards > compatible as writing to the leaf might not work anymore.
This is a great example of why backwards compatibility is a really hard subject. A manager relying on nacm:default-deny-all might not be injecting the right NACM rules to make the managed system secure after the version change. While all management operations will succeed, the change opens up a security hole for managers unaware of the change. I believe such a change should not be described as backwards compatible. My point is that while in the YANG versioning design team are working to define hard and fast rules for what constitutes backwards compatibility, reality is a few magnitudes more complex than any viable rule set. Best Regards, /jan _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
