In TAPI yang models leafrefs are used as refrerences between different branches of data tree which is not a semantics of a yang leafref (look at https://tools.ietf.org/html/rfc7950#section-9.9).
For example
tapi-connectivity@2018-02-16#46 -> g connection/connection-end-point is a single leafref whereas to uniquely identify connection-end-point you need cep_uuid + nep_uuid + node_uuid + topology_uuid
This is because in Yang all keys are local keys (identified by leafref xpath) and global uuid concept from TAPI cannot be directly represented in Yang.
Thus to properly represent a reference we need to either use leafref-tuples (composed keys) or instance-identifier. As in MEF Presto NRP we are planning migration to TAPI 2.x we had an internal conversation which we concluded with preference for leafref-tuples representation (this is the common way of doing that in Yang community due to our analysis)
In TAPI yang models leafrefs are used as refrerences between different branches of data tree which is not a semantics of a yang leafref (look at https://tools.ietf.org/html/rfc7950#section-9.9). For example tapi-connectivity@2018-02-16#46 -> g connection/connection-end-point is a single leafref whereas to uniquely identify connection-end-point you need cep_uuid + nep_uuid + node_uuid + topology_uuid
This is because in Yang all keys are local keys (identified by leafref xpath) and global uuid concept from TAPI cannot be directly represented in Yang.
Thus to properly represent a reference we need to either use leafref-tuples (composed keys) or instance-identifier. As in MEF Presto NRP we are planning migration to TAPI 2.x we had an internal conversation which we concluded with preference for leafref-tuples representation (this is the common way of doing that in Yang community due to our analysis)