This is as the Network adhoc and YAML WG designed it. It is the goal of TOSCA to abstract IaaS and in terms of application software the knowledge of hardware (e.g., in this case NICs) is abstracted as the result (if successfully connected) is a "Port".

Working as designed.

But doesn't this generate confusion?
Doesn't "port" usually have another meaning?
When I read port I imagine port 80 or a "port on a NIC".
The meaning in the description is NIC.
Could another name be better to obtain the abstraction needed?
I do not understand why we need to call the NIC with a different name and with the one already used for the port.

I'm sorry !!
I've had a talk with a friend of mine that is a network sysadmin and I finally understood the problem.
I'm more on the application side so I reason more at a level 4 of OSI and for me port is the TCP port.

I see now that the node name comes from the most commonly used term in the Level 2/1 OSI that is the "port of a switch or the port of the NIC".

We live in the IT world where overload of terms is usual but many times is confined to a scoped environment where people talk all the same slang so network people understand each other; unfortunately this standard goes from very low level things to application stuff, collecting all the overloads we have.

Said that now I have a more clear idea and stated that I'm not a network guy, my question is:
Since the standard needs to talk to a set of subjects that could have the same confusion, is there a way to avoid the ambiguous overload (not only on this subject, but even if potential future issues)?
My concern is the "usability of the standard": who is the subject that we think will be writing a TOSCA file? At the moment highly skilled people with multi competency in design the deployment of a complex system. How we plan to ease this job? The risk is that no one will want to use it (talk form a customer perspective)

Revising the YAML standard I can see that we use "port" in both concepts and this is not good.
Overloading apart we cannot have the same work in the same document mean two different things (at least not in a standard).
Since the most known "application" approach give to "port" the meaning of an endpoint of communication in an operating system.
As such this should be part of the OS node and not of the compute.
The "physical port connector" in my opinion should not be part of the spec since we have no interest in mapping the connector, but we are interested in mapping the Network Interface Controller that has a lifecycle of its own and can be a virtual thing that gets attached to the Compute node and has a multiplicity of 0..n
This would also help the networking part of the standard since if I have to define that I want 3 NIC on a Compute node the only approach I have is defining 3 NIC nodes to relate to the Compute