DDSSEC11 — Evaluation of data_tags when checking Permissions is unclear

A 'rule' in the Permissions document can include any number of <data_tags> elements. Each data_tags element contains one or more <tag> elements. For example

<publish>
  <topics><topic>A*</topic></topics>
  <data_tags>
     <tag>
          <name>a</name>
          <value>aVal</value>
     </tag>
     <tag>
          <name>b</name>
          <value>bVal</value>
     </tag>
  </data_tags>
  <data_tags>
     <tag>
          <name>a</name>
          <value>aVal</value>
     </tag>
     <tag>
          <name>c</name>
          <value>cVal</value>
     </tag>
  </data_tags>
</publish>

The spec should be more clear about the circumstances under which this will and will not match with the tags provided to the check_create_datawriter/reader() and check_remote_datawriter/reader() operations.

For example, would the above rule match a Writer with the following datatag qos:

 
{ { a, aVal } } 

or:

 
{ {a, aVal}, {b, bVal}, {c, cVal} }

Proposal:
Add the following statement to the last paragraph of 9.4.1.3.2.3:

For the data-tag criterion to match, the complete set of tags listed within one of the data_tags elements must match the complete set of data tags associated with the entity in question.

Clarify the matching criteria for partitions and data_tags

The matching criteria will be explained. All sections must match.

• The criteria for the sections within an "allow" rule is that the endpoint partitions/tags are a subset of the ones that are legal.
• The criteria for the sections within a "deny" rule is that the endpoint partitions/tags cannot overlap any of the ones listed as illegal.

Conservative defaults will be used when the section is not specified.
<partitions> within an allow rule defaults to the empty partition
<data_tags> within an allow rule defaults to no tags
<partitions> within a deny rule defaults to "*"
<data_tags> within a deny rule defaults to all tags