DDSSEC11 — Should differences in EndpointSecurityAttributesMask prevent matching?

http://issues.omg.org/browse/DDSSEC11-38 introduced an EndpointSecurityAttributesMask that is propagated by Discovery within the PublicationBuiltinTopicData and SubscriptionBuiltinTopicData. This has the bit fields:

is_access_protected	
is_discovery_protected	
is_submessage_protected	
is_payload_protected	
is_keyhash_obfuscated	
is_liveliness_protected	

So a participant only knows that a remote participant will "protect" the payload. But not the details of the protection. This is consistent with the fact that at the PIM level the DDS core only knows whether it needs to call the "encods_serialized_data" but not what this call does. It is the detail of a specific plugin (in our case the builtin ones) that has the knowledge of the SIGN versus ENCRYPT 'protection kinds'

Currently the specification does not say whether matching should be allowed between endpoints that have different EndpointSecurityAttributesMask. This should be clarified.

Moreover it seems it would not be possible with the current mechanisms to enforce that if a DataReader expects ENCRYPT, then it should get that rather than just SIGN. In principle this is something that could be enforced by the check_local_dataXXX_match operations. But it does not appear they get the information they need to make that determination.

Define Mechanism for Matching Plugin Specific Attributes

Define Mechanism for Matching Plugin Specific Attributes.

Proposal: reserve a set of opaque bits on the endpoint security attributes mask to be used by security plugins.

Also we are fixing in this issue an inconsistency between DDSSEC11-38 and DDSSEC11-72 (is_key_protected).

NOTE: not adding information about origin_authentication as it should not prevent endpoint matching.
Why is that? If the governance states that a Topic should have origin authentication I may be reasonable for a Reader to insist on that. Otherwise any data it accepts from that DataWriter would lack that and it would defeat the purpose of the configuration in the governance.
I thought we wanted the writer to decide, but I see your point, I'm adding it