Open abierman opened 5 years ago
From Wed meeting: don't fully understand the problem. Is this a duplicate of the "critical extension" issue? #49
No
There is no way to make an extension optional. There is no way to specify that the server does not implement an extension. The ticket is very clear on the issues
On Wed, Mar 27, 2019 at 7:24 AM Kent Watsen notifications@github.com wrote:
From Wed meeting: don't fully understand the problem. Is this a duplicate of the "critical extension" issue?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/netmod-wg/yang-next/issues/71#issuecomment-477179094, or mute the thread https://github.com/notifications/unsubscribe-auth/ABugj0--fKFAC6hkMZydv-Joq6r3x1kwks5va38IgaJpZM4cFqvh .
Consider NACM. If a server claims conformance to NACM (listed as an implemented module in yanglib) then is it allowed to ignore the default-deny-all extension? (server MAY ignore any extension)
If no, how does a server indicate that this extension is not supported? If yes, then how can an operator rely on NACM extensions?
this issue should be closed. the YANG Packages work should address any conformance/capabilities for some use-case
Does the following deviation work? deviation /a/b { deviate delete { myext:XXX "YYY"; } }
I agree that YANG Packages would be a good place to deal with conformance in general. For most part, I think the use/conformance requirements for extension statements are handled ok in RFC text (e.g. NACM implementors have to support it because the RFC speaks about them), but maybe there should be a way to find out in YANG Library or Packages etc.
Kent: config-false lists, YL, and/or packages could all be used to indicate which extensions are supported. Andy: deviate-delete seems like a easy fix Kent: are we trying to define conformance for the extension or uses of the extension
The conformance requirements and capabilities discovery for extension statements is broken and implementations do not follow it.
If a module contains extensions and a server advertises the implemented module in the YANG library, then the server must implement all extensions in the module.
There is no way to make if-feature a required sub-statement of an extension. There is no way to specify a deviation to an extension, even to deviate not-supported.
Not all extensions are meant for the server, and the server implementor just chooses some extensions in an ad-hoc, un-advertised manner, so the client tools do not know for sure which extensions will be supported or not