-----Original Message----- From: netmod <netmod-boun...@ietf.org> On Behalf Of Jan Lindblad Sent: Tuesday, 19 April, 2022 10:26 To: Balázs Lengyel <balazs.lengyel=40ericsson....@dmarc.ietf.org> Cc: netmod@ietf.org; Qin Wu <bill.wu=40huawei....@dmarc.ietf.org> Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06
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 BALAZS2: Practically any change can cause operational problems if a client depends on it, still not saying anything about it will be a problem. Even if we only consider RFC7950 terminology: Is it allowed to change this extension: yes, no, in what manner? This should be stated. IMHO this is a great example of why we cannot consider all secondary effects of a change when considering compatibility. If we do, no change will be compatible. We should say allowed (compatible) changes are the ones that allow existing operations to succeed. _______________________________________________ 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
