We need to clarify that the IP Address is the Source address for unicast and it is the Destination Address for multicast.

TBD
Is it allowed to have the same address on different connections?

When working with UDP unicast, the Address of PubSubConnections is an address (hostname, port) of the communication partner. This information is enough for sending (publishing) datagrams via UDP socket. However, it's not enough for receiving (subscribing).
First, to be able to receive anything on a socket, we have to bind it to the local port (and optionally also to the local interface). Then after the datagram is received, the Address of the PubSubConnection can be used as a filter on the source address of the received datagram.

The missing part is a local port to bind to. This could be specified on a per connection basis, but in this case, all connections on one host would need to have unique ports assigned. I think it's better if there is one local port shared by all unicast connections.

One improvement to the previous comment:

It was: "I think it's better if there is one local port shared by all unicast connections."

Should be: "I think it's better if there is one local port shared by all unicast connections inside the same application. Each application may have its own local port (but don't have to)."

And one more comment coming from actual prototyping of an application that is both publisher/subscriber and has both unicast/multicast connections.

I'm not sure if it's worth mentioning in the spec, but from a perspective of one application, if it hosts both unicast and multicast PubSubConnections, the local port used by unicast connections for listening (the thing which I recommend to be specified in my previous comments), has to be different from any of the ports among all multicast connections addresses.

Otherwise I think it's impossible to implement it using the socket API.

The issue is resolved since a while in Part 14 drafts but there is on last open discussion point of using the same port for unicast and multicast traffic.

Comment from David Smith (FLC WG):

I disagree, The source port of the publisher should be noted as ephemeral, or configured differently for each publisher network message group, and the destination port of the subscribers should use the standard 4840 port.

The subscriber will be able to distinguish the packet from the source port and IP, or it may not care where it came from and only rely on the group ID in the pubsub headers. In the L2 Ethernet mapping, source ports and IP addresses don’t exist, so group ID at the application layer is needed to differentiate data.

A second consideration is that for firewalls having mandatory non-standard destination ports is a nightmare for useability as the end user needs to configure a range that will be used instead of one specific port. This puts a huge hole in the firewall, and can be a configuration change management problem when they need to add connections and fail to update the firewall config to allow new connections.

Discussed remaining issue with using same port for unicast and multicast in the meeting today.
We use the same port as default.

Agreed to changes in Part 14 1.05.1 Draft 37.