Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

On Tue, Apr 19, 2022 at 1:26 AM Jan Lindblad <janl@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
>