NDAA passed: Internet and Online Streaming Services Emergency Alert Study

Tue Jan 5 04:40:28 UTC 2021

On Mon, Jan 4, 2021 at 10:25 PM Chris Adams <cma at cmadams.net> wrote:

> Once upon a time, Billy Crook <BCrook at unrealservers.net> said:
> > On a technical note (having read the comment about overloading the
> system)
> > could a system like DNS help handle this?
>
> I wouldn't think so, because some of the important alerts are very time
> sensitive.  It's been mentioned several times in this thread that the
> earthquake alerts are on the order of 10 seconds in advance.  I know
> someone that survived a tornado by a few seconds (the time it took to
> get out of bed and get to the bedroom door as the tornado dropped the
> second floor of the house on the bed).
>
4G/LTE/5G networks could be further leveraged for this. In Denton County,
TX, USA, you can register to "opt in" to receive weather alerts. We get
tornadoes here. I could see better leveraging of that technology than
streaming services. It is uncommon to find anyone without a cell phone in
the US anymore.

EMS services in some states leverage private 3G/4G networks for real-time
communications. Wider reach in population clusters.

> To be useful for the worst events, they need to be push, and push in
> very short order.  And since those are the alerts most likely to be
> life-saving, those are what the system needs to be built for (or what's
> the point).
>
> And to the point of the weather service sending out more alerts than in
> the past: yes, they do.  To some extent, it's better radars and software
> to find hazards; they're also learning all the time to better identify
> what is and is not a threat (so there are storms that might have had a
> warning 10 years ago that might not today).  But I'll take extra alerts
> now and then... a friend died in a tornado years ago because the warning
> came after it was on the ground (and probably after they were dead).
>
> --
> Chris Adams <cma at cmadams.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210104/0e777e91/attachment.html>