Re: [earlywarning] Finishing the Charter Text Discussions

Hi Hannes,

Based upon the previous email decisions, changes to the charter text are
still needed.  

The second paragraph of the charter provides a high level purpose and
scope for the ATOCA work.  The following should be added to the end of
the second paragraph to provide further clarification on the purpose and
scope of the ATOCA work:

"The ATOCA solutions will not adversely affect the ability of any access
technology to provide emergency services to the citizens (e.g. 9-1-1
calls) or to provide communication services to first responders or other
authorized emergency services personnel.  Additionally, ATOCA is not
replacement solution for any authority to citizen alerting supported by
any access technology."

Regards,

DeWayne A. Sennett

-----Original Message-----
From: earlywarning-bounces@ietf.org
[mailto:earlywarning-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, April 06, 2010 4:18 AM
To: earlywarning@ietf.org
Subject: [earlywarning] Finishing the Charter Text Discussions

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.

_______________________________________________
earlywarning mailing list
earlywarning@ietf.org
https://www.ietf.org/mailman/listinfo/earlywarning