Authority To Citizen Alert (ATOCA) Charter Proposal

Authorities need mechanisms to notify citizens and visitors of emergency events.  Traditionally, they have done so with broadcast networks (radio and television).  The Internet provides another way for authority to citizen alerts to be sent, but it also presents new challenges.

The class of alerts that are of interest to this working group are those sent by authorized agents, primarily government agents.  The mechanisms that result from this work may be applicable to a wider group of authorized agents, but our current work is focused on emergency alerts from governments.  Nevertheless, we desire to design this mechanism so that it can be used by national, regional or local authorities and cover alerts for impending Tsunamis which might affect most of a county down to a road closing due to an automobile accident.  A critical element of the work are the mechanisms that assure that only authorized agents can send alerts.

The recipients of these alerts are the wide range of devices connected to the Internet and private IP networks which humans may have “at hand” to get such events, as well as automatons who may take action based on the alerts. This implies that the content of the alert contains some information which is intended to be consumed by humans, and some which is intended to be consumed by automatons.  Ideally, the alerts would contain, or refer to media other than text media (cf audio and/or video), but the present work is restricted to human readable text, which may be mechanically rendered by the device in other forms (text to speech for example).  In situations of a major emergency there could be scenarios where there are multiple alerts generated that may require that a priority mechanism has to be implemented, and this mechanism is  out of scope at his time.

Which devices should get alerts is primarily driven by location.  The first set of recipients that must be catered for are those within the area affected by the alert.  In many jurisdictions, there are regulations the define whether recipients within the affected area have opt-in or opt-out capability, but the protocols we will define will include both opt in and opt out mechanisms.  This work builds on existing IETF geopriv location work.   

Another class of recipients that are in scope of the work are explicit opt-in subscriptions which ask for alerts that are sent to an associated party.  An example of such a subscription would be “send me alerts which are sent to my daughter based on her location”.  

Both of these classes of recipients must operate at Internet scale, which is one of the major challenges to the work.  Many tools have been developed within the IETF to scale messaging, which will be exploited by this effort. Examples include multicast.  The work must function on the networks we have, however, and as such must take into account what is actually deployed, or could reasonably be deployed.

There are other efforts in other for a on alerts, which will be considered in this effort.  For example, we expect to make use of the OASIS Common Alerting Protocol.  ITU-T, ETSI, TIA, ATIS and 3GPP also have alert efforts underway, and consultation with these efforts will be undertaken to avoid unnecessary duplication of effort.

The security implications of mechanisms that can send alerts to billions of devices are profound, but the utility of the mechanism encourages us to face the problems and solve them. 
 
Milestones
 
   Requirements draft March 2010
 
   Framework draft June 2010