Hello,
the NACM definition (rfc8341) does not give you an unrestricted Xpath for that path leaf. Here is the datatype definition from that RFC
typedef node-instance-identifier {
type yang:xpath1.0;
description
"Path expression used to represent a special
data node, action, or notification instance-identifier
string.
A node-instance-identifier value is an
unrestricted YANG instance-identifier expression.
All the same rules as an instance-identifier apply,
except that predicates for keys are optional. If a key
predicate is missing, then the node-instance-identifier
represents all possible server instances for that key.
This XML Path Language (XPath) expression is evaluated in the
following context:
o The set of namespace declarations are those in scope on
the leaf element where this type is used.
o The set of variable bindings contains one variable,
'USER', which contains the name of the user of the
current session.
o The function library is the core function library, but
note that due to the syntax restrictions of an
instance-identifier, no functions are allowed.
o The context node is the root node in the data tree.
The accessible tree includes actions and notifications tied
to data nodes.";
}
It mentions that the xpath should be an instance identifier expression, this is an xpath where any predicate is only of the form [keyleaf='value'], so that it exactly identifies a specific location in your model. The one difference is you can omit predicates to reference all elements in a list. More detail from the Yang RFC 7950 on the identityref datatype can be found here https://datatracker.ietf.org/doc/html/rfc7950#section-9.13
Given those restrictions you cannot do what you are trying to do in a single rule. Since you are trying to give access to an arbitrary set of devices, you will need a rule per device in the group.
You can use NSO services to generate NACM rules, so you could have a service with a leaf-list of type leafref, referring to device names, and use that service to generate the NACM rules in its template.
If its important to you to use the device group definitions, you could have the device-group name in your service only, but then I would also have a kicker that would also be created in the service template. This would cause the service to be re-deployed whenever the group is changed. That would ensure that on any group change, the NACM rules are updated even though the group definition is not located under your service within the model tree.
