There is no mapping of the logical ports indicated for the DDSI-RTPS Ethernet PSM

An application has no way of differentiating which port an Ethernet frame is directed to, and thus, there is no way to drop a frame directed to a port where the application is not listening.
This is especially important for the participant discovery messages, where filtering on the default multicast port should be used to prevent the discovery of participants in a different domain.

Prepending a header to the RTPS message with the source and destination logical ports (in network order) would allow an Ethernet transport to properly signal and filter the logical ports involved in the communication.

In Clause 7.2.2, the term "network topology description" seems odd. The text should probably refer to the deployment configuration model.

In Table 7.19, "DataFrameSpecification Definition", the second bullet point should only refer to UDP/IP, not "TCP/IP".

In Clause 8.2.2 should clarify that endpoints in the context of DDS entities refer to DataReaders and DataWriters, the term may confuse readers coming from different backgrounds.

In Clause B.1.2, the clarification on manual configurations that need to calculate a schedule should probably mention they need to calculate whether the requirements can be met (schedule may be a confusing term in that context).

In B.2.1.1, "Square Stream Configuration", the destination-mac-address in the status response should be "01-00-5E-7F-FF-01" (given the destination multicast IP address).

In B.2.1.2, "Triangle Stream Configuration", the destination-mac-address in the status response should be "01-00-5E-7F-FF-02" (given the destination multicast IP address).

Apply minor clarifications and enhacements

This resolution applies the suggested clarifications and enhancements.

IEEE 802.1Q has recently (as of 2022) incorporated several specifications that have been developed in parallel. That is the case of 802.1Qcc, which this specification heavily relies on, and 802.1Qcr. This is part of the regular process of IEEE.

At the time of publication of the revised submission, 802.1Q-2022 was being voted and finalized, so the Beta 1 version of DDS-TSN points to 802.1Q-2018, 802.1Qcc, and 802.1Qcr. We should update these references and point to 802.1Q-2022, which now includes both Qcc and Qcr.

Update references to 802.1Qcc and 802.1Qcr

As part of this resolution, we update references to 802.1Qcc and 802.1Qcr with references to IEEE 802.1Q (2022), which has merged these specifications into the core document.