Re: [earlywarning] New Charter Text Proposal

Hannes Tschofenig <> Mon, 10 May 2010 19:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8371828C234 for <>; Mon, 10 May 2010 12:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VN1eBcEVDym1 for <>; Mon, 10 May 2010 12:59:54 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 059AA28C23E for <>; Mon, 10 May 2010 12:48:18 -0700 (PDT)
Received: (qmail invoked by alias); 10 May 2010 19:41:06 -0000
Received: from (EHLO []) [] by (mp069) with SMTP; 10 May 2010 21:41:06 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/Tbkpw2S7Tfs5i6KF089g8BvLlkRzIEslFMXA1UU EZXSWc7awEWUg3
Message-ID: <>
Date: Mon, 10 May 2010 12:40:59 -0700
From: Hannes Tschofenig <>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Subject: Re: [earlywarning] New Charter Text Proposal
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: Mon, 10 May 2010 19:59:55 -0000

Please provide your feedback at latest by 28th May 2010.


Hannes Tschofenig wrote:
> Hi all,
> as you all have seen it is a bit difficult to come up with a text that 
> makes everyone happy. Please find an updated proposal below based on 
> the recent discussions on the list.
> Ciao
> Hannes
> Authority to Citizen Alert (ATOCA)
> ==================================
> There are a variety of mechanisms that authorities have available to
> notify citizens and visitors of 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 the process of being deployed.  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 the 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 that
> 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.).
> This work is differentiated from and is not intended to replace other
> alerting mechanisms (e.g., PWS, CMAS, ETWS), as the recipients of these
> ATOCA 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 (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 alert.  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 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 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 layer 2 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.
> 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.
> _______________________________________________
> earlywarning mailing list