In the PubSub spec I see a problem, with the
DataSetMessageSequenceNumber handling.

Table 81 – DataSetMessage Header Structure

"DataSetMessageSequenceNumber - UInt16:

A strictly monotonically increasing sequence number assigned by the publisher to
each DataSetMessage sent.
A receiver should ignore older DataSetMessage than the last sequence processed
if it does not handle reordering of DataSetMessages.
To determine whether a received DataSetMessage is newer than the last processed
DataSetMessage the following formula shall be used:

(65535 + received sequence number – last processed sequence number) modulo 65536

Results below 16384 indicate that the received DataSetMessage is newer than the
last processed DataSetMessage and the received DataSetMessage is processed.
Results above 49162 indicate that the received message is older (or same) than the last processed DataSetMessage and the received DataSetMessage should be
ignored if reordering of DataSetMessages is not necessary.
Other results are invalid and the DataSetMessage shall be ignored."

This handling is unnecessary, when security is enabled, and
can get really dangerous if a publisher gets reset then they will likely
start the sequence number again from zero, thus 49162 message can
get ignored. When message N has just been received, I would only
ignore N, and N-1 which is consistent with the two macro cycle exception
at:

Table 75 – Layout of the MessageNonce for AES-CTR:

"Subscribers shall reset the records they
keep for sequence numbers if they do not
receive messages for two times the keep
alive time to deal with Publishers that are out of
service and were not able to continue from the last used
SequenceNumber."