Besides compiling the YANG model with the —export flag, you can also use the tailf:export statement in the YANG module. See ConfD UG Chapter “Hidden Data”. With NETCONF, the YANG 1.0 module is announced in the <hello> message, and the YANG 1.1 module is announced according to the RFC 8525 YANG Library.
If you need to hide/unhide a YANG module at runtime, you would need to do an in-service upgrade to apply changes of the above. See ConfD UG chapter “In-service Data Model Upgrade”.
Okay, so if I understand correctly, for any runtime control, we need to have two version of fxs files (one with netconf enabled, another without netconf) and then we can switch to particular version by in-service data model upgrade. (In our case we can even do this before starting confd for the first time)
There is no way to achieve the same with a single fxs file and then toggling export parameter via some maapi APIs. Right?
Our original problem is
Currently we use single set of fxs files in multiple platforms.
Transaction hooks gives error on any create/modify operation on a subtree depending on platform version at run time.
But northbound managers are using the capability information in hello message to discover supported services in the device.
So we are looking for any method to exclude those url lists from capability data. Is there any hook for the same within confd?
In CLI we can apply NACM reject rules to hide those subtrees from being rendered. I have not checked but I think that would not work with capability response.