On Tue, Apr 19, 2022 at 1:26 AM Jan Lindblad <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
