Re: [earlywarning] New Charter Text Proposal
Marc Linsner <mlinsner@cisco.com> Tue, 11 May 2010 10:49 UTC
Return-Path: <mlinsner@cisco.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 473663A6B6F for <earlywarning@core3.amsl.com>; Tue, 11 May 2010 03:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.466
X-Spam-Level:
X-Spam-Status: No, score=-8.466 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8]
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 gNzqKIOgYov8 for <earlywarning@core3.amsl.com>; Tue, 11 May 2010 03:49:41 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AC5173A6ABC for <earlywarning@ietf.org>; Tue, 11 May 2010 03:49:40 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggIAHLT6EurRN+J/2dsb2JhbACeKGsGoGeZZIJggjAE
X-IronPort-AV: E=Sophos;i="4.53,206,1272844800"; d="scan'208";a="528068757"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 11 May 2010 10:49:30 +0000
Received: from [172.17.193.133] ([10.21.70.146]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o4BAnSxC016727 for <earlywarning@ietf.org>; Tue, 11 May 2010 10:49:28 GMT
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 11 May 2010 06:49:27 -0400
From: Marc Linsner <mlinsner@cisco.com>
To: "earlywarning@ietf.org" <earlywarning@ietf.org>
Message-ID: <C80EAE77.24550%mlinsner@cisco.com>
Thread-Topic: [earlywarning] New Charter Text Proposal
Thread-Index: Acrw96BFRKTopLo1uEyTYD+rth8LJw==
In-Reply-To: <4BE8614B.6010903@gmx.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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 10:49:42 -0000
Works for me. -Marc- On 5/10/10 3:40 PM, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> wrote: > Please provide your feedback at latest by 28th May 2010. > Thanks. > > Ciao > Hannes > > 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 >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > > _______________________________________________ > 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