Will clarify, but the goal was the server AddressSpace - since a FunctionalEntity can be any object (it only requires an interface, it is not possible to easily check the scope of the FE)

If the scope is the server AddressSpace then the only argument to have this method in the FunctionalEntity type/interface (and thus on each instance) is defeated.

Implementation of the method has no benefit from the fact that it's called on a specific instance.

Conclusion: this could have been a "global" method placed in FxRoot.

On the FE, there needs to be no checking - on the CM - which has to resolve the configuration NodeId, the BrowsePath starts at the FE. What I'm arguing against is any checking on the provided nodeId other then if it is found (and that the value matches what was passed in). The AC could have problems figuring out if it is in the ndoeId is in the FE. There is no reverse browse path and since the variables in an FE might be referenced by an organize reference (not a HasChild type reference - even walking back up the tree might not find the FE (It would be a lot of work the AC with no actual benefit) - FE can be nested - so it might be a variable in a child FE - basically the tree under an FE can be very wide and deep and figuring out if a nodeId is in it would be a very expensive operation - and if we expect an FE to report a nodeID that is not in the tree then every FE would have to do it for every verification node and that very expense operation make no sense.

The verify was designed to be quick and easy.

Updated text to indicate that the existence of the node and for variables the value is checked, not the location in the AddressSpace

reviewed changes in call, agreed to change, closed issue