On Tue, Apr 19, 2022 at 1:26 AM Jan Lindblad <j...@tail-f.com> wrote:
> 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. > > +1 Classifying a change and encoding the classification into a semver does not actually fix anything. Only advancements in tooling and protocols will fix anything. There needs to be standardized warnings. 1) YANG compiler - standard extensions to trigger deprecation and NBC warnings - needed at the definition-level, not the module level 2) NETCONF and RESTCONF protocols - need standard error-tag to allow error-serverity=warning - need standard warnings reports As a developer, I want to see warnings about a specific issue, and suggestions on how to fix it, just like I get from my C++ compiler. The YANG language and YANG-based protocols are still quite primitive compared to modern tools. > Best Regards, > /jan > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod