[dns-dir] FW: WG Review: Authority to Citizen Alert (ATOCA)

["Romascanu, Dan (Dan)" <[e-mail]>]

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
IESG Secretary
Sent: Tuesday, July 20, 2010 8:00 PM
To: [e-mail]
Subject: WG Review: Authority to Citizen Alert (ATOCA) 

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area.  The IESG has not made any determination as
yet.
The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG
mailing
list ([e-mail]) by Tuesday, July 27, 2010.

                

Authority to Citizen Alert (ATOCA)
----------------------------------
Current Status: Proposed Working Group

Last Modified: 2010-07-15

Chairs(s)
TBD

Real-time Applications and Infrastructure Area Directors:
   Gonzalo Camarillo <[e-mail]>
   Robert Sparks <[e-mail]>

Real-time Applications and Infrastructure Area Advisor:
   Robert Sparks <[e-mail]>

Mailing Lists:
  General Discussion: [e-mail]
  To Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>
  Archive: <http://www.ietf.org/mail-archive/web/earlywarning>

Real-time Applications and Infrastructure Area Advisor:
   Robert Sparks <[e-mail]>

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 impacting layer 2
networks (e.g. causing congestion or denial 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.

NOTE FOR CHARTER REVIEW (this section to be removed before charter
approval): Some early drafts related to this proposed work are
* draft-norreys-ecrit-authority2individuals-requirements
* draft-rosen-ecrit-lost-early-warning
* draft-rosen-atoca-server-discovery
* draft-rosen-atoca-cap
* draft-schulzrinne-atoca-requirements

Goals and Milestones
		  
Jan 2011  Submit "Terminology and Framework" to the IESG for 
         publication as Informational 
		  
Apr 2011  Submit "Addressing security, performance and
         congestion issues for alert distribution" to the 
         IESG for publication as Informational 

Apr 2011 Submit conveying point-to-point Authority to Citizen Alerts
        to the IESG for publication as Proposed Standard

May 2011  Submit "Discovering alerting servers" to the IESG for 
         publication as Proposed Standard
		  
Jun 2011 Submit conveying point-to-multipoint Authority to Citizen 
        Alerts to the IESG for publication as Proposed Standard
		  
Aug 2011 Submit "Considerations for interworking with currently 
        deployed alert distribution systems" to the IESG for 
        publication as Informational