Re: [earlywarning] New Charter Text Proposal
Brian Rosen <br@brianrosen.net> Tue, 11 May 2010 13:14 UTC
Return-Path: <br@brianrosen.net>
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 6476B28C168 for <earlywarning@core3.amsl.com>; Tue, 11 May 2010 06:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.058
X-Spam-Level:
X-Spam-Status: No, score=-0.058 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
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 Kmh3Wj0-V4Mr for <earlywarning@core3.amsl.com>; Tue, 11 May 2010 06:14:20 -0700 (PDT)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 2383C3A6CED for <earlywarning@ietf.org>; Tue, 11 May 2010 06:12:34 -0700 (PDT)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.74]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1OBpFw-0002HB-1Y; Tue, 11 May 2010 08:12:16 -0500
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 11 May 2010 09:12:16 -0400
From: Brian Rosen <br@brianrosen.net>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>, "earlywarning@ietf.org" <earlywarning@ietf.org>
Message-ID: <C80ECFF0.33AFB%br@brianrosen.net>
Thread-Topic: [earlywarning] New Charter Text Proposal
Thread-Index: AcrxC5PLhIS3eQxupkWgZbiUmiFyCQ==
In-Reply-To: <4BE19433.3050604@gmx.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
Subject: Re: [earlywarning] New Charter Text Proposal
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: Tue, 11 May 2010 13:14:21 -0000
Okay with me On 5/5/10 11:52 AM, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> 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 > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning
- [earlywarning] New Charter Text Proposal Hannes Tschofenig
- Re: [earlywarning] New Charter Text Proposal Hannes Tschofenig
- Re: [earlywarning] New Charter Text Proposal Richard Barnes
- Re: [earlywarning] New Charter Text Proposal Thomson, Martin
- Re: [earlywarning] New Charter Text Proposal Marc Linsner
- Re: [earlywarning] New Charter Text Proposal ken carlberg
- Re: [earlywarning] New Charter Text Proposal Brian Rosen
- Re: [earlywarning] New Charter Text Proposal James M. Polk