On Fri, 01 Jan 2021 17:12:40 -0500, Matt Hoppes said:

How would that even work? Force a pop up into web traffic?

That's not going to play nicely at all in a world of https://

What if the end users is using an app on a phone?

I'm having a hard time thinking of what app I could *possibly* be using on a phone where I wouldn't want an interruption for a tornado or active shooter alert. This was discussed in detail a while ago - I'm pretty sure the general consensus was that having the phone/game console/smart home control center/ whatever would be running an alert endpoint app that would talk to the ISP/ cellphone tower and register for alerts and then DTRT to notify the relevant carbon-based life forms.

On Fri, Jan 1, 2021, at 23:12, Matt Hoppes wrote:

How would that even work? Force a pop up into web traffic? What if the end users is using an app on a phone?

Like any other "commission-based study". Remember, the action is : "after providing public notice and opportunity for comment, the Commission shall complete an inquiry to examine the feasibility" Any eventual action requiring intervention of the operators (access or service) is not yet defined, and will follow at a later date (if ever).

On 1/2/21 12:40 PM, Sabri Berisha wrote:

----- On Jan 1, 2021, at 2:12 PM, Matt Hoppes mattlists@rivervalleyinternet.net wrote:

Hi,

...

How would that even work? Force a pop up into web traffic? What if the end users is using an app on a phone? Most, if not all, mobile devices connected to cellular already have that option. On my iphone it's under settings->notifications->government alerts. There are three separate options: Amber alerts, Emergency alerts, and Public Safety alerts. I wonder if that is wired in with the earthquake alerts i think you can get these days.

Personally, I have all three turned off after receiving nonsens alerts. Amber alerts for children abducted in Los Angeles, only 600km (~450 miles) from the Bay Area, where I live, for example. Or a "public safety" alert telling me that there are too many people in the local Trader Joe's, 2 miles from my home.

Aliens always invade New York, so I'm safe up here :)

I beg your pardon, they have a bizarre fascination with Golden Gate Bridge. It's the oversized monkeys that like New York. Mike

I am impressed that this thread made it to the drain in less than a day, so here are my few cents on the topic. First, the NDAA does not prescribe port numbers, or any other technology, as no policy document EVER should. It's plain and simple. Mark Foster covered it well, but here is a slightly different point - if the government needs to insert _high priority programming_ whatever you are operating it needs to be able to do that. Now think about your deer grandma (on the one you hate but the dear one), who is sitting on her couch immersed in YouTube jumping cats videos, while there is a tornado in the area. Wouldn't you be happy that YouTube implemented the alert system so grandma now knows she needs to go in the shelter? It is impressive how everyone got worked up on the veto and didn't pay attention to what was written in the NDAA but I'll let people read through it as I don't think this list is suitable for political discussions. Also a PSA: Amber alerts, Emergency alerts, and Public Safety alerts all go over cell broadcast. Think of it as a broadcast message on a LAN where the LAN is the local mobile phone cell. The reason you get that message 600 miles away for an amber alert is because in most civilized societies children's lives are immensely valued. And a 5-6 hour driving distance is not much knowing the lifecycle of reporting of such things and activation of the system, and also the time it takes for some of those kidnappings to be discovered before it can even be reported. Cheers, On Mon, Jan 4, 2021 at 2:00 AM Mark Tinka <mark.tinka@seacom.com> wrote:

On 1/2/21 22:40, Sabri Berisha wrote:

...

Aliens always invade New York, so I'm safe up here :)

I thought that was Roswell :-).

Mark.

Most civilized societies immensely value a great many things, and for exactly zero of them is it acceptable for the government to kick down my door, wake me up, and scrawl a message on my wall to make sure I hear about it. Just because digital tools can save the government millions of man-hours because they no longer have to go house-to-house doesn't justify the theft and use of my personal property against my wishes.

Government Alerts on both IOS and Android are enabled by default, but the operating systems provide very simple toggles to disable them if you so choose. I'm also curious if you consider any unwanted notification or pop up on your devices as 'theft', because it's not. On Mon, Jan 4, 2021 at 4:17 AM Peter Kristolaitis <alter3d@alter3d.ca> wrote:

Most civilized societies immensely value a great many things, and for exactly zero of them is it acceptable for the government to kick down my door, wake me up, and scrawl a message on my wall to make sure I hear about it. Just because digital tools can save the government millions of man-hours because they no longer have to go house-to-house doesn't justify the theft and use of my personal property against my wishes.

On 2021-01-04 3:56 a.m., Krassimir Tzvetanov wrote:

...

Also a PSA: Amber alerts, Emergency alerts, and Public Safety alerts all go over cell broadcast. Think of it as a broadcast message on a LAN where the LAN is the local mobile phone cell. The reason you get that message 600 miles away for an amber alert is because in most civilized societies children's lives are immensely valued. And a 5-6 hour driving distance is not much knowing the lifecycle of reporting of such things and activation of the system, and also the time it takes for some of those kidnappings to be discovered before it can even be reported.

On 1/4/21 6:44 AM, Mike Hammett wrote:

What makes the most sense is the underlying OS does the work and not each individual app.

The underlying OS gets these alerts from some aggregator that collects this information from all jurisdictions.

Doing it at the app layer seems foolish.

That probably makes sense generally, but for things like earthquakes which have tight requirements (= < 10 seconds), you probably need specialized apps. Mike

Then modify the underlying OS to accommodate it. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Michael Thomas" <mike@mtcc.com> To: nanog@nanog.org Sent: Monday, January 4, 2021 8:53:38 AM Subject: Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study On 1/4/21 6:44 AM, Mike Hammett wrote: What makes the most sense is the underlying OS does the work and not each individual app. The underlying OS gets these alerts from some aggregator that collects this information from all jurisdictions. Doing it at the app layer seems foolish. That probably makes sense generally, but for things like earthquakes which have tight requirements (= < 10 seconds), you probably need specialized apps. Mike

On 1/4/21 10:01 AM, Masataka Ohta wrote:

Any device with speaker should produce audible alert and any device with display should produce visible alert.

I'm not sure typical North American residential construction could tolerate the sonic pressure generated by such a "goal"... Streaming devices, sure. They're in-line with conventional distribution channels for emergency alerts such as television, radio, etc. That would include "smart speakers", TV streaming sources, etc. But my refrigerator, washing machine, etc. does not need to do this...many could (they have Internet connectivity in some cases), but that's just overkill and honestly silly. I'm also of the mindset that, in the end, the owner/operator of a given device should be given the authority to disable emergency alerts on that device. It's their device, after all. They may have other ways they prefer to receive such alerts, or they may want to die in a tornado. I'm not going to stop them. Conventional devices like TVs only alert when on, and things like weather radios can be placed into a non-alerting mode without losing other owner-relevant functionality. I'll note that most mobile phones allow the user to turn off most (though usually not all) emergency alerts. Non-OEM OS ROMs often go further. -- Brandon Martin

Every device that would be capable of doing anything also has an OS. That OS is likely shared amongst multiple device models. The only involvement ISPs should have is ensuring that they have proper IP <-> geolocation information and your standard IP forwarding principles. ISPs should not be involved in the processing or design of any of this. It simply doesn't involve them. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> To: nanog@nanog.org Sent: Monday, January 4, 2021 9:01:57 AM Subject: Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study Mike Hammett wrote:

What makes the most sense is the underlying OS does the work and not each individual app.

It all depends on not OSes but devices. Any device with speaker should produce audible alert and any device with display should produce visible alert. As devices are identified at the IP layer, the alert must be distributed at the IP layer, that is, by ISPs. Masataka Ohta

Mike Hammett wrote:

Every device that would be capable of doing anything also has an OS.

Old computers had hardware (manually manipulated switches and light bulbs to read/write specific memory locations) to install boot strap loader to download OS without any OS.

The only involvement ISPs should have is ensuring that they have proper IP <-> geolocation information

Though IP layer has notion of location w.r.t. network topology, it is not geolocation, which is why there is no precise geolocation services to be relied by essential services such as emergency alert. Masataka Ohta

Mike Hammett wrote:

No one cares about old hardware when solving a modern problem.

Modern examples do exist, for example: https://processors.wiki.ti.com/index.php/StarterWare StarterWare is a free software development package that provides no-OS platform support for ARM and DSP TI processors. but harder to understand for people who lack precise knowledge on what computers and OSes are. Masataka Ohta

Brandon Martin wrote:

...

but harder to understand for people who lack precise knowledge on what computers and OSes are.

Hi, embedded developer here who spends a considerable amount of time writing firmware for "bare metal" systems with "no OS".

I did it with a Z80 computer soldered by myself.

I have fairly high confidence that what Mike was referring to was "whatever base level software ships on the doohickey and provides the underlying infrastructure for the user-visible 'apps' that move media from the Internet to the monitor". Mike, please correct me if I'm wrong.

What? "base level software"? You miss that many functions including application ones was and still is performed by hardware, which is why I wrote to Mike:

...

What makes the most sense is the underlying OS does the work and not each individual app. It all depends on not OSes but devices.

For example, these days, many functions of high end IP routers are performed by hardware.

In that context, it doesn't really matter what the box is running. Could be Linux, could be Windows, could be QNX, could be a "while(1) scheduler" and some embedded IP stack.

Regardless of whether a computer is with or without OS, no IP stack, part of which may be implemented by hardware, can generate emergency alert by itself, unless some UDP port is specified for it, which is what I have been saying. Masataka Ohta

Once upon a time, Billy Crook <BCrook@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). 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@cmadams.net>

----- Original Message -----

From: "Richard Porter" <richard@pedantictheory.com>

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

...

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.

Yup; it's called Commercial Mobile Alerting Service (Or Wireless Emergency Alerts, if you're a consumer), and it's been deployed, over SMS Cell Broadcast, for about 10 years now, depending on your carrier. NWS can actually send Tornado WARNINGS *to specific sectors of specific towers*, so they can warn exactly the people necessary in real-time... if it's implemented correctly along the entire path. I'm not actually certain which carriers if any have actually deployed the enchilada. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

Google and Apple already have push systems that can be the model for how they push out alerts for these services, if not just use those very systems. Roku, Amazon, Microsoft, Samsung, etc. can work out similar systems. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Chris Adams" <cma@cmadams.net> To: nanog@nanog.org Sent: Monday, January 4, 2021 10:23:32 PM Subject: Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study Once upon a time, Billy Crook <BCrook@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). 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@cmadams.net>

On Mon, Jan 4, 2021 at 7:11 PM Billy Crook <BCrook@unrealservers.net> wrote:

On Fri, Jan 1, 2021 at 4:13 PM Matt Hoppes < mattlists@rivervalleyinternet.net> wrote:

...

Just give users the ability to select what categories/severities they want to see, so I don't get disrupted every time there's a scary rain storm coming or some divorcee is behind on child-support.

Yesterday I was mildly indifferent. Today, after receiving SIX zarking Amber alerts between 8 PM and 11 PM local time, I suddenly have a strong opinion. Talk about alert fatigue. The sixth alert I received could have been for the world ending. I still wouldn't have looked at my phone. Thankfully I can adjust the default setting to disable everything except "presidental emergency alerts"...whatever that is. As long as I can turn it off completely, I'm fine with people baking that crap into their tech. I still want my wired Nest smoke alarm to be able to pick up NWS alerts though. -A

Once upon a time, Matthew Petach <mpetach@netflight.com> said:

If we're going to postulate every citizen of the country having a cell phone, then we should first postulate the system whereby the government provides them free to every citizen, with a minimum level of access provided free to all users.

You are going from a false base in this particular point, because the current alert systems all require people to purchase their own devices, except for locations with alert sirens. Even those are typically only designed to alert people outdoors (of course, if you live close enough, they'll wake you up, but that's not the primary intent). IF you own a cell phone, there's an alert system. IF you own a weather/all-hazards radio, there's an alert system. The government doesn't provide equipment to receive either of those. I feel that trying to shove alerts down a streaming path is a bad idea, because that's yet another geo-location thing the providers will get wrong. I agree that cell phones provide sufficient coverage already (nothing will be 100%), and for people that care, buy a radio. If you can't figure out to program it, get help - there are regular help days around here from TV stations and EMS and such (or at least there were pre-COVID). The alerts on cable TV are already annoying enough - I've been watching severe weather coverage of radar showing a cell moving towards my house when the alert comes on and takes over my TV for the time it takes to repeat what I've already heard from my weather radio. Now if I want to continue to see live radar coverage, I have to get out a portable TV and connect to the outside antenna (I cannot get good TV signals inside my house because of terrain, despite being only about 7-8 miles from the transmitters). I don't know if an unsubscribed cell phone gets the emergency alerts (I know you are supposed to be able to call 911 from any cell phone, even if not carrying paid service). If so, that'd be another cheap way to get alerts. -- Chris Adams <cma@cmadams.net>

On 1/5/21 7:29 PM, Chris Adams wrote:

I don't know if an unsubscribed cell phone gets the emergency alerts (I know you are supposed to be able to call 911 from any cell phone, even if not carrying paid service). If so, that'd be another cheap way to get alerts.

They pretty much universally should as long as they still have a SIM in them (or are eSIM/ESN-only devices) to give them some idea of their preferred network to which to register. Even if not, they're supposed to register with the "best network available" for emergency calling and alerting only, though I'm not sure how robust that is. I have definitely received SMS-broadcast emergency alerts on an "inactive" phone that was on and not in airplane mode for various reasons, so it does seem to work. It was a CDMA2000 ESN-only device, though, so still had provisioning info. I usually keep such devices in airplane mode, if they're still in use, though, and obviously then the cell radio is inactive so no alerts.

I respect this in principle, but hyperbole serves no-one - a smartphone only creates a "morass of privacy/security issues" if you let it. A basic smartphone can be had for less than $100 USD, which would give you calling, text messaging and emergency alerts. You don't need to spend many hundreds. (I myself run a mid-range device at about US$200 worth. I won't spend $800 or anything close to that for something I could just as easily lose or drop or break in in my pocket whilst doing "active" things). So one has to ask at some level, whether the addition of emergency alerts and the ability to maybe do some simple tasks on the fly when needed (which need not include social media, or the use of location tracking services, or even mobile data most of the time?) is worth anything to you. I feel like a cheap smartphone would be preferable to a smart smoke detector. At least the bits required to deliver the required functionality are already there and not needing to be invented. Mark. On 6 January 2021 10:39:52 pm NZDT, Rich Kulawiec <rsk@gsp.org> wrote:

On Mon, Jan 04, 2021 at 09:08:06PM -0600, Billy Crook wrote:

...

Then again how many people would benefit from adding this to online streaming, but don't already have cellphones that have emergency alert popups that get their attention. The kind of people who don't have smartphones are going to be the ones still watching bunny ears television anyway.

I've worked in science and technology for a long time, and I've chosen not to have a smartphone. Not that I have to justify this decision to you, but: (1) I spend a fair amount of my time in environments with poor/no connectivity (2) I participate in activities that are likely to result in the destruction or loss of the phone and (3) I use my phone...for phone calls and the occasional text. So spending $40 rather than $800, avoiding the morass of privacy/security issues involved in a smartphone, and maximizing available battery life seems like the best move.

I know others who've made the same decision for similar reasons.

---rsk

-- Sent from a mobile device.

----- Original Message -----

From: "Chris Adams" <cma@cmadams.net>

Aren't the cell-based emergency alerts on all cell phones, not just smartphones?

CMAS/WEA uses SMS Cell Broadcast. I assume the SMS firmware on the phone has to know what to do about those, and I don't know how far that knowledge goes back in the deployment of SMS firmware, and it's all-fired difficult to find out, IME. Anything built in the last 4-5 years certainly should know; I've received CMAS on phones as far back as 2009 build or so... though I did need an app, and I had to steal one from another carrier than my own. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

On 3/01/2021 2:41 am, Masataka Ohta wrote:

Sean Donelan wrote:

...

the Commission shall complete an inquiry to examine the feasibility of updating the Emergency Alert System to enable or improve alerts to consumers provided through the internet, including through streaming services.

It is trivially easy to have a dedicated UDP port to receive broadcast packets for such purposes, as "through streaming services" is not the requirement.

but "including" is... And I don't see that opening up a UDP port on every end-user device to receive some sort of broadcast (unicast?) is going to be great security. Someone will find away to exploit it.

As streaming services are often offered from distant places including foreign locations, generations of emergency alert packets *MUST* be responsibility of *LOCAL* ISPs.

A problem is that home routers may filter the broadcast packets from ISPs, but the routers may be upgraded or some device to snoop the alert packets may be placed between ISPs and the routers.

I think you're overthinking this. In my mind it's simple.  The streaming companies need to have a channel within their streaming system to get a message to a 'currently active customer' (emergency popup notification that appears when their app is open or their website is active with an authenticated user).  The streaming company will also know the location of their customer (billing information) so will know what geographic locations are relevant to that customer. Local Authorities can feed emergency broadcast information to the streaming companies tagged with a geolocation and the streaming company will only rebroadcast it to those customers who are interested in that geolocation. Providing for network-layer alerts of this nature is overcomplicated and unnecessary - as was pointed out there are existing means to do this (cellphone emergency broadcasts, weather radio service, etc) and the intent appears to be to simply add another channel for those who might not be able to receive the other. Asking the likes of Netflix to be able to channel an brief emergency notifcation across a relevantly-located customers streaming service doesn't actually seem that complex, and because it's all 'in band' it requires no specific intervention from the underlying network operator. Mark.

I've already had to spike one widely announced WAN UDP protocol that someone had proposed without thinking through security and DDOS features. Please don't let's try that trick again. We have perfectly good approaches that don't involve insecure untraceable transport layers. This isn't 1985. TCP and something SSL encrypted - HTTPS comes to mind, even if it gets its own port (11911 is available...). -george On Sat, Jan 2, 2021 at 10:02 PM Mark Foster <blakjak@blakjak.net> wrote:

On 3/01/2021 2:41 am, Masataka Ohta wrote:

...

Sean Donelan wrote:

...

the Commission shall complete an inquiry to examine the feasibility of updating the Emergency Alert System to enable or improve alerts to consumers provided through the internet, including through streaming services.

It is trivially easy to have a dedicated UDP port to receive broadcast packets for such purposes, as "through streaming services" is not the requirement.

but "including" is...

And I don't see that opening up a UDP port on every end-user device to receive some sort of broadcast (unicast?) is going to be great security. Someone will find away to exploit it.

...

As streaming services are often offered from distant places including foreign locations, generations of emergency alert packets *MUST* be responsibility of *LOCAL* ISPs.

A problem is that home routers may filter the broadcast packets from ISPs, but the routers may be upgraded or some device to snoop the alert packets may be placed between ISPs and the routers.

I think you're overthinking this.

In my mind it's simple. The streaming companies need to have a channel within their streaming system to get a message to a 'currently active customer' (emergency popup notification that appears when their app is open or their website is active with an authenticated user). The streaming company will also know the location of their customer (billing information) so will know what geographic locations are relevant to that customer.

Local Authorities can feed emergency broadcast information to the streaming companies tagged with a geolocation and the streaming company will only rebroadcast it to those customers who are interested in that geolocation.

Providing for network-layer alerts of this nature is overcomplicated and unnecessary - as was pointed out there are existing means to do this (cellphone emergency broadcasts, weather radio service, etc) and the intent appears to be to simply add another channel for those who might not be able to receive the other. Asking the likes of Netflix to be able to channel an brief emergency notifcation across a relevantly-located customers streaming service doesn't actually seem that complex, and because it's all 'in band' it requires no specific intervention from the underlying network operator.

Mark.

-- -george william herbert george.herbert@gmail.com

On 2021-01-03 08:26, Valdis Klētnieks wrote:

On Sun, 03 Jan 2021 18:59:37 +1300, Mark Foster said:

...

In my mind it's simple.� The streaming companies need to have a channel within their streaming system to get a message to a 'currently active customer' (emergency popup notification that appears when their app is open or their website is active with an authenticated user).� The

Oh geez. Just on my PS4, there's streaming apps for Disney+, Netflix, Hulu, Prime, Playstation Store, Peacock, Tubi, ESPN+, AppleTV, YouTube (less than half of which I actually subscribe to, but I haven't found a big enough crowbar to remove the others, they keep returning) - and that's probably not a complete list.

And we get to watch them all do it in subtly different ways, often buggy. Egads.

Yeah my family got a PS4 for Christmas. But we've had an Xbox One for the last few years. There are quite a few streaming apps, true. But a lot fewer of those than worldwide telcos, or jurisdictions, or emergency services.

Bonus points for figuring out how to keep two streaming apps from stepping on each other's toes, as often these apps stay semi-alive in the background, which may be enough to cause an alert to be sent to the app. Now you need to avoid a "thundering herd" problem if there's 18 different streaming apps on the device, all of which just got woken up. On resource constrained systems, that's often the start of a death spiral as the system either runs totally out of memory or goes into thrashing mode.

And the alternative is just saying "only the streaming app in the foreground gets to handle the alert", but that isn't correct either - I might not *have* a streaming app running in the foreground on the device at the time the alert goes out. (You hit another problem as well - now all the apps have to notify upstream

So do you want the streaming service to deliver the alert, or do you want the underlying device doing the streaming, to deliver the alert? Because I think you've gone down a layer and didn't need to. Foregrounded App, delivering alert, feels doable.

So having every single "streaming" app have to include duplicate code and *still* not get the alert to the user doesn't seem the right direction to go...

If one wanted to target the console world or smart TV world, that's another way of doing it - but then you need Microsoft, Sony, Samsung, LG etc to all be doing essentially the same thing. Not impossible, but not precisely within the scope of 'online streaming services'.

...

streaming company will also know the location of their customer (billing information) so will know what geographic locations are relevant to that customer.

Billing info may be good enough for stuff that stays at home. It doesn't tell you what zip code a portable device is actually in at the moment - and getting the *right* localized info to the portable device is one of the tricky parts of this. If you're out and about town while visiting your in-laws 3 time zones away from where you live, you want alerts for the town your in-laws live, not for the address the streaming company sends the bill to.

The problem that was trying to be solved, was people who literally don't have a mobile device. What category of device are you trying to alert to that wouldn't otherwise be able to receive an emergency broadcast? Seems like we're getting more-and-more niche.

And that's assuming that a streaming company even *has* the info in their billing information - I just checked, and Hulu doesn't have a street address for me. So they're going to end up having to do IP based geolocation.

... or simply collect the geographic information required, retrospectively, in order to comply.

Meanwhile, this causes yet another problem - if Hulu has to be able to know what alerts should be piped down to my device, this now means that every single police and public safety agency has to be able to send the alerts to Hulu (and every other streaming company) - and do this securely. That's a *lot* bigger problem than "The Blacksburg VA police department only has to set up agreements with network access providers that might be providing access to devices in Blacksburg".

Sure. But the likes of Netflix will need a relationship with every single PD in the world? Scales nicely in one direction, but not the other.

Seriously guys - having the streaming companies do this is at the entirely wrong level.

I dunno. Providing an API and establishing a relationship with what has to be a relatively finite number of streaming providers seems not impossible. If Netflix put up an API and you built a hierarchy for emergency notifications (so perhaps your local PD don't directly talk to Netflix, but maybe they talk to someone at state level? Then there's a managable chain of relationships). If you're going to create a legislative or regulatory framework that requires the streaming operators to provide for this sort of thing anyway - as it appears the NDAA will require - it feels like a solvable problem to me. With the disclaimer that i'm not a developer and i'm not from North America, so perhaps the scale issue is beyond my understanding. Mark. Mark.

Valdis Klētnieks wrote:

That's why I think doing it at the streaming service level is one level too high.

As IP layer is the highest location dependent layer, any layer above it needs special mechanism to explicitly treat location information, which does not scale especially at international scale, though many of you might think FCC can control all the foreign operators. Masataka Ohta

On Sun, Jan 03, 2021 at 03:26:07AM -0500, Valdis Kl??tnieks wrote:

Meanwhile, this causes yet another problem - if Hulu has to be able to know what alerts should be piped down to my device, this now means that every single police and public safety agency has to be able to send the alerts to Hulu (and every other streaming company) - and do this securely.

And then there's another problem (that I'm going to bet you've already thought of, given what you've written here): Hulu and every other streaming company need to be able to authenticate the alerts from all those different agencies. Those agencies also need to secure their sending infrastructure...and good luck with that. And then there's another problem, which is that once all those different agencies have this facility, they're going to (ab)use it as they see fit. I've noticed that over the last decade or so that weather alerts I've received are covering increasingly-less-severe events, e.g., we've slowly gone from "there's a tornado on the ground" to "there's going to be a thunderstorm". And at this particular point in history, I can think of one person who would be using this every five minutes simply because it's there. ---rsk

Once upon a time, Rich Kulawiec <rsk@gsp.org> said:

And then there's another problem, which is that once all those different agencies have this facility, they're going to (ab)use it as they see fit.

A year or two ago, Alabama issued a state-wide "blue alert" when a police officer was shot. So my weather/all-hazards radio alarm went off at 3am for something that happened 200 miles away. I then disabled that alert category. I only have severe weather warning categories enabled now (because tornadoes are a thing I do want to know about). -- Chris Adams <cma@cmadams.net>

Mark Foster wrote:

On 3/01/2021 2:41 am, Masataka Ohta wrote:

...

Sean Donelan wrote:

...

the Commission shall complete an inquiry to examine the feasibility of updating the Emergency Alert System to enable or improve alerts to consumers provided through the internet, including through streaming services.

It is trivially easy to have a dedicated UDP port to receive broadcast packets for such purposes, as "through streaming services" is not the requirement.

but "including" is...

It's not feasible. The alert should be given by not services but devices running various services including streaming ones.

And I don't see that opening up a UDP port on every end-user device to receive some sort of broadcast (unicast?) is going to be great security. Someone will find away to exploit it.

It should be the responsibility of local ISPs to generate such packets and not to relay such packets generated by others.

I think you're overthinking this.

In my mind it's simple.  The streaming companies need to have a channel within their streaming system

You have successfully made the simple problem complex enough to be unsolvable.

Local Authorities can feed emergency broadcast information to the streaming companies tagged with a geolocation

Local authorities? You can't expect such locality for companies offering streaming or similar services over the Internet. Moreover, there is no reason to give precise definition of "streaming services" and not to give alert to users of similar services. Masataka Ohta

On 1/2/21 10:31 PM, Jay R. Ashworth wrote:

...

including foreign locations, generations of emergency alert packets *MUST* be responsibility of *LOCAL* ISPs.

A problem is that home routers may filter the broadcast packets from ISPs, but the routers may be upgraded or some device to snoop the alert packets may be placed between ISPs and the routers. Yup; it's messy, and in many many different ways. Won't be a snapshot rollout. Not a bad idea, though, if implemented correctly; time to dig out my notes, I guess.

Is there a reason not to use an outbound tcp/quic connection? It was unthinkable years ago to use TCP with DNS, but now we have DoH and the world hasn't spiraled out of control. Heck if you made it a websocket you'd have a built in channel for multi-media html, etc. That is, just push a URL down and fire up a webview that the OS makes certain is in focus. Mike

On 1/3/21 12:11 PM, Jay R. Ashworth wrote:

----- Original Message -----

...

...

Yup; it's messy, and in many many different ways. Won't be a snapshot rollout. Not a bad idea, though, if implemented correctly; time to dig out my notes, I guess. Is there a reason not to use an outbound tcp/quic connection? It was unthinkable years ago to use TCP with DNS, but now we have DoH and the world hasn't spiraled out of control. Heck if you made it a websocket you'd have a built in channel for multi-media html, etc. That is, just

From: "Michael Thomas" <mike@mtcc.com> To: nanog@nanog.org On 1/2/21 10:31 PM, Jay R. Ashworth wrote: push a URL down and fire up a webview that the OS makes certain is in focus. Well, TCP means that the servers have to expect to have 100k's of open connections; I remember that used to be a problem.

As for D'oH, sure; let's centralize the attack surface.

The only reason I bring up DoH is because now there are tcp connection when the day before there were none. I haven't noticed any difference since firefox turned it, so they obviously figured out the scaling. Mike

On 1/3/21 2:23 PM, Jay R. Ashworth wrote:

----- Original Message -----

...

From: "Michael Thomas" <mike@mtcc.com>

...

Well, TCP means that the servers have to expect to have 100k's of open connections; I remember that used to be a problem.

As for D'oH, sure; let's centralize the attack surface. The only reason I bring up DoH is because now there are tcp connection when the day before there were none. I haven't noticed any difference since firefox turned it, so they obviously figured out the scaling. Firefox is using one TCP connection to pipeline all the D'oH queries down?

I assume so. DoH is just http running http2 or http3. Clearly getting servers to support millions of http sessions is doable these days. Mike

On 03Jan21, Brandon Martin allegedly wrote:

On 1/3/21 3:11 PM, Jay R. Ashworth wrote:

...

Well, TCP means that the servers have to expect to have 100k's of open connections; I remember that used to be a problem.

Out of curiosity, has anyone investigated if it's possible to hold open a low-traffic, long-lived TCP session without actually storing state using techniques similar to syncookies and do so in a compatible manner?

Creating quiescent sockets has certainly been discussed in the context of RSS where you might want to server-notify a large number of long-held client connections very infrequently. While a kernel could quiesce a TCP socket down to maybe 100 bytes or so (endpoint tuples, sequence numbers, window sizes and a few other odds and sods), a big residual cost is application state - in particular TLS state. Even with a participating application, quiescing in-memory state to something less than, say, 1KB is probably hard but might be doable with a participating TLS library. If so, a million quiescent connections could conceivably be stashed in a coupla GB of memory. And of course if you're prepared to wear a disk read to recover quiescent state, your in-memory cost could be less than 100 bytes allowing many millions of quiescent connections per server. Having said all that, as far as I understand it, none of the DNS-over-TCP systems imply centralization, that's just how a few applications have chosen to deploy. We deploy DOH to a private self-managed server pool which consume a measly 10-20 concurrent TCP sessions. Mark.

----- Original Message -----

From: "Brandon Martin" <lists.nanog@monmotha.net>

The nice thing is that such emergency alerts don't require confidentiality and can relatively easily bear in-band, application-level authentication (in fact, that seems preferable to only using session-level authentication). That means you could easily carry them over plain HTTP or similar which removes the TLS overhead you mention.

Sure. Just signing the alert packet so it can be authenticated is plenty.

Several GB of RAM is nothing for a modern server, of course. It sounds like you'd probably run into other scaling issues before you hit memory limitations needed to juggle legitimate TCP connection state.

Well, yeah, but I don't know that it's *just* RAM; I suspect it might be data structure as well... Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

On 1/3/21 1:50 PM, Mark Delany wrote:

On 03Jan21, Brandon Martin allegedly wrote:

...

I was thinking more in the original context of this thread w.r.t. potential distribution of emergency alerts. That could, if semi-centralized, easily result in 100s of million connections to juggle across a single service just for the USA. While it presumably wouldn't be quite that centralized, it's a sizable problem to manage. Indeed. But how do you know the clients are still connected? And if they aren't, there is not much a server can do beyond discarding the state. Presumably the client would need to run a fairly frequent keep-a-live/reconnect strategy to ensure the connection is still functioning.

Which raises the question: how long a delay do you tolerate for an emergency alert? I think the end result is a lot of active connections and keep-a-live traffic. Not really quiescent at all. In the end, probably just as cheap to poll a CDN.

I just sent some mail to the myshakes folks at UCB asking if they have an achitecture/network document. In their case for earthquakes it need to be less than ~10 seconds so they are really pushing the limit. If they get back to me, I'll share it here. Mike

On 1/3/21 2:27 PM, Ask Bjørn Hansen wrote:

On Jan 3, 2021, at 13:57, Michael Thomas <mike@mtcc.com> wrote:

...

I just sent some mail to the myshakes folks at UCB asking if they have an achitecture/network document. In their case for earthquakes it need to be less than ~10 seconds so they are really pushing the limit. If they get back to me, I'll share it here. The two platforms they support have APIs and infrastructure to make it work at large scale.

Do you know where to find docs on it? I'd be curious because clearly this is a hard problem.

Piggybacking this sort of thing on another connection is trading some connection overhead for a whole lot of application complexity. This being nanog it’s unsurprising that the discussion is focusing on the connection and protocol bits, but those are a tiny part of the overall complexity (for the client, too). 🙂

Well, the network is an interesting part in its own right because of the latency is so critical. I did notice that at least part of their sensor network is your phone itself. Mike

At this point I would assume that nearly every device is persisting at least one long lived TCP connection.  Whether it's for telemetry or command and control, everything these days seems to have this capability.  As an example, I can hit a button in the Nintendo Switch parent app on my phone and my kid's Switch is reflecting changes a second later.  That's not even a platform I would have expected to have that capability. If they have an existing connection then there lots of high connection count solutions in the IOT space that could easily handle this number of connections.  A single 12c 32G box running emqttd could handle 1.3M connections.  Just picking a random AWS EC2 size machine, m5.4xlarge, would run you about $0.003/year per device to keep that connection open and passing data.  I assume you could drive that down significantly from there. On 01/03/2021 03:35 PM, Brandon Martin wrote:

On 1/3/21 4:22 PM, Mark Delany wrote:

...

Creating quiescent sockets has certainly been discussed in the context of RSS where you might want to server-notify a large number of long-held client connections very infrequently.

While a kernel could quiesce a TCP socket down to maybe 100 bytes or so (endpoint tuples, sequence numbers, window sizes and a few other odds and sods), a big residual cost is application state - in particular TLS state.

Even with a participating application, quiescing in-memory state to something less than, say, 1KB is probably hard but might be doable with a participating TLS library. If so, a million quiescent connections could conceivably be stashed in a coupla GB of memory. And of course if you're prepared to wear a disk read to recover quiescent state, your in-memory cost could be less than 100 bytes allowing many millions of quiescent connections per server.

Having said all that, as far as I understand it, none of the DNS-over-TCP systems imply centralization, that's just how a few applications have chosen to deploy. We deploy DOH to a private self-managed server pool which consume a measly 10-20 concurrent TCP sessions.

I was thinking more in the original context of this thread w.r.t. potential distribution of emergency alerts.  That could, if semi-centralized, easily result in 100s of million connections to juggle across a single service just for the USA.  While it presumably wouldn't be quite that centralized, it's a sizable problem to manage.

Obviously you could distribute it out ala the CDN model that the content providers use, but then you're potentially devoting a sizable chunk of hardware resources at something that really doesn't otherwise require it.

The nice thing is that such emergency alerts don't require confidentiality and can relatively easily bear in-band, application-level authentication (in fact, that seems preferable to only using session-level authentication).  That means you could easily carry them over plain HTTP or similar which removes the TLS overhead you mention.

Several GB of RAM is nothing for a modern server, of course.  It sounds like you'd probably run into other scaling issues before you hit memory limitations needed to juggle legitimate TCP connection state.

On 1/3/21 1:22 PM, Mark Delany wrote:

Even with a participating application, quiescing in-memory state to something less than, say, 1KB is probably hard but might be doable with a participating TLS library. If so, a million quiescent connections could conceivably be stashed in a coupla GB of memory. And of course if you're prepared to wear a disk read to recover quiescent state, your in-memory cost could be less than 100 bytes allowing many millions of quiescent connections per server.

Even at 1000 bytes, we're talking about 40GB for the entirety of California. You can get off the shelf cloud VM's with that easily these days, and 10 of those covers the US (ok, redundancy, but still...). That's probably why DoH wasn't a big deal. Throwing memory at a problem these days is probably easier than any heroic measures. Mike

On Sat, Jan 2, 2021 at 6:51 AM Sander Steffann <sander@steffann.nl> wrote:

Hi, [...] Just to be clear: this is talking about IP traffic, not things like SMS-CB, right? When there are already cell broadcast alerts, I have the feeling that adding alerts to IP traffic (however that would be supposed to work) wouldn't add that much coverage…

Cheers, Sander

I think the challenge here is that there's a category of people who don't have cell phones, who don't have cable TV, but receive content over their internet connection. I happen to live with someone like that, so I know it's a non-zero portion of the population. For them, cell based alerts don't reach them, and cable TV inserted alerts don't reach them. Thus, the question of "can we reach them via IP-based alerting?" I think it's a good investigation to undertake, as there's clearly a population that is left out of the current alerting systems we have in place. Matt

On Sat, Jan 2, 2021 at 5:45 PM Max Harmony via NANOG <nanog@nanog.org> wrote:

On 02 Jan 2021, at 19.18, Matthew Petach <mpetach@netflight.com> wrote:

...

I think the challenge here is that there's a category of people who don't have cell phones, who don't have cable TV, but receive content over their internet connection. I happen to live with someone like that, so I know it's a non-zero portion of the population.

Emergency alerts are also on OTA TV (and radio), not just cable. People whose sole communications device is a computer can subscribe to FEMA'S IPAWS feed. People who can't (or don't want to) do that can use a weather radio (despite the name, NWS broadcasts all hazards alerts, not just weather). The most likely answer to "how do we get streaming services to provide emergency alerts?" is to make them redistribute the IPAWS feed and update their software to make the updates human-readable. It would probably be cheaper to just tell people where to find free IPAWS software instead of making every streaming service add the feature, and, as a last resort, give people who need them free weather radios.

The FEMA IPAWS system doesn't seem well-suited for end-users to subscribe to it. Of note is the specific restriction: - Providers cannot stress IPAWS servers with excessive requests. Which might hint that the FEMA servers aren't intended to support hundreds of thousands of individuals connecting directly to them to request alert data. It doesn't look like there's currently any internet-capable way of consuming the IPAWS feed, at least that a quick search engine dive turns up. Wondering if any of the folks here know of providers that have signed up with FEMA to redistribute the IPAWS feed for free? (Yes, I found WeatherMessage, but their pricing and platform restrictions made them a non-starter). Thanks! Matt

Let's just go back to air-raid sirens. I'm old enough to remember when they were tested every day at noon, which also told you it was noon (lunch!) We'd say heaven help us if The Enemy attacked at noon. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

I think the challenge here is that there's a category of people who don't have cell phones, who don't have cable TV, but receive content over their internet connection. I happen to live with someone like that, so I know it's a non-zero portion of the population.

I pay for my Internet connection and I do not want "your shit" to be spending "my money". If you think this is oh so important then *YOU* can pay to install at your sole expense, a device which emits your silly warnings -- I do not want them. You will also have to negotiate for easement rights on my Private Property and those are not going to be given away for cheap. And even if you do pay me %1 Million a month that it will cost to acquire the necessary easement on my Private Property, I will put your annoying shit inside a soundproof faraday cage in the closet. So you might as well just not bother. This is the same thing I tell shithead politicians and pollsters that cause my phone to ring. If you wish to speak with me then you can pay to install your own communications equipment at your own expense. That does not mean that I will be answer or pay any attention to it or refrain from taking action to prevent it from disturbing me. For the shitheads that use robotic callers I have a wonderful digital war-dialer that can tie up a whole central switch -- one way or the other the assholes will be forced to cease their disgusting behaviour! -- Be decisive. Make a decision, right or wrong. The road of life is paved with flat squirrels who could not make a decision.

On Sun, 03 Jan 2021 18:00:22 -0700, "Keith Medcalf" said:

This is the same thing I tell shithead politicians and pollsters that cause my phone to ring. If you wish to speak with me then you can pay to install your own communications equipment at your own expense.

Um... Keith? Pretty much all of them *do* pay for their end of the communications equipment. The bigger question is why you pay for *your* end rather than insisting that everybody who wants to talk to you pay for your end. (Hint: Do you require that the annoying sister in law you don't want to hear from also install gear at their expense? Does the answer change if you usually want to hear from her but not today because reasons?)

On Sun, Jan 3, 2021 at 5:03 PM Keith Medcalf <kmedcalf@dessus.com> wrote:

...

I think the challenge here is that there's a category of people who don't have cell phones, who don't have cable TV, but receive content over their internet connection. I happen to live with someone like that, so I know it's a non-zero portion of the population.

I pay for my Internet connection and I do not want "your shit" to be spending "my money". If you think this is oh so important then *YOU* can pay to install at your sole expense, a device which emits your silly warnings -- I do not want them. You will also have to negotiate for easement rights on my Private Property and those are not going to be given away for cheap.

I take it you chant the same diatribe at your television when your video bandwidth is *stolen* by the emergency broadcast notification system, as it marches across the top of your screen? After all, you've paid for your television feed, and you don't want those "emergency broadcast messages" spending *your money*. Dammit, how dare they interrupt those precious seconds of the nightly news to tell you there's a flash flood warning for your county? There's already precedent set. I think that ship sailed long before you started attempting to drill holes through the hull. ;P Matt

Comment inline -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

On Jan 4, 2021, at 14:35, bzs@theworld.com wrote:

 Why wouldn't we just build this into 10-year battery smoke alarms, a simple radio receiver?

Someone contact gentex.com to go over the IoT thoughts.

Why does anyone think this must be a feature of the internet when, as people here have described, that entails all sorts of complexities.

You just want something that goes BEEP-BEEP-BEEP KISS YOUR ASS GOODBYE! BEEP BEEP BEEP really loudly on command, perhaps with some more detail.

Probably about 10c in circuitry involved.

We're really getting way into the cargo cult worship of the internet much like how TV in the 1950s was supposed to be the answer to every one of society's problems but mostly what we got were sitcoms and ads for bad beer.

Ok, proceed with the list of edge cases. But at least there are laws requiring smoke alarms most everywhere.

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

On Mon, 04 Jan 2021 15:33:10 -0500, bzs@theworld.com said:

Why wouldn't we just build this into 10-year battery smoke alarms, a simple radio receiver?

First, that means your smoke alarm batteries run down faster, which is a major issue. I didn't bother thinking past that show-stopper, others can do so if they wish...

On Tue, Jan 5, 2021 at 2:50 PM <bzs@theworld.com> wrote:

Could we make the battery just a little more powerful? How much power would a bit of circuitry waiting for a "turn on! there's a new message coming in!" need? [....]

If your network connectivity, or web browser, or cellular reception stops working; people realize very quickly that they aren't getting messages, and that something is wrong. Well, maybe, sometimes people break PMTU Discovery by firewalling off ICMP for "security", but even more often: People already ignore testing their smoke detectors. Emergency radios in smoke detectors would be too hard to test, so basically, people would not test them every week, or they would be annoyed by the weekly test, and defeat them - then when an actual emergency happens, 30% of the detectors, don't pick up a thing, because their local environment and signal propagation changed, they're in a signal dead zone, or the nearest NOAA transmitter was 100 miles away, and there was too much local interference to get a decodable message, anyways. Emergency receivers are subject to signal, reception, and coverage issues, even if you can put one in every smoke detector. They are a neat add-on, but do not displace the motivation to distribute true emergency messages over 100% of available services from 3rd party communication providers, including the internet, cellular networks, broadcast streaming, all services, etc. Devices used to access streaming services, and web content have a huge Advantage - End users receive ordinary content and communications on these devices every day, and there is a service provider to continually monitor services, so it makes sense to levy the responsibility upon those distribution providers and network operators - that will make a more reliable result, since end users don't require extra work to verify these are actually working, etc. For Smoke Detector + Emergency receiver.. Probably need to add external power. Might as well use a separate power supply and a separate unit. A smoke detector is microwatts, and a radio receiver with logic for decoding and processing the analog waveform is more than a hundred milliwatts. "Not turning on" - is a sure way to not receive a signal - RFI and EM are abundant, and active logic is required to discriminate a true message.

etc. -- -JH

----- Original Message -----

From: bzs@theworld.com

On January 4, 2021 at 21:19 valdis.kletnieks@vt.edu (Valdis Klētnieks) wrote:

...

First, that means your smoke alarm batteries run down faster, which is a major issue.

That's the sort of argument I label "all sign, no magnitude".

How much faster? If it took one minute of battery life off a 10 year battery would that be a problem? 30 minutes?

Well, let's address that. Last time I looked, consumer residential smoke detectors were still running off 9V alkaline batteries, which are expected to run the device for 6 months of 1/99 duty cycle (or less, probably *way* less). An Energizer 9v is rated for 8.4VDC in the very general vicinity of 500mAh.

How does that compare to other factors like ambient temperature which also affects battery life but we mostly consider "in the noise"?

A lot. Increasing the alert count from the 1 or 2 it probably is on most smoke alarms to 2 or 3 a *week*, with LOUD analog speaker alert playback is going to change that duty cycle, probably, to something like 10/90. [ All numbers pulled out of my butt for illustration, but probably within half an order of magnitude. ]

Could we make the battery just a little more powerful? How much power would a bit of circuitry waiting for a "turn on! there's a new message coming in!" need?

Well, parsing for EAS on the receiver is going to make its drain non-trivial, too, I think. But there are "increasing the battery replacement frequency" problems *and* "increasing the battery capacity and hence price, not to mention general availability" problems balancing that out. Any way you play it, it has to be an optional model, not a general takeover of the field, I suspect, or the "well we just won't bother anymore" factor takes over. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

Well, it probably gets way worse: if it's a "permanent" battery, it will be harder to find, and harder to replace... ----- Original Message -----

From: "William Herrin" <bill@herrin.us> To: "jra" <jra@baylink.com> Cc: bzs@theworld.com, nanog@nanog.org Sent: Wednesday, January 13, 2021 11:52:47 PM Subject: Re: End-user Alert Delivery (was Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study)

On Wed, Jan 13, 2021 at 7:58 PM Jay R. Ashworth <jra@baylink.com> wrote:

...

Last time I looked, consumer residential smoke detectors were still running off 9V alkaline batteries, which are expected to run the device for 6 months of 1/99 duty cycle (or less, probably *way* less).

Ordinary ionization-based smoke detectors use a 10-year lithium battery, which is about the same lifespan as the americium-based detector circuit as it begins to decay into neptunium.

You may now resume your argument over how much battery drain is too much.

Regards, Bill Herrin

-- Hire me! https://bill.herrin.us/resume/

-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

This is because there is only enough undecayed Americium in the 10-YO smoke detectors to supply radioactive boyscouts with reactor fuel :) -mel

On Jan 13, 2021, at 11:49 PM, bzs@theworld.com wrote:

On January 14, 2021 at 04:56 jra@baylink.com (Jay R. Ashworth) wrote:

...

Well, it probably gets way worse: if it's a "permanent" battery, it will be harder to find, and harder to replace...

No, you don't replace the permanent batteries in these 10 year smoke detectors, you toss the whole smoke detector and buy a new one. Heroic efforts aside.

So you don't need to find the right battery.

FWIW many smoke detectors bought in the past 10-15 years (I dunno but something like that) even with typical replaceable batteries have some sort of timer in them so when they hit 10 years they begin beeping in a slightly different pattern (like two short beeps every 60 seconds) and replacing the battery doesn't help. It just begins doing that on the fresh battery until you figure out that you need to toss the detector and buy a new one.

Ran into that, looked it up on their web site as I was confused why a new battery wasn't helping and they confirmed that means the detector has expired buy a new one.

I assume these 10 year sealed smoke detectors somehow came out of that.

...

----- Original Message -----

...

From: "William Herrin" <bill@herrin.us> To: "jra" <jra@baylink.com> Cc: bzs@theworld.com, nanog@nanog.org Sent: Wednesday, January 13, 2021 11:52:47 PM Subject: Re: End-user Alert Delivery (was Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study)

...

On Wed, Jan 13, 2021 at 7:58 PM Jay R. Ashworth <jra@baylink.com> wrote:

...

Last time I looked, consumer residential smoke detectors were still running off 9V alkaline batteries, which are expected to run the device for 6 months of 1/99 duty cycle (or less, probably *way* less).

Ordinary ionization-based smoke detectors use a 10-year lithium battery, which is about the same lifespan as the americium-based detector circuit as it begins to decay into neptunium.

You may now resume your argument over how much battery drain is too much.

Regards, Bill Herrin

-- Hire me! https://bill.herrin.us/resume/

-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

-- -Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*

(Topic at hand was just building an emergency alert system into smoke detectors rather than try to come up with some complex internet-oriented design.) On January 14, 2021 at 03:56 jra@baylink.com (Jay R. Ashworth) wrote:

Last time I looked, consumer residential smoke detectors were still running off 9V alkaline batteries, which are expected to run the device for 6 months of 1/99 duty cycle (or less, probably *way* less).

Look again, as I said in the OP most consumer smoke detectors today are sealed ten year, can't replace the battery (well, not without surgery.) I've no idea off-hand what they're using inside tho it's probably not difficult to find out, $10 and a hammer if nothing else.

An Energizer 9v is rated for 8.4VDC in the very general vicinity of 500mAh.

...

How does that compare to other factors like ambient temperature which also affects battery life but we mostly consider "in the noise"?

A lot. Increasing the alert count from the 1 or 2 it probably is on most smoke alarms to 2 or 3 a *week*, with LOUD analog speaker alert playback is going to change that duty cycle, probably, to something like 10/90. [ All numbers pulled out of my butt for illustration, but probably within half an order of magnitude. ]

I don't understand what you're designing but all I was suggesting was a smoke detector with a built in RF switch which upon hearing the magic signal started squawking "EMERGENCY ALERT!" or similar, perhaps with a coded word or two like "EMERGENCY TORNADO ALERT!" or perhaps a brief suggestion to consult your favorite emergency medium immediately (TV, radio, phone, religious text, etc.) Or perhaps that would be understood if it ever starts squawking "EMERGENCY ALERT!" or similar. Some of them now just start barking "EMERGENCY! EMERGENCY! FIRE! FIRE! GET OUT OF THE HOUSE" over and over. I hear them go off nearby fairly regularly so that rings in my head I'm not making it up.

...

Could we make the battery just a little more powerful? How much power would a bit of circuitry waiting for a "turn on! there's a new message coming in!" need?

Well, parsing for EAS on the receiver is going to make its drain non-trivial, too, I think.

But there are "increasing the battery replacement frequency" problems *and* "increasing the battery capacity and hence price, not to mention general availability" problems balancing that out.

Any way you play it, it has to be an optional model, not a general takeover of the field, I suspect, or the "well we just won't bother anymore" factor takes over.

But none of these power problems etc applies to any of the other proposed solutions? Phones etc? Or internet connections in general? Meh, I'd like to hear the thoughts of a smoke detector product engineer. My WAG is the only major objection would be that they're already neck deep in regulatory compliance and OMG this would add another layer of that, new orgs to answer to, new paperwork, etc. But so what else is new, ask marketing if it'd be worthwhile anyhow.

Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*