Re: [earlywarning] Final Charter Text. Thanks!

"Thomson, Martin" <> Mon, 31 May 2010 23:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5509A3A6782 for <>; Mon, 31 May 2010 16:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.432
X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m4JrgYKm74Cj for <>; Mon, 31 May 2010 16:22:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 20A8E3A672E for <>; Mon, 31 May 2010 16:22:27 -0700 (PDT)
Received: from [] ([]:3544 "EHLO") by with ESMTP id S287517Ab0EaXWQ (ORCPT <rfc822;>); Mon, 31 May 2010 18:22:16 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 31 May 2010 18:22:15 -0500
Received: from ([fe80::9d82:a492:85e3:a293]) by ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 1 Jun 2010 07:22:13 +0800
From: "Thomson, Martin" <>
To: Hannes Tschofenig <>, "" <>
Date: Tue, 1 Jun 2010 07:24:02 +0800
Thread-Topic: [earlywarning] Final Charter Text. Thanks!
Thread-Index: AcsBBiG1BJuC69RpSgqvq/lpCGYbzwAEjOGg
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on
Subject: Re: [earlywarning] Final Charter Text. Thanks!
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, 31 May 2010 23:22:29 -0000

I'm OK with this.

> -----Original Message-----
> From: [mailto:earlywarning-
>] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, 1 June 2010 7:13 AM
> To:
> Subject: [earlywarning] Final Charter Text. Thanks!
> 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.
> _______________________________________________
> earlywarning mailing list