[earlywarning] Finishing the Charter Text Discussions

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

Hi all, 

we had some discussions in response to the charter text I distributed. I made some minor changes based on the received comments but most of the discussions seemed (at least to me) not related to the charter text itself. 

Is the charter text OK for everyone? 

Ciao
Hannes

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

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

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. 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. The goal of this group is not to specify 
how originators of alerts obtain authorization, but rather how a messaging 
system can verify authorization and deliver message to the intended recipients. 
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 (e.g., audio and/or video), but 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). 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 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
affected by the alert.  In many jurisdictions, there are regulations that
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. The group will explore how to support both opt-in and 
opt-out at the level of communication protocols. 

Another class of recipients that are in scope of the work are explicit
opt-in subscriptions which ask for alerts for a specified location. 
An example of such a subscription would be 'send me alerts for
location x' (previously determined as the location of interest). 
This work builds 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. 
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. 

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 
TBD      Initial document for subscribing to alerts using SIP
         A starting point for this work is draft-rosen-sipping-cap
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.