I want to create a model with a list. And make only some of the list items visible by default. And use “unhide” to show the rest of the data. As I understand tailf:hidden could be applied only to a hole YANG scheme element, so I’m thinking to create some dedicated node with “tailf:hidden” annotation and programmatically check if the “unhide” have been called by the user.
Should I do that way?
Is there a more “confd-ness” way to do that?
Is the idea to hide/unhide elements of the list good or there is some better design decision?
(I need some of the items to be visible only to the advanced users/technicians)
That does not sound like the ideal approach. Let me try to rephrase what are you trying to be sure I understand: you want to provide (or not provide) nodes based on a state of another node. That is needlessly complicated and perhaps even impossible, there are other options:
Note that the argument to tailf:hidden is a so called “hide group”, and an argument to the unhide command is again a hide group; so if you apply tailf:hidden with the same hide group to multiple nodes, unhiding the hide group works for all those nodes.
If your overall idea is that some users simply should not have access to a certain set of nodes, then you better have a look at access right management.
I want a part of the network interfaces to be visible only to the authorized (staff) users. And keep follow RFC (“urn:ietf:params:xml:ns:yang:ietf-interfaces”): to have /interfaces with known structure. I can create additional leaves for the hidden interfaces but in that case, they will not fit the scheme defined in the RFC.
What is a suggested approach?
As I’ve understood AAA has no option to hide some elements in the list.
I want to keep the exact RFC model but hide certain items (network interfaces) in the /interfaces list (for regular users)
I’ll re-read the user guide and will check, thank you. But if it isn’t possible I’ll augment the model, but I do not want to augment it because that could potentially break future compatibility with some third-party software which relies on RFC.
Just a point to augmenting: creating your custom module that augments a standard module is perfectly RFC-compliant. Note that the new elements belong to your namespace, and any RFC-compliant management software must ignore elements from unknown namespace.
The situation is obviously different if the communication protocol is, say, CLI, where there usually are no namespace declarations; but then again, CLI client can hardly be called RFC-compliant - there are no RFCs for this, as far as I know.