[EAS] : Fallout Over False Alert Continues

[Sean Donelan]

On Wed, 29 Oct 2014, Tim Stoffel wrote:
> I think the intent of the rule about ignoring the timestamp on an EAN 
> is meant to ensure that the EAN gets propagated as rapidly as possible. 
> I don't know how 'strict' that 'strict time' is, but an EAN (or any 
> other alert) that is of by days, weeks or months (and probably hours) 
> is not likely a valid EAS alert. Being off a few minutes is not good, 
> but doesn't necessarily mean an event is invalid. So although setting 
> 'strict time' may not be in the letter of the FCC rules, it is certainly 
> in the spirit of the rules in the sense that false EAS alerts are 
> anathema.

If you look at the last 20 years of EAS problems, you will find 
alternating suggestions to set 'strict time' = ON or OFF on one
popular vendor's equipment depending on the most recent problem at
the time.  You can use google to look up some of them.  In some
cases real alerts were not permitted, and other times old/not real
alerts were permitted.  It tends to be a knee-jerk reaction to
switch it to whatever the opposite setting was, resulting in the
opposite problem a few years later.

Its easier to blame operator error, and not look at the contributing
factors including the design of the protocol.

Although perfection is always the goal, FEMA, FCC, NOAA and OSTP need
to document their objectives for EAS and their preference which is worse:
1) missing a real alert because a too tight validation process rejected 
it, or 2) a false alert because a too loose validation process accepted 
it. Yep, the age-old false negative, false positive problem.

The Common Alerting Protocol (CAP) and EAS-CAP Implementation Guide 
include the Year in the Sent and Expires data elements, but don't
directly address the clock skew issue.  Other Internet authentication 
protocols tend to use either 5 minutes or 15 minutes as an acceptable 
clock skew.  The specific value is less important than all 
implementations agreeing to use the same value.