Re: [earlywarning] Finishing the Charter Text Discussions

"SENNETT, DEWAYNE A (ATTCINW)" <> Wed, 07 April 2010 15:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE1483A6991 for <>; Wed, 7 Apr 2010 08:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.999
X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lY1+jFTkaGMI for <>; Wed, 7 Apr 2010 08:32:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6F2FC3A6993 for <>; Wed, 7 Apr 2010 08:30:54 -0700 (PDT)
X-VirusChecked: Checked
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: []
Received: (qmail 25925 invoked from network); 7 Apr 2010 15:30:47 -0000
Received: from (HELO ( by with DHE-RSA-AES256-SHA encrypted SMTP; 7 Apr 2010 15:30:47 -0000
Received: from (localhost.localdomain []) by (8.14.3/8.14.3) with ESMTP id o37FUjWK024062; Wed, 7 Apr 2010 10:30:46 -0500
Received: from td03xsmtp005.US.Cingular.Net ( [] (may be forged)) by (8.14.3/8.14.3) with ESMTP id o37FUfDY023917; Wed, 7 Apr 2010 10:30:41 -0500
Received: from bd01xsmtp004.US.Cingular.Net ([]) by td03xsmtp005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 10:30:41 -0500
Received: from BD01MSXMB015.US.Cingular.Net ([]) by bd01xsmtp004.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Apr 2010 08:30:40 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Apr 2010 08:30:39 -0700
Message-ID: <BE16D422273834438B43B6F7D730220F0D1A2FDB@BD01MSXMB015.US.Cingular.Net>
In-Reply-To: <>
Thread-Topic: [earlywarning] Finishing the Charter Text Discussions
Thread-Index: AcrVevzdbW3lKIJYTyi/UOYzlZHd8gA6/1cQ
References: <>
To: "Hannes Tschofenig" <>, <>
X-OriginalArrivalTime: 07 Apr 2010 15:30:40.0495 (UTC) FILETIME=[479D57F0:01CAD667]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Apr 2010 15:32:23 -0000

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."


DeWayne A. Sennett

-----Original Message-----
[] On Behalf Of Hannes Tschofenig
Sent: Tuesday, April 06, 2010 4:18 AM
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

Is the charter text OK for everyone? 



Authority to Citizen Alert (ATOCA)

Authorities need mechanisms to notify citizens and visitors of emergency
events.   Traditionally, they have done so with broadcast networks
and television).  The Internet provides another way for authority to
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
focuses on delivering alerts to IP endpoints only. 

The general message pattern that this group is intended to address is
sending of alerts from a set of pre-authorized agents (e.g.,
agencies) to a large population. The goal of this group is not to
how originators of alerts obtain authorization, but rather how a
system can verify authorization and deliver message to the intended
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
the Internet and private IP networks which humans may have ?at hand? to
such events, as well as automatons who may take action based on the
This implies that the content of the alert contains some information
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
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
be used. The work on a resource priority mechanism is out of scope of
initial charter, but may be revisited at a later date.

Which devices should get alerts is primarily driven by location.  The
set of recipients that must be catered for are those within the area
affected by the alert.  In many jurisdictions, there are regulations
define whether recipients within the affected area have opt-in or
capability, but the protocols we will define will include both opt-in
opt-out mechanisms. The group will explore how to support both opt-in
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
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,
ETSI and 3GPP also have alert efforts underway, and consultation with
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
devices are profound, but the utility of the mechanism encourages us to
the problems and solve them. 

TBD      Initial document for "Terminology and Framework" document. 
         A starting point for this work is
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 

earlywarning mailing list