[earlywarning] Final Charter Text. Thanks!

["Hannes Tschofenig" <[e-mail]>]

Thank you all for participating in this charter discussion. I plan to submit the following charter text to the RAI ADs within the next 24 hours. I included a few minor wording changes based on the very recent feedback on the list. 

Brian D., James P. + Martin T.: Please browse through the text to see whether you are happy with it.

Ciao
Hannes

----------------------------------------------


Authority to Citizen Alert (ATOCA)
==================================

There are a variety of mechanisms that authorities have available to
notify citizens and visitors during emergency events. Traditionally, 
theyhave 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 
onlythose 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) will be the 
basis for the message delivery system of this working group.

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.

Milestones


TBD Initial document for "Terminology and Framework" document. 
A starting point for this work is 
draft-norreys-ecrit-authority2individuals-requirements.

TBD Initial document for conveying alerts in SIP. 
A starting point for this work is draft-rosen-sipping-cap

TBD	  Initial document for conveying alerts through point to
multipoint methods.

TBD      Initial document for locating the alerting server for a
geographic region. A starting point for this work is
draft-rosen-ecrit-lost-early-warning.

TBD	  Initial document addressing security, performance and 
congestion issues for alert distribution.

TBD	  Initial document for interfacing existing alert
distribution systems.