Fix Version/s: None
This ticket is to capture requested updates to DMTN-102 that come out of the Community Broker Workshop.
First, to recast the data rates section in (mega/giga) bits per second rather than bytes per second, for easier comparison with typical bandwidth units.
- relates to
DM-19484 Estimate distribution of alert packet size based on scientific considerations
- To Do
Make DMTN-102 linguistically compliant with
RFC-600 (e.g., distributed vs. transmitted).
Wait until that LCR is accepted and implemented before incorporating new wording into the Alerts Key Numbers.
Delaying the start of work on this ticket, as the Alerts Key Numbers doc should be updated after all the other work related to Alerts that came out of the CBW is done.
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.
Regarding the edits to DMTN-102 made so far (above comment), I think we should incorporate them into Master now, and leave GitHub branch tickets/
DM-20238 (and this Jira ticket) open to collect further potential updates that might come out of alerts-related tickets.
Assigned Eric Bellm to review the pull request.
Eric and Gregory both provided feedback, which was incorporated on branch tickets/
Then I tried to make a Glossary and List of Acronyms following how DMTN-109 did it, but failed to make it work. Have assigned a review to Tim J. to be done sometime after the holidays to try and get the glossary into the PDF. Then the pull request can be accepted and the branch merged to master.
Thanks to Gabriele Comoretto [X] and Tim Jenness, and the suggestions of Gregory Dubois-Felsmann, the new version of DMTN-102 now has a nice Glossary. The branch for this ticket has been merged to master. About to close this ticket.
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: