Re: [earlywarning] Final Charter Text. Thanks!
"Thomson, Martin" <Martin.Thomson@andrew.com> Mon, 31 May 2010 23:22 UTC
Return-Path: <Martin.Thomson@andrew.com>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5509A3A6782 for <earlywarning@core3.amsl.com>; Mon, 31 May 2010 16:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.432
X-Spam-Level:
X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4JrgYKm74Cj for <earlywarning@core3.amsl.com>; Mon, 31 May 2010 16:22:28 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 20A8E3A672E for <earlywarning@ietf.org>; Mon, 31 May 2010 16:22:27 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:3544 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S287517Ab0EaXWQ (ORCPT <rfc822; earlywarning@ietf.org>); Mon, 31 May 2010 18:22:16 -0500
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 31 May 2010 18:22:15 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 1 Jun 2010 07:22:13 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, "earlywarning@ietf.org" <earlywarning@ietf.org>
Date: Tue, 01 Jun 2010 07:24:02 +0800
Thread-Topic: [earlywarning] Final Charter Text. Thanks!
Thread-Index: AcsBBiG1BJuC69RpSgqvq/lpCGYbzwAEjOGg
Message-ID: <8B0A9FCBB9832F43971E38010638454F03E7F1F02C@SISPE7MB1.commscope.com>
References: <20100531211316.310600@gmx.net>
In-Reply-To: <20100531211316.310600@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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 csmailgw2.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Subject: Re: [earlywarning] Final Charter Text. Thanks!
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 May 2010 23:22:29 -0000
I'm OK with this. > -----Original Message----- > From: earlywarning-bounces@ietf.org [mailto:earlywarning- > bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Tuesday, 1 June 2010 7:13 AM > To: earlywarning@ietf.org > 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 > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning
- Re: [earlywarning] Final Charter Text. Thanks! DALY, BRIAN K (ATTCINW)
- Re: [earlywarning] Final Charter Text. Thanks! DRAGE, Keith (Keith)
- Re: [earlywarning] Final Charter Text. Thanks! Hannes Tschofenig
- [earlywarning] Final Charter Text. Thanks! Hannes Tschofenig
- Re: [earlywarning] Final Charter Text. Thanks! Thomson, Martin
- Re: [earlywarning] Final Charter Text. Thanks! DRAGE, Keith (Keith)