Authority-to-Citizen Alert

Document Charter Authority-to-Citizen Alert WG (atoca)
Title Authority-to-Citizen Alert
Last updated 2010-08-17
State Approved
WG State Concluded
IESG Responsible AD Robert Sparks
Charter Edit AD (None)
Send notices to (None)


There are a variety of mechanisms that authorities have available to
  notify citizens and visitors during emergency events. Traditionally,
  they have done so with broadcast networks (radio and television). For
  commercial mobile devices, broadcasting services such as the Public
  Warning System (PWS), the Earthquake and Tsunami Warning System
  (ETWS), and the Commercial Mobile Alert System (CMAS) are
  standardized and are in various stages of deployment. The Internet
  provides another way for authority-to-citizen alerts to be sent, but
  it also presents new challenges. While there are some existing
  layer 2 mechanisms for delivering alerts, the work in this group
  focuses on delivering alerts to IP endpoints only.
  The general message pattern that this group is intended to address is
  the sending of alerts from a set of pre-authorized agents (e.g.,
  governmental agencies) to a large population without undue impacts
  on the networks serving that population. In particular, the message
  pattern specified should avoid congestion and other denials of service.
  The goal of this group is not to specify how originators of alerts
  obtain authorization, but rather how an ATOCA system can verify
  authorization and deliver messages to the intended recipients. A
  critical element of the work are the mechanisms that assure that
  only those pre-authorized agents can send alerts via ATOCA, through
  an interface to authorized alert distribution networks
  (e.g., iPAWS/DM-Open in the U.S.).
  The ATOCA effort is differentiated from and is not intended to
  replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the
  recipients of ATOCA alerts are the wide range of devices connected to
  the Internet and various 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 (e.g., audio and/or video). The initial work in the group is
  focused on small messages, which may be mechanically rendered by the
  device in other forms (text to speech for example). Future work in
  the group may investigate rich media.     In situations of a
major emergency there could be scenarios   where there are multiple alerts
generated that may require that a   priority mechanism (defined by alert
originator policy) has to be   used. The work on a resource priority
mechanism is out of scope of   the initial charter, but may be revisited
at a later date.     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 identified by the alert originator to be
affected   by the emergency event. In many jurisdictions, there are
regulations   that define whether recipients/devices within the affected
area have   opt-in or opt-out capability, but the protocols ATOCA will
define   will include both opt-in and opt-out mechanisms. The group will
  explore how to support both opt-in and opt-out at the level of  
communication protocols and/or device behavior.     Another class of
recipients that are in scope of the work are   explicit opt-in
subscriptions which ask for alerts for a specified   location, not
necessarily the physical location of the device itself.   An example of
such a subscription would be 'send me alerts for   location x'
(previously determined as the location of interest).   This work may build
on existing IETF GEOPRIV location work.     There are efforts in
other fora on early warning, which will be   considered in this effort.
For example, we expect to make use   of the OASIS Common Alerting Protocol
(CAP) for the encoding of   alerts. OGC, ATIS, TIA, ITU-T, ETSI and 3GPP
also have alert   efforts underway, and consultation with these efforts
will be   undertaken to avoid unnecessary duplication of effort and also
  to avoid unintentional negative impacts on the networks. Of course,
  existing protocols for delivering messages (e.g., SIP, XMPP, or SMTP)
  will be the basis for the message delivery system of this working group.
  Any service discovery mechanisms defined by the group are expected
  to reuse existing discovery frameworks.     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. In addition, the   potential performance and
congestion impacts to networks resulting   from sending alert information
to billions of devices must be   considered and solved if such a service
is implementable. To avoid   manual configuration of servers distributing
alerts a discovery   mechanism will be specified.