DDSSEC11 — Inconsistency in SubMessage and SubMessageElement naming throughout document

Most of the original list of points were addressed as part of the FTF2.
The remaining two points are copied below:
----------------------------------------------------
7.3.7 – missing section for SecuredPayload SubmessageElement
Or, [and i think this is better], replace everywhere SecuredPayload with
SecureDataBody. Then, add a section in 7.3.7 for SecureDataBody.

----------------------------------------------------
7.3.6.2 RTPS Submessage: SecureSubMsg
Figure 5 does not show SecureSubMsg.
Should SecureSubMsg be removed?
Or maybe it should be used only as a 'generic' term.
SecureSubMsg is referenced many times in
"Section 8.8.10 Cryptographic Plugins encoding/decoding behavior".
Because of this, it might be good to define 'SecureSubMsg' as
the sequence [ SecurePrefix + SecureBody|SerializedSubMsg + SecurePostfix ].
Does that work?

=======================================================
Original list of points is below
=======================================================

----------------------------------------------------

7.3.7.4 SecureDataTag Element
Typo in second para:

The UDP/IP wire representation for the SecuredPayload shall be:

Should be

The UDP/IP wire representation for the SecuredDataTag shall be:

Gerardo: Fixed in AB errata
----------------------------------------------------

7.3.7.8 SecureRTPSPrefixSubMsg Submessage

Is it true that it contains SecureDataTag?
It should contain a SecureDataHeader, I think.

Gerardo: Fixed in AB errata
----------------------------------------------------

Mention of TransformationKeyId (section 9.5.2.5) and
CryptoTransformationKeyId (section 9.5.2.1.1) should
be CryptoTransformKeyId

Gerardo: Fixed in AB errata
----------------------------------------------------

9.5.2.4 DDS:Crypto:AES-GCM-GMAC SecureDataBody

Second paragraph "SecureDataTag" should be "SecureDataBody".

The IDL does not include the 'struct' typename:

@Extensibility(FINAL_EXTENSIBILITY)
struct

;

Gerardo: This was already fixed by 182

----------------------------------------------------
9.5.2.5 DDS:Crypto:AES-GCM-GMAC SecureDataTag

The IDL shows receiver_mac is octet[8], but I think
it should be octet[16]. 16 bytes is consistent with the
format shown in 9.5.3.3.4.3.

Gerardo: Fixed in AB errata
----------------------------------------------------
7.3.7.8 SecureRTPSPrefixSubMsg Submessage

Message structure shows contents as SecureDataTag. Should be
SecureDataHeader.

Gerardo: This was already fixed by 182
----------------------------------------------------

7.3.7 – missing section for SecuredPayload SubmessageElement

Or, [and i think this is better], replace everywhere SecuredPayload with
SecureDataBody. Then, add a section in 7.3.7 for SecureDataBody.

Gerardo: Too big a change for AB Errata. Push to RTF
----------------------------------------------------

7.3.6.2 RTPS Submessage: SecureSubMsg

Figure 5 does not show SecureSubMsg.
Should SecureSubMsg be removed?
Or maybe it should be used only as a 'generic' term.

SecureSubMsg is referenced many times in
"Section 8.8.10 Cryptographic Plugins encoding/decoding behavior".

Because of this, it might be good to define 'SecureSubMsg' as
the sequence [ SecurePrefix + SecureBody|SerializedSubMsg + SecurePostfix ].
Does that work?

Gerardo: Too big a change for AB Errata. Push to RTF
----------------------------------------------------
7.3.7.5 SecureBodySubMsg Submessage

Mentions SecureSubMsg, but should be SecureBodySubMsg

Gerardo: Fixed in AB errata
----------------------------------------------------

7.3.7.6 SecurePrefixSubMsg Submessage

Mentions SecureSubMsg, should be SecurePrefixSubMsg

Gerardo: Fixed in AB errata
----------------------------------------------------

7.3.7.7 SecurePostfixSubMsg Submessage

Mentions SecureSubMsg, should be SecurePostfixSubMsg

Gerardo: Fixed in AB errata

Rename SecureDataHeader, SecurePayload, SecureDataTag

Rename the following submessage elements:
SecureDataHeader -> CryptoHeader
SecuredPayload -> CryptoContent
SecureDataTag -> CryptoFooter