Hey Pepe,
Speaking generally, both of these approaches are viable but I want to emphasize that having data types inside the public regulated data types repository is not a necessary prerequisite for using them. You probably have your own custom data types defined for your ROS2 packages/stacks; you are expected to have that in UAVCAN, too. Here’s an example of a vendor-specific DSDL namespace that doesn’t need to have anything to do with the public regulated data types repository to be useful:
I think we might benefit indeed from having a public regulated namespace inspired by the standard data types of ROS2, but before going this way I would encourage you to prototype this in a separate project first. You are not going to need fixed port-IDs for this anyway so there are absolutely no technical limitations expected.
Related: An exploratory study: UAVCAN as a middleware for ROS