Completed the following updates that have been identified thus far. Making edits to DMTN-102 on branch tickets/DM-20238 (see latest PDF here).
I'm not closing this ticket because there are other alerts-related updates happening which might prompt further changes to DMTN-102 (e.g., DM-19484, DM-20296, DM-20298, DM-20299, DM-22193).
(0) Everywhere the term "formal requirement" has been changed to "requirement". There are no informal requirements and I annoy myself with this "formal requirement" language.
(1) Recast the data rates section in (mega/giga) bits per second rather than bytes per second, for easier comparison with typical bandwidth units. In Section 2.4 "Alert Stream Data Rate", all quotes to Bytes per second have also been quoted in bits per second.
(2) Include an estimate of the size of the alert stream without the DIASource history or the postage stamps ("alert stream-lite"). Section 2.3 "Alert Packet Size" has been updated to quote the 27KB in savings (estimated by KT and posted by Colin, above) from dropping the history record from the alert packet.
(3) Update DMTN-102 to agree with the updates from RFC-600 and LCR 1883. Section 2.1 "Alert Release Timescale" has been reworded to reflect the recently updated wording of DMS-REQ-0004 and OSS-REQ-0127 (essentially the meaning is unchanged). Section 2.2 "Number of Alerts per Vist (and per Night)" has been reworded to match the recently added DMS-REQ-0393. Section 2.5 "Number of Selected Brokers" has been updated to reflect the recently added DMS-REQ-0391 requirement on the minimum number of full streams distributed (numStreams). Section 2.7 "Delayed/Failed Alert Distribution" has been updated to reflect the recently added DMS-REQ-0392 requirements that revise the meaning of sciVisitAlertDelay and sciVisitAlertFailure.
Copying in a discussion from #dm-sst, I think it would be useful to include an estimate of the size of the alert stream without the DIASource history or the postage stamps ("alert stream-lite"). Kian-Tat Lim's off the cuff estimate is: