| The Telecom Digest |
|---|
| Copyright © 2022 E. William Horne. All Rights Reserved. |
| Telecom Digest Wed, 10 Aug 2022 |
|
Message-ID: <20220809201817.GA40972@telecomdigest.us> Date: Tue, 9 Aug 2022 20:18:17 +0000 From: Telecom Digest Moderator <telecomdigestsubmissions@remove-this.telecom-digest.org> Subject: Re: I'm still trying to reconnect with the Telecom Digest server I got an email from Garrett Wollman at csail: he did me a big favor, and installed the Apache2 web server and PHP software needed for our day-to- day operations on the new "telecom digest" server. Thanks you, sir: you're a professional, and I'm not, so kudos to you and your team. I've been using our "backup" server for the last few days, and in the process, I've realized that the Telecom Digest's internal work-flow and software are in need of a major overhaul: I've been doing things by hand that were automated on the old server, but thinking about the scripts and lisp that I've put together - and am now doing without - has made it obvious that I need to go back to the drawing board and redesign a process which grew willy-nilly over decades. So, I'm going to stay on the backup machine for another few days, while I make notes and plans. I've just turned 70, and although I still feel my mind is sharp, I must be realistic: the system has to be simplified and must have much better documentation if it's going to work when I'm much further along the road. I welcome help and suggestions, especially with the tasks shown in the following list: 1. I have to take the daily "Digest" email (the one most subscribers get) and turn it into a web page so that those with only web-based access can read the digest on the web. Currently, that is a semi-automated process, but I'm going to try to automate it completely: the rules and procedure steps can be defined, and the scripts written, by anyone experienced in awk or sed or (insert your favorite tool here). 2. The old server has procmail rules which detected posts that didn't have complete headers, and put them in separate mailboxes where I would work on them by hand. There needs to be an automatic process for those changes, too. 3. I'd like to learn how to either a. Adapt the regular web page for better visibility on mobile devices with small screens, or ... b. Learn how to detect a browser's screen resolution and/or size, and deliver the content specific to that device. 4. Construct, code, test, and implement a moderation process which doesn't require specialized knowlege, so that "Guest" moderators aren't left flailing around in Linux-land just to do me a favor. It would have to include: a. Methods to modify posts before publication if needed. b. Provision for moderation via email, without need for modifying the headers of a post that requires repair. That will mean an automated pre-moderation process which will benefit me as well as those whom help if I'm sick or on vacation. 5. Other improvements that I don't yet know I need. Suggestions welcome. Bill Horne Message-ID: <20220809184255.GA40937@telecomdigest.us> Date: Tue, 9 Aug 2022 18:42:55 +0000 From: Telecom Digest <telecomdigestsubmissions@remove-this.telecom-digest.org> Subject: Higher-Frequency Communications: NTIA And FCC Sign New MOU On Spectrum Coordination By Katy J. Milner , Meredith G. Singer and Sara M. Baxenberg On August 2, 2022, the National Telecommunications and Information Administration (NTIA) and the Federal Communications Commission (FCC) signed a new Memorandum of Understanding (MOU) on radiofrequency spectrum coordination. The new MOU has been anticipated since the announcement of the Spectrum Coordination Initiative between the two agencies in February of this year. Established under the leadership of FCC Chairwoman Jessica Rosenworcel and NTIA Administrator and Assistant Secretary of Commerce for Communications and Information Alan Davidson, the Spectrum Coordination Initiative is intended to "strengthen the processes for decision making and information sharing and to work cooperatively to resolve spectrum policy issues." With respect to the MOU in particular, the objective was to "update the nearly twenty-year-old Memorandum of Understanding between the agencies to address gaps in government coordination and to better reflect today's spectrum opportunities and challenges." https://www.mondaq.com/unitedstates/telecoms-mobile-cable-communications/1218530/higher-frequency-communications-ntia-and-fcc-sign-new-mou-on-spectrum-coordination?email_access=on Message-ID: <CC373993-3F01-48C3-95A4-BFC1A3287FEC@roscom.com> Date: 8 Aug 2022 23:31:03 -0400 From: "Monty Solomon" <monty@roscom.com> Subject: Emergency Alert System Vulnerability Emergency Alert System (EAS) Vulnerability We recently became aware of certain vulnerabilities in EAS encoder/decoder devices that, if not updated to most recent software versions, could allow an actor to issue EAS alerts over the host infrastructure (TV, radio, cable network). https://content.govdelivery.com/accounts/USDHSFEMA/bulletins/3263326 ************************ Moderator's Note ************************ Sometime in the 1970's there was an accidental "activation" of what used to be called the "Conelrad" system. The Pentagon said that a civilian employee at Cheyenne Mountain had accidentally put the wrong punched tape into the teletype which was connected to the UPI and AP networks, and supposedly there was widespread panic and terror. Accept there wasn't. The event was barely noticed, for several reasons: 1. The radio stations that wern't part of Conelrad were supposed to go off the air, leaving only one or two transmitter operating on the "Conelrad" channels that were marked on all the AM radios. However, the technicians who were supposed to be told to turn them off never got those orders, because either A. The station managers and supervisors refused to sacrifice the ad revenue they were getting by staying on the air, and they all figured that it was a mistake anyway, knowing that if they were wrong, it wouldn't matter.. B. The "alert" receivers which were supposed to wake up station personnel to the fact that the world was theoretically about to end hadn't been maintained, and many of them had been tuned to the wrong channels, so the "chain" of alerts which had been planned, where stations "A" would send an alert, and that would be answered by station "B," and then by "C," either didn't start at all, or petered out at the first station that didn't get the alert from their upstream link, and therefore didn't do anything at all. 2. Conelrad had a network of specially-equipped stations, one or two per area: they had specially-built transmitter which could, in theory, switch to the "Conelrad" frequencies that all the drivers in all the cars were expected to tune to when their regular stations went off the air. The idea was that, since the plan for which stations would remain on the air was "secret," that the invading hordes of bombers couldn't use the AM stations to navigate to their targets, since only one or two stations would remain on the air, and the bomber navigators wouldn't know where the radio signals were coming from. I later heard, from the "old hands" at radio stations where I worked, that the switching mechanisms either failed for lack of maintenance, or couldn't be used because nobody had accounted for the changes in the stations' antenna arrays which had to be made in order to allow the transmitters to switch channels with only DJ's or supervisors on hand to make the needed adjustments. I'll spare you the details, but the antennas were a much bigger problem than anyone had expected. The post-event fault-finding went up and down the chain of command, with everyone from SAC to the Congress to the White House saying we had to get a new, more reliable system. Accept, we didn't. The alerting system required all radio stations to have an alerting receiver turned on and able to respond to the "alert" tone, and thus cause the reactions that the Conelrad planners had assumed would be dutifully executed by all the folks in radio-land. Both before and after the false alarm, it was a disaster of magical thinking, containing assumptions about how all the people involved would automatically do the "right thing," without questioning the source of the information or the consequences if they ignlored the alerts. It failed of its own weightr: the uniformed automatons of World War II had come home, gotten married, and had kids - and neither they nor their children were able to imagine such a great catastrophe as a nuclear war, and they mostly chose to ignore those few alerts which survived the multiple points of failure that the designers hadn't counted on. The Conelrad system is still mentioned in business school courses about disaster preparedness. It's in the sections on how NOT to do it. Bill Horne |