DDSSEC11 — Need a way to determine the builtinTopic used for the DataWriter automatic liveliness

As described in 7.4.2 DDS-RTPS defines a the builtin ParticipantMessage topic used to carry two types of Liveliness messages:

DDS-Security (section 7.4.2) defines a ParticipantMessageSecure that is used to securely send liveliness data messages.

The Liveliness messages pertain two types of liveliness

• DataWriter Automatic Liveliness
• DataWriter Manual by Participant Liveliness

According to section 7.4.2 both the ParticipantMessage and the ParticipantMessageSecure builtin endpoints should be created but it is not clear whether for a specific DataWriter the liveliness messages should be sent over both or just one of them and if so which...

This will affect interoperability between vendors and also between an application using DDS-Security and one that is not.

The specification should clarify this.

Apply the modifications suggested in the issue description and comments

(1) If the Liveliness is "manual by Topic" then liveliness uses Hearbeat submessages associated with the regular DataWriter/DataReader channel so the protection is derived from the DataWriter meta-dataprotection kind. There is no other way to do this.

(2) If the Liveliness is "manual by Participant" or "automatic" then we would use the ParticipantMessage or ParticipantMessageSecure. In this case we could derive the behavior from the <enable_discovery_protection> setting on the Governance or add a <enable_liveliness_protection>.

For (2) it seems that tying the selection of the liveliness channel to the enable_discovery_protection would defeat having separate settings for <discovery_protection_kind> and <liveliness_protection_kind> so if we wanted that we should consolidate those two into single setting. So we would need to come up with some common concept for "discovery" and "liveliness" which is not so obvious what that would be.

Because of this it seems the simplest and most transparent would be to add a <enable_liveliness_protection> under <topic_rule>, and its associated is_liveliness_protected attribute under EndpointSecurityAttributes.

Also, we are adding a is_liveliness_protected attribute under ParticipantSecurityAttributes, so the "Liveliness Protection Kind" governance element has a clear mapping to a Participant attribute. We do this in a way that is consistent to other mappings (e,g., as the mapping for RTPS protection kind to is_rtps_protected).