DDSIRTP26 — Note on the message wide CRC check

Using the header_extension submessage to pass the message's CRC seems to me the wrong place. It would be more logical to add the CRC at the end of the message for obvious reasons. First processing the whole potentially large message and then inserting the CRC somewhere in the front, requires extra resources. Also, this makes it unnecessary to first use zero's for the value of the CRC field while calculating the message's CRC. Adding the CRC just to the end of the message, maybe in a submessage of its own if you like, is a much better solution.

Moreover, the receiver has been designed in such a way that while processing a message it can hand off processed submessgaes right away, which is rather nice. With a message CRC ckheck, either in the header or the tail of the messgae, mitigates this feature since one first has to process the whole message before deciding if the message, and therefor the submessages, is valid. Iff some CRC checking should be implemented, do this at the level of a submessage.

With a 128 or just 64 bit CRC bit checksum, the designer clearly had huge message sizes in mind, which doesn't seem a good design decision to me.