* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Atoca Status Pages

Authority-to-Citizen Alert (Concluded WG)
Rai Area: Alissa Cooper, Ben Campbell | 2010-Aug-17 — 2012-Nov-14 

2012-08-20 charter

Authority-to-Citizen Alert (atoca)


 Current Status: Active

     Scott O. Bradner <sob@harvard.edu>
     Martin Thomson <martin.thomson@gmail.com>

 Real-time Applications and Infrastructure Area Directors:
     Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
     Robert Sparks <rjsparks@nostrum.com>

 Real-time Applications and Infrastructure Area Advisor:
     Robert Sparks <rjsparks@nostrum.com>

 Mailing Lists:
     General Discussion: atoca@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/atoca
     Archive:            http://www.ietf.org/mail-archive/web/atoca

Description of Working Group:

    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.

Goals and Milestones:
  Aug 2012 - Call for proposals for Secure Alerting Format
  Sep 2012 - Individual contribution(s) made for Secure Alerting Format draft
  Oct 2012 - Call for WG consensus on adopting a Secure Alerting Format draft into the WG
  Oct 2012 - First WG draft of Secure Alerting Format
  Feb 2013 - Submit Secure Alerting Format draft to the IESG as Proposed Standard

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/atoca/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -