From bs7652@att.com Tue Jul 7 09:09:13 2009 Return-Path: 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 CCF7F3A6ABE for ; Tue, 7 Jul 2009 09:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.5 X-Spam-Level: X-Spam-Status: No, score=-106.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 4Ul0GCygxNy7 for ; Tue, 7 Jul 2009 09:09:12 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id B9B1A3A6E44 for ; Tue, 7 Jul 2009 09:08:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-9.tower-121.messagelabs.com!1246982929!26981737!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 10443 invoked from network); 7 Jul 2009 16:08:50 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-9.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2009 16:08:50 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n67G8njO009270 for ; Tue, 7 Jul 2009 12:08:49 -0400 Received: from 01GAF5142010625.AD.BLS.COM (01GAF5142010625.ad.bls.com [139.76.131.31]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n67G8geY009134 for ; Tue, 7 Jul 2009 12:08:42 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 12:08:41 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 12:08:41 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jul 2009 12:08:40 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0EFE5AE6@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: another interesting news article thread-index: Acn/HTEZt1i2aUUTTuGwzx8KIfGeQw== From: "Stark, Barbara" To: X-OriginalArrivalTime: 07 Jul 2009 16:08:41.0816 (UTC) FILETIME=[3233CD80:01C9FF1D] Subject: [earlywarning] another interesting news article X-BeenThere: earlywarning@ietf.org 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: Tue, 07 Jul 2009 16:09:13 -0000 http://www.usatoday.com/news/nation/2009-07-06-ealerts_N.htm Barbara ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 From Hannes.Tschofenig@gmx.net Sun Jul 12 03:55:34 2009 Return-Path: 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 539BE3A68AB for ; Sun, 12 Jul 2009 03:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[AWL=-0.894, 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 ks9gaCMFCq2g for ; Sun, 12 Jul 2009 03:55:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CF27C3A687E for ; Sun, 12 Jul 2009 03:55:29 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2009 10:55:56 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp052) with SMTP; 12 Jul 2009 12:55:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+tiPMXS9etfFdw+fjIyRcWRniv7KwSLaJ8W+qudU v3il1KQGKfanPM From: "Hannes Tschofenig" To: , Date: Sun, 12 Jul 2009 13:58:13 +0300 Message-ID: <187701ca02df$a80ff0e0$501ca20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoC36b7j3zEcOs9RyKYQbyxpU/7yA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Subject: [earlywarning] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Sun, 12 Jul 2009 10:55:34 -0000 Hi all, I am currently looking at the element found in the CAP specification. The description says "The code denoting the category of the subject event of the alert message" and a few values are listed as well: "Geo" - Geophysical (inc. landslide) "Met" - Meteorological (inc. flood) "Safety" - General emergency and public safety "Security" - Law enforcement, military, homeland and local/private security "Rescue" - Rescue and recovery "Fire" - Fire suppression and rescue "Health" - Medical and public health "Env" - Pollution and other environmental "Transport" - Public and private transportation "Infra" - Utility, telecommunication, other non-transport infrastructure "CBRNE" - Chemical, Biological, Radiological, Nuclear or High-Yield Explosive threat or attack "Other" - Other events I was wondering whether there is somewhere a more verbose / more complete description of the semantic of the individual values. Ciao Hannes From acb@incident.com Sun Jul 12 08:51:18 2009 Return-Path: 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 54FB43A6C13 for ; Sun, 12 Jul 2009 08:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 pvYF839zSYS4 for ; Sun, 12 Jul 2009 08:51:17 -0700 (PDT) Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id 7C3D03A6C14 for ; Sun, 12 Jul 2009 08:51:17 -0700 (PDT) Received: (qmail 26583 invoked from network); 12 Jul 2009 15:51:45 -0000 Received: from unknown (HELO postfix.incident.com) (acb@99.182.125.96 with login) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 12 Jul 2009 15:51:45 -0000 X-Yahoo-SMTP: vPhT.EeswBCqpJNRI7jKigo5rdzzHPEykVa7e4bkNNvf X-YMail-OSG: Y67cYlIVM1nxUuThtG7pmsawGm5riYrtB0qJoZabhUy6l8ifJIrGI5A98Pi3MZRJ9flDK29xt.X7m1dlO7whu3mtNvXzQc_Kxlr5vKfDrhuEnJVOtzwjD5vQnuGINCtVQoJtdeabVTGNgimBm6ac1IbsAvuq4Cs_D77lzuNHU_bMFG0H.Asgqdo77u8WkuVC41ygFMpXDK90ARhg628exkrKlCON3YfP1By38AglzbF3JHybY.E6IfTYRsxPhPP0Nawj7zGDdUqN5ms- X-Yahoo-Newman-Property: ymail-3 Received: from [127.0.0.1] (localhost [127.0.0.1]) by postfix.incident.com (Postfix) with ESMTP id 4FC182063171; Sun, 12 Jul 2009 08:51:44 -0700 (PDT) Message-Id: <8C3B4F90-C248-418C-9DC3-D9EFAFCCFF50@incident.com> From: Art Botterell To: cap-list@incident.com, earlywarning@ietf.org In-Reply-To: <187701ca02df$a80ff0e0$501ca20a@nsnintra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 12 Jul 2009 08:51:43 -0700 References: <187701ca02df$a80ff0e0$501ca20a@nsnintra.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Sun, 12 Jul 2009 15:51:18 -0000 On Jul 12, 2009, at 7/12/09 3:58 AM, Hannes Tschofenig wrote: > I was wondering whether there is somewhere a more verbose / more > complete > description of the semantic of the individual values. No, and that's deliberate. Considering the high levels of uncertainty that so often surround emergent events, the CAP designers (first in the CAP Working Group and later within OASIS) struggled to balance completeness against specificity. There was also a concern that we could get bogged down in trying to perfect the taxonomies and wind up with no standard at all. So the definitions were deliberately left somewhat open-ended and contextual... some would go so far as to say "vague" and I, for one, wouldn't argue. - Art From acb@incident.com Sun Jul 12 11:23:09 2009 Return-Path: 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 A2CBB28C179 for ; Sun, 12 Jul 2009 11:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] 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 Ykwmj3I+lR+S for ; Sun, 12 Jul 2009 11:23:08 -0700 (PDT) Received: from n72.bullet.mail.sp1.yahoo.com (n72.bullet.mail.sp1.yahoo.com [98.136.44.34]) by core3.amsl.com (Postfix) with SMTP id 6014628C175 for ; Sun, 12 Jul 2009 11:23:05 -0700 (PDT) Received: from [69.147.84.144] by n72.bullet.mail.sp1.yahoo.com with NNFMP; 12 Jul 2009 18:23:33 -0000 Received: from [68.142.200.221] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 12 Jul 2009 18:23:33 -0000 Received: from [68.142.201.253] by t9.bullet.mud.yahoo.com with NNFMP; 12 Jul 2009 18:23:33 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 12 Jul 2009 18:23:33 -0000 X-Yahoo-Newman-Id: 691479.70895.bm@omp414.mail.mud.yahoo.com Received: (qmail 77134 invoked from network); 12 Jul 2009 18:23:33 -0000 Received: from unknown (HELO postfix.incident.com) (acb@99.182.125.96 with login) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 12 Jul 2009 18:23:32 -0000 X-YMail-OSG: ejMA6ysVM1kUpzpxGmbBACt0PT8NCv13SDQ1FU6d3OGiXwfqMQCM_UyHVrFGhFxA27mChAixmYDEslLDcPN_KHxO5RDlv0VA3GFFrM7hMJPyENmrzjTrQ.ZF17wwVGF4xJfBXNQraQlWVIKA7ZLXFoLVKFMX_9PebDSHNiIfDuFCBDlBbxmiy0fI2v20wPCqtn7RcDq7OJHo3n4TrSxAdsQO4iBpIDyDa9R06vrA4rBBf6ySvTV3.aNQf_4UFsopMr69RMldF1X_7tniLrWXDoafu.6NCm3A3uEDuFxrmceVyxM- X-Yahoo-Newman-Property: ymail-3 Received: from [127.0.0.1] (localhost [127.0.0.1]) by postfix.incident.com (Postfix) with ESMTP id 9E3F32063850; Sun, 12 Jul 2009 11:23:31 -0700 (PDT) Message-Id: <9E54E462-245A-4EC9-81D0-5A169DA2411C@incident.com> From: Art Botterell To: cap-list@incident.com, earlywarning@ietf.org In-Reply-To: <7B88AB507ED649F2B28CF1829AD3D122@xppc1> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 12 Jul 2009 11:23:31 -0700 References: <187701ca02df$a80ff0e0$501ca20a@nsnintra.net> <8C3B4F90-C248-418C-9DC3-D9EFAFCCFF50@incident.com> <7B88AB507ED649F2B28CF1829AD3D122@xppc1> X-Mailer: Apple Mail (2.935.3) Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Sun, 12 Jul 2009 18:23:09 -0000 David has it exactly. I would expect that in some future "CAP 2.0" the concept of managed lists might be extended back into CAP... assuming interested communities start making headway on building such lists. - Art On Jul 12, 2009, at 7/12/09 9:54 AM, David Aylward (Comcare) wrote: > Hannes: > > As Art says, CAP's incident list is very general. To further Art's > point, > when it came to the development of what became the OASIS EDXL > Distribution > Element (DE), we faced the same issue as a primary purpose of the DE > is > routing messages by incident type. The CAP categories were far too > broad > for that. > > So the draft requirements and specification for the DE developed by > the > cross emergency domain practitioner working group developed a > detailed list > of incident types for submission to the OASIS EMTC as part of its > request > for the development of that standard. > > The EMTC wisely rejected our suggestion, thinking that (1) the work to > create a shared incident type taxomony should be done for the US and > other > countries, but hadn't been done yet, and (2) such lists of incident > types > would likely change more frequently than the standard. > > So they adopted a flexible solution of "Managed Lists" for this and > similar > list issues (e.g. roles). Under this approach values such as > incident > names appear in the standard, along with the name of the managed > list you > are using. If there is only one Managed List for that topic in the > world, > great, but if there are several you can still communicate because > you know > which list is being used. > > The absence of both initial managed lists and a repository for their > locations is an identified gap that hopefully will be addressed > soon. A > number of us developed a project to do Managed Lists for incident > names and > roles, but other priorities have gotten in the way. > > > > > David K. Aylward, President > COMCARE Emergency Response Technology Group > 1351 Independence Court, SE > Washington, DC 20003 > 202.255.3215 (mobile) > 202.295.0136 (office) > 202.521.4047 (fax) > daylward@comcare.org > > This communication is intended for the use of the recipient to which > it is > addressed, and may contain confidential, personal and/or privileged > information. Please contact us immediately if you are not the intended > recipient of this communication, and do not copy, distribute, or > take action > relying on it. Any communication received in error, or subsequent > reply, > should be deleted or destroyed. > > > -----Original Message----- > From: cap-list-bounces@lists.incident.com > [mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art > Botterell > Sent: Sunday, July 12, 2009 11:52 AM > To: cap-list@incident.com; earlywarning@ietf.org > Subject: Re: [CAP] Definition of Warning Categories > > On Jul 12, 2009, at 7/12/09 3:58 AM, Hannes Tschofenig wrote: >> I was wondering whether there is somewhere a more verbose / more >> complete >> description of the semantic of the individual values. > > No, and that's deliberate. Considering the high levels of uncertainty > that so often surround emergent events, the CAP designers (first in > the CAP Working Group and later within OASIS) struggled to balance > completeness against specificity. There was also a concern that we > could get bogged down in trying to perfect the taxonomies and wind up > with no standard at all. > > So the definitions were deliberately left somewhat open-ended and > contextual... some would go so far as to say "vague" and I, for one, > wouldn't argue. > > - Art > > > > _______________________________________________ > This list is for public discussion of the Common Alerting Protocol. > This > list is NOT part of the formal record of the OASIS Emergency > Management TC. > Comments for the OASIS record should be posted using the form at > http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency > CAP-list mailing list > CAP-list@lists.incident.com > http://lists.incident.com/mailman/listinfo/cap-list > > This list is not for announcements, advertising or advocacy of any > particular program or product other than the CAP itself. > > > > _______________________________________________ > This list is for public discussion of the Common Alerting Protocol. > This list is NOT part of the formal record of the OASIS Emergency > Management TC. Comments for the OASIS record should be posted using > the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency > CAP-list mailing list > CAP-list@lists.incident.com > http://lists.incident.com/mailman/listinfo/cap-list > > This list is not for announcements, advertising or advocacy of any > particular program or product other than the CAP itself. From Hannes.Tschofenig@gmx.net Sun Jul 12 11:55:31 2009 Return-Path: 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 34EBE3A68D2 for ; Sun, 12 Jul 2009 11:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599] 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 6KriLOtNtqdD for ; Sun, 12 Jul 2009 11:55:30 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 935723A6B66 for ; Sun, 12 Jul 2009 11:55:29 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2009 18:55:57 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp071) with SMTP; 12 Jul 2009 20:55:57 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+ZgsELgB6ZPuSAVUazdNsmYvEyA/Faf9uHxMQtaq wDxsJtno4syPK4 From: "Hannes Tschofenig" To: "'Elizabeth F. Klute'" , , , References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> Date: Sun, 12 Jul 2009 21:58:16 +0300 Message-ID: <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoDCFUbyDH9YNYRQQa7JasYXVhf2wADqf4XAAKyfwA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Sun, 12 Jul 2009 18:55:31 -0000 I should provide a bit more feedback about the background to my question. If you only set the value in the category field for the purpose of human consumption then there is not really an interoperability issue. Now, with the work on http://tools.ietf.org/html/draft-rosen-sipping-cap-03 we wanted to define an event package for SIP that allows you to "subscribe" to certain type of events: you might indicate something like location and the type of events you are interested in. Now, the semantic of the category field suddently matters. With the individuals-to-citizen emergency services we tried to come up with a description of the emergency services categories, see RFC 5031. Ciao Hannes >-----Original Message----- >From: cap-list-bounces@lists.incident.com >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of >Elizabeth F. Klute >Sent: 12 July, 2009 20:28 >To: acb@incident.com; cap-list@incident.com; earlywarning@ietf.org >Subject: Re: [CAP] Definition of Warning Categories > >Thanks Art, > >I was struggeling on how to answer but could not have done it better! >Elizabeth Klute, Director Disaster Management > >----- Original Message ----- >From: cap-list-bounces@lists.incident.com > >To: cap-list@incident.com ; >earlywarning@ietf.org >Sent: Sun Jul 12 11:51:43 2009 >Subject: Re: [CAP] Definition of Warning Categories > >On Jul 12, 2009, at 7/12/09 3:58 AM, Hannes Tschofenig wrote: >> I was wondering whether there is somewhere a more verbose / more >> complete description of the semantic of the individual values. > >No, and that's deliberate. Considering the high levels of >uncertainty that so often surround emergent events, the CAP >designers (first in the CAP Working Group and later within >OASIS) struggled to balance completeness against specificity. >There was also a concern that we could get bogged down in >trying to perfect the taxonomies and wind up with no standard at all. > >So the definitions were deliberately left somewhat open-ended >and contextual... some would go so far as to say "vague" and >I, for one, wouldn't argue. > >- Art > > > >_______________________________________________ >This list is for public discussion of the Common Alerting >Protocol. This list is NOT part of the formal record of the >OASIS Emergency Management TC. Comments for the OASIS record >should be posted using the form at >http://www.oasis-open.org/committees/comments/form.php?wg_abbre >v=emergency >CAP-list mailing list >CAP-list@lists.incident.com >http://lists.incident.com/mailman/listinfo/cap-list > >This list is not for announcements, advertising or advocacy of >any particular program or product other than the CAP itself. >_______________________________________________ >This list is for public discussion of the Common Alerting >Protocol. This list is NOT part of the formal record of the >OASIS Emergency Management TC. Comments for the OASIS record >should be posted using the form at >http://www.oasis-open.org/committees/comments/form.php?wg_abbre >v=emergency >CAP-list mailing list >CAP-list@lists.incident.com >http://lists.incident.com/mailman/listinfo/cap-list > >This list is not for announcements, advertising or advocacy of >any particular program or product other than the CAP itself. > From Hannes.Tschofenig@gmx.net Sun Jul 12 12:04:27 2009 Return-Path: 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 67E2C28B23E for ; Sun, 12 Jul 2009 12:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599] 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 WJh3HzjPJ8Xc for ; Sun, 12 Jul 2009 12:04:26 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B95AF3A67CF for ; Sun, 12 Jul 2009 12:04:25 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2009 19:04:54 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp042) with SMTP; 12 Jul 2009 21:04:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Z2n0bLfZZxoXTmgCfHfxWQ1CAwyPnJK4BuFCf+p M4+f4YNfQgzFXn From: "Hannes Tschofenig" To: "'David Aylward \(Comcare\)'" , , References: <187701ca02df$a80ff0e0$501ca20a@nsnintra.net><8C3B4F90-C248-418C-9DC3-D9EFAFCCFF50@incident.com> <7B88AB507ED649F2B28CF1829AD3D122@xppc1> Date: Sun, 12 Jul 2009 22:07:13 +0300 Message-ID: <18ef01ca0323$f75b60a0$501ca20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7B88AB507ED649F2B28CF1829AD3D122@xppc1> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcoDCVgmerNFJDMgT0uSSmgCVS2P2AAAq0lgAAWvZxA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.48 Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Sun, 12 Jul 2009 19:04:27 -0000 Hi David,=20 Is this really so difficult?=20 Here is what I would do: Setup a registry that associates labels with a description of what the label means. Someone maintains the registry (in = the IETF we use IANA). Someone adds a new term - fine. Deleting unused or revised terms is fine as well.=20 So, is there an initial list flying around somewhere already?=20 Ciao Hannes PS: What is the element in the CAP document used for today?=20 >-----Original Message----- >From: cap-list-bounces@lists.incident.com=20 >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of=20 >David Aylward (Comcare) >Sent: 12 July, 2009 19:55 >To: cap-list@incident.com; earlywarning@ietf.org >Subject: Re: [CAP] Definition of Warning Categories > >Hannes: > >As Art says, CAP's incident list is very general. To further=20 >Art's point, when it came to the development of what became=20 >the OASIS EDXL Distribution Element (DE), we faced the same=20 >issue as a primary purpose of the DE is routing messages by=20 >incident type. The CAP categories were far too broad for that. =20 > >So the draft requirements and specification for the DE=20 >developed by the cross emergency domain practitioner working=20 >group developed a detailed list of incident types for=20 >submission to the OASIS EMTC as part of its request for the=20 >development of that standard. > >The EMTC wisely rejected our suggestion, thinking that (1) the=20 >work to create a shared incident type taxomony should be done=20 >for the US and other countries, but hadn't been done yet, and=20 >(2) such lists of incident types would likely change more=20 >frequently than the standard. =20 > >So they adopted a flexible solution of "Managed Lists" for=20 >this and similar >list issues (e.g. roles). Under this approach values such as incident >names appear in the standard, along with the name of the=20 >managed list you are using. If there is only one Managed List=20 >for that topic in the world, great, but if there are several=20 >you can still communicate because you know which list is being used. =20 > >The absence of both initial managed lists and a repository for=20 >their locations is an identified gap that hopefully will be=20 >addressed soon. A number of us developed a project to do=20 >Managed Lists for incident names and roles, but other=20 >priorities have gotten in the way. > > > >=A0 >David K. Aylward, President >COMCARE Emergency Response Technology Group >1351 Independence Court, SE >Washington, DC 20003 >202.255.3215 (mobile) >202.295.0136=A0(office) >202.521.4047 (fax) >daylward@comcare.org >=A0 >This communication is intended for the use of the recipient to=20 >which it is addressed, and may contain confidential, personal=20 >and/or privileged information. Please contact us immediately=20 >if you are not the intended recipient of this communication,=20 >and do not copy, distribute, or take action relying on it. Any=20 >communication received in error, or subsequent reply, should=20 >be deleted or destroyed. > > >-----Original Message----- >From: cap-list-bounces@lists.incident.com >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art Botterell >Sent: Sunday, July 12, 2009 11:52 AM >To: cap-list@incident.com; earlywarning@ietf.org >Subject: Re: [CAP] Definition of Warning Categories > >On Jul 12, 2009, at 7/12/09 3:58 AM, Hannes Tschofenig wrote: >> I was wondering whether there is somewhere a more verbose / more=20 >> complete description of the semantic of the individual values. > >No, and that's deliberate. Considering the high levels of=20 >uncertainty that so often surround emergent events, the CAP=20 >designers (first in the CAP Working Group and later within=20 >OASIS) struggled to balance completeness against specificity. =20 >There was also a concern that we could get bogged down in=20 >trying to perfect the taxonomies and wind up with no standard at all. > >So the definitions were deliberately left somewhat open-ended=20 >and contextual... some would go so far as to say "vague" and=20 >I, for one, wouldn't argue. > >- Art > > > >_______________________________________________ >This list is for public discussion of the Common Alerting=20 >Protocol. This list is NOT part of the formal record of the=20 >OASIS Emergency Management TC. >Comments for the OASIS record should be posted using the form=20 >at=20 >http://www.oasis-open.org/committees/comments/form.php?wg_abbre >v=3Demergency >CAP-list mailing list >CAP-list@lists.incident.com >http://lists.incident.com/mailman/listinfo/cap-list > >This list is not for announcements, advertising or advocacy of=20 >any particular program or product other than the CAP itself. > > > >_______________________________________________ >This list is for public discussion of the Common Alerting=20 >Protocol. This list is NOT part of the formal record of the=20 >OASIS Emergency Management TC. Comments for the OASIS record=20 >should be posted using the form at=20 >http://www.oasis-open.org/committees/comments/form.php?wg_abbre >v=3Demergency >CAP-list mailing list >CAP-list@lists.incident.com >http://lists.incident.com/mailman/listinfo/cap-list > >This list is not for announcements, advertising or advocacy of=20 >any particular program or product other than the CAP itself. > From daylward@natstrat.com Sun Jul 12 09:54:25 2009 Return-Path: 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 E4A703A6954 for ; Sun, 12 Jul 2009 09:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 6HPN4u7XtJj9 for ; Sun, 12 Jul 2009 09:54:24 -0700 (PDT) Received: from server514.appriver.com (server514a.exghost.com [72.32.253.68]) by core3.amsl.com (Postfix) with ESMTP id A13E33A689A for ; Sun, 12 Jul 2009 09:54:24 -0700 (PDT) Received: by server514.appriver.com (CommuniGate Pro PIPE 5.2.14) with PIPE id 63611858; Sun, 12 Jul 2009 11:54:28 -0500 Received: from [72.32.253.140] (HELO FE01.exg4.exghost.com) by server514.appriver.com (CommuniGate Pro SMTP 5.2.14) with ESMTP id 63611852; Sun, 12 Jul 2009 11:54:26 -0500 Received: from FE01.exg4.exghost.com ([10.242.228.17]) by FE01.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 11:54:52 -0500 Received: from xppc1 ([67.192.118.158]) by FE01.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 11:54:51 -0500 From: "David Aylward \(Comcare\)" To: , References: <187701ca02df$a80ff0e0$501ca20a@nsnintra.net> <8C3B4F90-C248-418C-9DC3-D9EFAFCCFF50@incident.com> Date: Sun, 12 Jul 2009 12:54:56 -0400 Message-ID: <7B88AB507ED649F2B28CF1829AD3D122@xppc1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoDCVgmerNFJDMgT0uSSmgCVS2P2AAAq0lg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <8C3B4F90-C248-418C-9DC3-D9EFAFCCFF50@incident.com> X-OriginalArrivalTime: 12 Jul 2009 16:54:51.0918 (UTC) FILETIME=[796092E0:01CA0311] X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Primary: daylward@natstrat.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: daylward@natstrat.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.253.140 X-Note-Reverse-DNS: fe01.exg4.exghost.com X-Note-WHTLIST: daylward@natstrat.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 114 115 116 117 121 122 133 214 X-Note: Mail Class: ALLOWEDSENDER X-Mailman-Approved-At: Sun, 12 Jul 2009 12:07:21 -0700 Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Sun, 12 Jul 2009 16:56:26 -0000 Hannes: As Art says, CAP's incident list is very general. To further Art's = point, when it came to the development of what became the OASIS EDXL = Distribution Element (DE), we faced the same issue as a primary purpose of the DE is routing messages by incident type. The CAP categories were far too = broad for that. =20 So the draft requirements and specification for the DE developed by the cross emergency domain practitioner working group developed a detailed = list of incident types for submission to the OASIS EMTC as part of its = request for the development of that standard. The EMTC wisely rejected our suggestion, thinking that (1) the work to create a shared incident type taxomony should be done for the US and = other countries, but hadn't been done yet, and (2) such lists of incident = types would likely change more frequently than the standard. =20 So they adopted a flexible solution of "Managed Lists" for this and = similar list issues (e.g. roles). Under this approach values such as incident names appear in the standard, along with the name of the managed list = you are using. If there is only one Managed List for that topic in the = world, great, but if there are several you can still communicate because you = know which list is being used. =20 The absence of both initial managed lists and a repository for their locations is an identified gap that hopefully will be addressed soon. A number of us developed a project to do Managed Lists for incident names = and roles, but other priorities have gotten in the way. =A0 David K. Aylward, President COMCARE Emergency Response Technology Group 1351 Independence Court, SE Washington, DC 20003 202.255.3215 (mobile) 202.295.0136=A0(office) 202.521.4047 (fax) daylward@comcare.org =A0 This communication is intended for the use of the recipient to which it = is addressed, and may contain confidential, personal and/or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take = action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. -----Original Message----- From: cap-list-bounces@lists.incident.com [mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art Botterell Sent: Sunday, July 12, 2009 11:52 AM To: cap-list@incident.com; earlywarning@ietf.org Subject: Re: [CAP] Definition of Warning Categories On Jul 12, 2009, at 7/12/09 3:58 AM, Hannes Tschofenig wrote: > I was wondering whether there is somewhere a more verbose / more =20 > complete > description of the semantic of the individual values. No, and that's deliberate. Considering the high levels of uncertainty =20 that so often surround emergent events, the CAP designers (first in =20 the CAP Working Group and later within OASIS) struggled to balance =20 completeness against specificity. There was also a concern that we =20 could get bogged down in trying to perfect the taxonomies and wind up =20 with no standard at all. So the definitions were deliberately left somewhat open-ended and =20 contextual... some would go so far as to say "vague" and I, for one, =20 wouldn't argue. - Art _______________________________________________ This list is for public discussion of the Common Alerting Protocol. = This list is NOT part of the formal record of the OASIS Emergency Management = TC. Comments for the OASIS record should be posted using the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=3Demerge= ncy CAP-list mailing list CAP-list@lists.incident.com http://lists.incident.com/mailman/listinfo/cap-list This list is not for announcements, advertising or advocacy of any particular program or product other than the CAP itself. From acb@incident.com Sun Jul 12 12:22:46 2009 Return-Path: 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 2808728C175 for ; Sun, 12 Jul 2009 12:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, 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 ZZS43BH4JkNn for ; Sun, 12 Jul 2009 12:22:45 -0700 (PDT) Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id 6F3DA3A6B66 for ; Sun, 12 Jul 2009 12:22:45 -0700 (PDT) Received: (qmail 14882 invoked from network); 12 Jul 2009 19:23:13 -0000 Received: from unknown (HELO postfix.incident.com) (acb@99.182.125.96 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 12 Jul 2009 19:23:13 -0000 X-Yahoo-SMTP: vPhT.EeswBCqpJNRI7jKigo5rdzzHPEykVa7e4bkNNvf X-YMail-OSG: 569svdQVM1mPfWiHilGyjbxP0SdnV9N.jXBXsd_h0KZv8uF4Zb1TCpAG8tnhomlADTJvGCJQnycE8amLM9ZWldScw8.VBYXRCr6V6CSrDFrCnUiYZT_WlvQ8.e2Wd_CcHJ54PNljXYaQEZI..VIBMRvGTbrp10505czBBDU_XPyQcNpEqZW9dIOuwKFTZu7uqd2rZpMZc3eSJ858EvEoA76VXnbrmuYZ7WxyB6XwUlWiLA4sfDbQ3Z8pfISgryvAegBS_X2fkcGMYh9DXH5kl1RQevRABqtgDU8CvOOZQGDhx90- X-Yahoo-Newman-Property: ymail-3 Received: from [127.0.0.1] (localhost [127.0.0.1]) by postfix.incident.com (Postfix) with ESMTP id 5E66A2063C2F; Sun, 12 Jul 2009 12:23:12 -0700 (PDT) Message-Id: <30076E62-60BC-4488-9F10-33686E82E657@incident.com> From: Art Botterell To: earlywarning@ietf.org, cap-list@incident.com In-Reply-To: <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 12 Jul 2009 12:23:12 -0700 References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> X-Mailer: Apple Mail (2.935.3) Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Sun, 12 Jul 2009 19:22:46 -0000 I'm wondering whether it might be simpler, at least in the near term, to let consumers subscribe to selected sources rather than to topical categories. That pushes the question of message authoritativeness / jurisdiction /credibility out of the CAP infrastructure and into the larger field of inter-agency and inter-jurisidictional coordination, where it more properly belongs. Taxonomies tend to be culturally loaded and can never be guaranteed to be complete. Thus there's a real risk of "categorical disconnects" leading to missed alerts either because of differing interpretations of categories or of unforeseen events that don't fit our preconceived categories. Maybe someday we'll have a reliable taxonomy of the unexpected, but right now a degree of deliberate imprecision seems to be the best we can do... and I sometimes wonder whether even that is more helpful than it is risky. - Art On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: > I should provide a bit more feedback about the background to my > question. > > If you only set the value in the category field for the purpose of > human > consumption then there is not really an interoperability issue. > > Now, with the work on http://tools.ietf.org/html/draft-rosen-sipping-cap-03 > we wanted to define an event package for SIP that allows you to > "subscribe" > to certain type of events: you might indicate something like > location and > the type of events you are interested in. > > Now, the semantic of the category field suddently matters. With the > individuals-to-citizen emergency services we tried to come up with a > description of the emergency services categories, see RFC 5031. > > Ciao > Hannes From hgs@cs.columbia.edu Sun Jul 12 13:17:09 2009 Return-Path: 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 86EEE28C194 for ; Sun, 12 Jul 2009 13:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 q4qS4H3AU66y for ; Sun, 12 Jul 2009 13:17:08 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 8E2CB28C103 for ; Sun, 12 Jul 2009 13:17:08 -0700 (PDT) Received: from new-host-2.home (pool-173-54-225-57.nwrknj.fios.verizon.net [173.54.225.57]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n6CKHbhQ004696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 12 Jul 2009 16:17:37 -0400 (EDT) Message-Id: <7B8483F8-3E5A-4156-BF5D-90A31611E4F4@cs.columbia.edu> From: Henning Schulzrinne To: Art Botterell In-Reply-To: <30076E62-60BC-4488-9F10-33686E82E657@incident.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 12 Jul 2009 16:17:37 -0400 References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> X-Mailer: Apple Mail (2.935.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.7 Cc: earlywarning@ietf.org, cap-list@incident.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Sun, 12 Jul 2009 20:17:09 -0000 I'm also not convinced that categories are all that useful, at least among different kinds emergencies. It seems a bit far-fetched to say "I want to know if there's a tsunami, but not a tornado or chemical leak, affecting my area". There are likely to be non-emergency categories, such as school closings or traffic alerts, that may have more limited appeal, but may use the same basic infrastructure. Henning On Jul 12, 2009, at 3:23 PM, Art Botterell wrote: > I'm wondering whether it might be simpler, at least in the near > term, to let consumers subscribe to selected sources rather than to > topical categories. That pushes the question of message > authoritativeness / jurisdiction /credibility out of the CAP > infrastructure and into the larger field of inter-agency and inter- > jurisidictional coordination, where it more properly belongs. > > Taxonomies tend to be culturally loaded and can never be guaranteed > to be complete. Thus there's a real risk of "categorical > disconnects" leading to missed alerts either because of differing > interpretations of categories or of unforeseen events that don't fit > our preconceived categories. Maybe someday we'll have a reliable > taxonomy of the unexpected, but right now a degree of deliberate > imprecision seems to be the best we can do... and I sometimes wonder > whether even that is more helpful than it is risky. > > - Art > > > On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: > >> I should provide a bit more feedback about the background to my >> question. >> >> If you only set the value in the category field for the purpose of >> human >> consumption then there is not really an interoperability issue. >> >> Now, with the work on http://tools.ietf.org/html/draft-rosen-sipping-cap-03 >> we wanted to define an event package for SIP that allows you to >> "subscribe" >> to certain type of events: you might indicate something like >> location and >> the type of events you are interested in. >> >> Now, the semantic of the category field suddently matters. With the >> individuals-to-citizen emergency services we tried to come up with a >> description of the emergency services categories, see RFC 5031. >> >> Ciao >> Hannes > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > From daylward@natstrat.com Sun Jul 12 13:41:18 2009 Return-Path: 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 49AA928C19D for ; Sun, 12 Jul 2009 13:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] 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 bwJ7ToIinKCR for ; Sun, 12 Jul 2009 13:41:17 -0700 (PDT) Received: from server514.appriver.com (server514a.exghost.com [72.32.253.68]) by core3.amsl.com (Postfix) with ESMTP id F3D5A28C1BE for ; Sun, 12 Jul 2009 13:41:16 -0700 (PDT) Received: by server514.appriver.com (CommuniGate Pro PIPE 5.2.14) with PIPE id 63623170; Sun, 12 Jul 2009 15:41:21 -0500 Received: from [72.32.253.140] (HELO FE01.exg4.exghost.com) by server514.appriver.com (CommuniGate Pro SMTP 5.2.14) with ESMTP id 63623167; Sun, 12 Jul 2009 15:41:15 -0500 Received: from FE01.exg4.exghost.com ([10.242.228.17]) by FE01.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 15:41:41 -0500 Received: from xppc1 ([67.192.118.158]) by FE01.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 15:41:41 -0500 From: "David Aylward \(Comcare\)" To: "'Art Botterell'" , , References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai><18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> Date: Sun, 12 Jul 2009 16:41:44 -0400 Message-ID: <34E56644D3334E8D876CD9368814657E@xppc1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoDJm4mfbl0gYbNSFi/rf7I6HPO7gACaiRA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <30076E62-60BC-4488-9F10-33686E82E657@incident.com> X-OriginalArrivalTime: 12 Jul 2009 20:41:41.0166 (UTC) FILETIME=[291F04E0:01CA0331] X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Primary: daylward@natstrat.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: daylward@natstrat.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.253.140 X-Note-Reverse-DNS: fe01.exg4.exghost.com X-Note-WHTLIST: daylward@natstrat.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 114 115 116 117 121 122 133 214 X-Note: Mail Class: ALLOWEDSENDER Cc: Timothy Grapes , ltincher@evotecinc.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Sun, 12 Jul 2009 20:41:18 -0000 Hannes: That is exactly what I was talking about, but CAP was not designed for = that. It is a=20 "broadcast to the world" standard. It is excellent for that purpose, = but not for the more refined purpose you are pursuing. The OASIS EDXL Distribution Element was designed for exactly that = purpose: machine to machine routing based on incident type, role and similar = factors, and primarily as Art suggests in the "wholesale", inter-organization = world. Organizations (and individuals connected to them) subscribe to "hear" = about incident types within certain geographies. =20 We have talked in the past, Hannes, about "core services", the purpose = of them is to provision queries such as you suggest, and govern rights to = send and receive such messages. =20 Lots of work has been done on these ideas outside of the = message-specific standards that they would enable. =A0 David K. Aylward, President COMCARE Emergency Response Technology Group 1351 Independence Court, SE Washington, DC 20003 202.255.3215 (mobile) 202.295.0136=A0(office) 202.521.4047 (fax) daylward@comcare.org =A0 This communication is intended for the use of the recipient to which it = is addressed, and may contain confidential, personal and/or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take = action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. -----Original Message----- From: cap-list-bounces@lists.incident.com [mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art Botterell Sent: Sunday, July 12, 2009 3:23 PM To: earlywarning@ietf.org; cap-list@incident.com Subject: Re: [CAP] Definition of Warning Categories I'm wondering whether it might be simpler, at least in the near term, =20 to let consumers subscribe to selected sources rather than to topical =20 categories. That pushes the question of message authoritativeness / =20 jurisdiction /credibility out of the CAP infrastructure and into the =20 larger field of inter-agency and inter-jurisidictional coordination, =20 where it more properly belongs. Taxonomies tend to be culturally loaded and can never be guaranteed to =20 be complete. Thus there's a real risk of "categorical disconnects" =20 leading to missed alerts either because of differing interpretations =20 of categories or of unforeseen events that don't fit our preconceived =20 categories. Maybe someday we'll have a reliable taxonomy of the =20 unexpected, but right now a degree of deliberate imprecision seems to =20 be the best we can do... and I sometimes wonder whether even that is =20 more helpful than it is risky. - Art On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: > I should provide a bit more feedback about the background to my =20 > question. > > If you only set the value in the category field for the purpose of =20 > human > consumption then there is not really an interoperability issue. > > Now, with the work on http://tools.ietf.org/html/draft-rosen-sipping-cap-03 > we wanted to define an event package for SIP that allows you to =20 > "subscribe" > to certain type of events: you might indicate something like =20 > location and > the type of events you are interested in. > > Now, the semantic of the category field suddently matters. With the > individuals-to-citizen emergency services we tried to come up with a > description of the emergency services categories, see RFC 5031. > > Ciao > Hannes _______________________________________________ This list is for public discussion of the Common Alerting Protocol. = This list is NOT part of the formal record of the OASIS Emergency Management = TC. Comments for the OASIS record should be posted using the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=3Demerge= ncy CAP-list mailing list CAP-list@lists.incident.com http://lists.incident.com/mailman/listinfo/cap-list This list is not for announcements, advertising or advocacy of any particular program or product other than the CAP itself. From daylward@natstrat.com Sun Jul 12 13:50:58 2009 Return-Path: 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 8D1E83A6C5B for ; Sun, 12 Jul 2009 13:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] 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 O0AztKZeKTYk for ; Sun, 12 Jul 2009 13:50:57 -0700 (PDT) Received: from server514.appriver.com (server514a.exghost.com [72.32.253.68]) by core3.amsl.com (Postfix) with ESMTP id EFEE73A6C71 for ; Sun, 12 Jul 2009 13:50:56 -0700 (PDT) Received: by server514.appriver.com (CommuniGate Pro PIPE 5.2.14) with PIPE id 63623556; Sun, 12 Jul 2009 15:51:01 -0500 Received: from [72.32.253.140] (HELO FE01.exg4.exghost.com) by server514.appriver.com (CommuniGate Pro SMTP 5.2.14) with ESMTP id 63623554; Sun, 12 Jul 2009 15:50:58 -0500 Received: from FE01.exg4.exghost.com ([10.242.228.17]) by FE01.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 15:51:24 -0500 Received: from xppc1 ([67.192.118.158]) by FE01.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 15:51:23 -0500 From: "David Aylward \(Comcare\)" To: "'Hannes Tschofenig'" , , References: <187701ca02df$a80ff0e0$501ca20a@nsnintra.net><8C3B4F90-C248-418C-9DC3-D9EFAFCCFF50@incident.com> <7B88AB507ED649F2B28CF1829AD3D122@xppc1> <18ef01ca0323$f75b60a0$501ca20a@nsnintra.net> Date: Sun, 12 Jul 2009 16:51:28 -0400 Message-ID: <74B7DB27F9264B95B3783D4D744AB0B1@xppc1> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoDCVgmerNFJDMgT0uSSmgCVS2P2AAAq0lgAAWvZxAAA9NqcA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <18ef01ca0323$f75b60a0$501ca20a@nsnintra.net> X-OriginalArrivalTime: 12 Jul 2009 20:51:23.0978 (UTC) FILETIME=[848112A0:01CA0332] X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Primary: daylward@natstrat.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: daylward@natstrat.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.253.140 X-Note-Reverse-DNS: fe01.exg4.exghost.com X-Note-WHTLIST: daylward@natstrat.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 114 115 116 117 121 122 133 214 X-Note: Mail Class: ALLOWEDSENDER Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Sun, 12 Jul 2009 20:50:58 -0000 Hannes: I am certainly not the world authority on this, but I was repeating the views of many who have spent time on this issue for many years. =20 You are describing a simplified version of what I suggested, just an entirely anarchic one. There is another reason that may not be so obvious to machine to machine people. There are semantic interoperability reasons for trying to = confine the choices. In the emergency response eco-system definitions of = incidents get used verbally and in writing, as well as machine to machine. =20 =A0 David K. Aylward, President COMCARE Emergency Response Technology Group 1351 Independence Court, SE Washington, DC 20003 202.255.3215 (mobile) 202.295.0136=A0(office) 202.521.4047 (fax) daylward@comcare.org =A0 This communication is intended for the use of the recipient to which it = is addressed, and may contain confidential, personal and/or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take = action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Sunday, July 12, 2009 3:07 PM To: David Aylward; cap-list@incident.com; earlywarning@ietf.org Subject: RE: [CAP] Definition of Warning Categories Hi David,=20 Is this really so difficult?=20 Here is what I would do: Setup a registry that associates labels with a description of what the label means. Someone maintains the registry (in = the IETF we use IANA). Someone adds a new term - fine. Deleting unused or revised terms is fine as well.=20 So, is there an initial list flying around somewhere already?=20 Ciao Hannes PS: What is the element in the CAP document used for today?=20 >-----Original Message----- >From: cap-list-bounces@lists.incident.com=20 >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of=20 >David Aylward (Comcare) >Sent: 12 July, 2009 19:55 >To: cap-list@incident.com; earlywarning@ietf.org >Subject: Re: [CAP] Definition of Warning Categories > >Hannes: > >As Art says, CAP's incident list is very general. To further=20 >Art's point, when it came to the development of what became=20 >the OASIS EDXL Distribution Element (DE), we faced the same=20 >issue as a primary purpose of the DE is routing messages by=20 >incident type. The CAP categories were far too broad for that. =20 > >So the draft requirements and specification for the DE=20 >developed by the cross emergency domain practitioner working=20 >group developed a detailed list of incident types for=20 >submission to the OASIS EMTC as part of its request for the=20 >development of that standard. > >The EMTC wisely rejected our suggestion, thinking that (1) the=20 >work to create a shared incident type taxomony should be done=20 >for the US and other countries, but hadn't been done yet, and=20 >(2) such lists of incident types would likely change more=20 >frequently than the standard. =20 > >So they adopted a flexible solution of "Managed Lists" for=20 >this and similar >list issues (e.g. roles). Under this approach values such as incident >names appear in the standard, along with the name of the=20 >managed list you are using. If there is only one Managed List=20 >for that topic in the world, great, but if there are several=20 >you can still communicate because you know which list is being used. =20 > >The absence of both initial managed lists and a repository for=20 >their locations is an identified gap that hopefully will be=20 >addressed soon. A number of us developed a project to do=20 >Managed Lists for incident names and roles, but other=20 >priorities have gotten in the way. > > > >=A0 >David K. Aylward, President >COMCARE Emergency Response Technology Group >1351 Independence Court, SE >Washington, DC 20003 >202.255.3215 (mobile) >202.295.0136=A0(office) >202.521.4047 (fax) >daylward@comcare.org >=A0 >This communication is intended for the use of the recipient to=20 >which it is addressed, and may contain confidential, personal=20 >and/or privileged information. Please contact us immediately=20 >if you are not the intended recipient of this communication,=20 >and do not copy, distribute, or take action relying on it. Any=20 >communication received in error, or subsequent reply, should=20 >be deleted or destroyed. > > >-----Original Message----- >From: cap-list-bounces@lists.incident.com >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art Botterell >Sent: Sunday, July 12, 2009 11:52 AM >To: cap-list@incident.com; earlywarning@ietf.org >Subject: Re: [CAP] Definition of Warning Categories > >On Jul 12, 2009, at 7/12/09 3:58 AM, Hannes Tschofenig wrote: >> I was wondering whether there is somewhere a more verbose / more=20 >> complete description of the semantic of the individual values. > >No, and that's deliberate. Considering the high levels of=20 >uncertainty that so often surround emergent events, the CAP=20 >designers (first in the CAP Working Group and later within=20 >OASIS) struggled to balance completeness against specificity. =20 >There was also a concern that we could get bogged down in=20 >trying to perfect the taxonomies and wind up with no standard at all. > >So the definitions were deliberately left somewhat open-ended=20 >and contextual... some would go so far as to say "vague" and=20 >I, for one, wouldn't argue. > >- Art > > > >_______________________________________________ >This list is for public discussion of the Common Alerting=20 >Protocol. This list is NOT part of the formal record of the=20 >OASIS Emergency Management TC. >Comments for the OASIS record should be posted using the form=20 >at=20 >http://www.oasis-open.org/committees/comments/form.php?wg_abbre >v=3Demergency >CAP-list mailing list >CAP-list@lists.incident.com >http://lists.incident.com/mailman/listinfo/cap-list > >This list is not for announcements, advertising or advocacy of=20 >any particular program or product other than the CAP itself. > > > >_______________________________________________ >This list is for public discussion of the Common Alerting=20 >Protocol. This list is NOT part of the formal record of the=20 >OASIS Emergency Management TC. Comments for the OASIS record=20 >should be posted using the form at=20 >http://www.oasis-open.org/committees/comments/form.php?wg_abbre >v=3Demergency >CAP-list mailing list >CAP-list@lists.incident.com >http://lists.incident.com/mailman/listinfo/cap-list > >This list is not for announcements, advertising or advocacy of=20 >any particular program or product other than the CAP itself. > From trutkowski@netmagic.com Sun Jul 12 13:56:04 2009 Return-Path: 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 DD04C3A6A84 for ; Sun, 12 Jul 2009 13:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Ra84k9LdjrQQ for ; Sun, 12 Jul 2009 13:56:04 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id 343F53A6807 for ; Sun, 12 Jul 2009 13:56:04 -0700 (PDT) Received: from [192.168.1.4] ([96.247.197.77]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KMO00GHCSTTHRU5@vms173005.mailsrvcs.net> for earlywarning@ietf.org; Sun, 12 Jul 2009 15:56:22 -0500 (CDT) Message-id: <4A5A4DF1.4070004@netmagic.com> Date: Sun, 12 Jul 2009 16:56:17 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-version: 1.0 To: Hannes Tschofenig References: <187701ca02df$a80ff0e0$501ca20a@nsnintra.net><8C3B4F90-C248-418C-9DC3-D9EFAFCCFF50@incident.com> <7B88AB507ED649F2B28CF1829AD3D122@xppc1> <18ef01ca0323$f75b60a0$501ca20a@nsnintra.net> In-reply-to: <18ef01ca0323$f75b60a0$501ca20a@nsnintra.net> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: earlywarning@ietf.org, "'David Aylward \(Comcare\)'" , cap-list@incident.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com 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: Sun, 12 Jul 2009 20:56:04 -0000 > > Here is what I would do: Setup a registry that associates labels with a > description of what the label means. Someone maintains the registry (in the > IETF we use IANA). Someone adds a new term - fine. Deleting unused or > revised terms is fine as well. > A step in that direction was taken at the joint WMO-ITU-T-OASIS workshop three weeks ago. Steps are being taken to set up an dedicated OID namespace for all manner of alert tags, especially for CAP. WMO is setting up a registry for some of the namespace. It's designed to be distributed and autonomous within an OID construct. --tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 From jmpolk@cisco.com Sun Jul 12 18:57:41 2009 Return-Path: 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 28F033A69AE for ; Sun, 12 Jul 2009 18:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 G-eMbYfeqBYl for ; Sun, 12 Jul 2009 18:57:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9A1FE3A68BD for ; Sun, 12 Jul 2009 18:57:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgGAEoxWkqrR7PD/2dsb2JhbACIPqpeh0dcMwmNWwUCgjcUgTyDcw X-IronPort-AV: E=Sophos;i="4.42,387,1243814400"; d="scan'208";a="212924638" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2009 01:58:09 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6D1w9q5007251; Sun, 12 Jul 2009 18:58:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6D1w9xT001731; Mon, 13 Jul 2009 01:58:09 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 18:58:09 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.85]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 18:58:09 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Jul 2009 20:58:07 -0500 To: "David Aylward \(Comcare\)" , "'Art Botterell'" , , From: "James M. Polk" In-Reply-To: <34E56644D3334E8D876CD9368814657E@xppc1> References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> <34E56644D3334E8D876CD9368814657E@xppc1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2009 01:58:09.0337 (UTC) FILETIME=[5EF3FA90:01CA035D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5711; t=1247450289; x=1248314289; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20[CAP]=20Definition=20o f=20Warning=20Categories |Sender:=20; bh=GMBeP4X7zeF7O9sEqpjtRIbehZyjmY7f8/JG375LmYE=; b=oWne5mK2lbDrkqaGLzHjEFnL1pKmB9vh5oMIyWpTjcSt5SCnKWhe8RSwxe 4DJsdK+sjdwYWETHowIjv4GVIntTTpTJL8kdy9C9HzbEOsdWtzA5mxNvKlOS II2BUM3nwg; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Timothy Grapes , ltincher@evotecinc.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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, 13 Jul 2009 01:57:41 -0000 All While I might agree with the reasons you have stated for the vagueness of categories, I have to look at Henning's example as a why I don't necessarily want "all warnings" from a geography. For example, he rightfully stated that just because I listed Tsunami warnings as something I care about, I should also care about the chemical leaks, or Tornados in my area too. And there's the rub - who decides what warnings I get? If I subscribe to (conceivably) all warnings in my area, do I really care when Dave has falen and can't reach his beer? Is that so monumental to anyone else? Local policy might dictate that yeah - everyone should do what it takes to get Dave his beer, but I don't necessarily need to care, therefore I will likely NOT want to get this messages. Too many warning messages will create a "cry wolf" mode of me eventually believing none of them are useful, regardless of what they say. I just won't reach for my (whatever) device if it's just out of my reach. Perhaps general categories ought to be looked at, because I think I can see exactly where Hannes is going, and I believe I'm in the same ballpark as him thinking this ought to be a little more specific for subscriptions. James At 03:41 PM 7/12/2009, David Aylward \(Comcare\) wrote: >Hannes: > >That is exactly what I was talking about, but CAP was not designed for that. >It is a >"broadcast to the world" standard. It is excellent for that purpose, but >not for the more refined purpose you are pursuing. > >The OASIS EDXL Distribution Element was designed for exactly that purpose: >machine to machine routing based on incident type, role and similar factors, >and primarily as Art suggests in the "wholesale", inter-organization world. > > >Organizations (and individuals connected to them) subscribe to "hear" about >incident types within certain geographies. > >We have talked in the past, Hannes, about "core services", the purpose of >them is to provision queries such as you suggest, and govern rights to send >and receive such messages. > >Lots of work has been done on these ideas outside of the message-specific >standards that they would enable. > > >David K. Aylward, President >COMCARE Emergency Response Technology Group >1351 Independence Court, SE >Washington, DC 20003 >202.255.3215 (mobile) >202.295.0136 (office) >202.521.4047 (fax) >daylward@comcare.org > >This communication is intended for the use of the recipient to which it is >addressed, and may contain confidential, personal and/or privileged >information. Please contact us immediately if you are not the intended >recipient of this communication, and do not copy, distribute, or take action >relying on it. Any communication received in error, or subsequent reply, >should be deleted or destroyed. > > >-----Original Message----- >From: cap-list-bounces@lists.incident.com >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art Botterell >Sent: Sunday, July 12, 2009 3:23 PM >To: earlywarning@ietf.org; cap-list@incident.com >Subject: Re: [CAP] Definition of Warning Categories > >I'm wondering whether it might be simpler, at least in the near term, >to let consumers subscribe to selected sources rather than to topical >categories. That pushes the question of message authoritativeness / >jurisdiction /credibility out of the CAP infrastructure and into the >larger field of inter-agency and inter-jurisidictional coordination, >where it more properly belongs. > >Taxonomies tend to be culturally loaded and can never be guaranteed to >be complete. Thus there's a real risk of "categorical disconnects" >leading to missed alerts either because of differing interpretations >of categories or of unforeseen events that don't fit our preconceived >categories. Maybe someday we'll have a reliable taxonomy of the >unexpected, but right now a degree of deliberate imprecision seems to >be the best we can do... and I sometimes wonder whether even that is >more helpful than it is risky. > >- Art > > >On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: > > > I should provide a bit more feedback about the background to my > > question. > > > > If you only set the value in the category field for the purpose of > > human > > consumption then there is not really an interoperability issue. > > > > Now, with the work on >http://tools.ietf.org/html/draft-rosen-sipping-cap-03 > > we wanted to define an event package for SIP that allows you to > > "subscribe" > > to certain type of events: you might indicate something like > > location and > > the type of events you are interested in. > > > > Now, the semantic of the category field suddently matters. With the > > individuals-to-citizen emergency services we tried to come up with a > > description of the emergency services categories, see RFC 5031. > > > > Ciao > > Hannes > >_______________________________________________ >This list is for public discussion of the Common Alerting Protocol. This >list is NOT part of the formal record of the OASIS Emergency Management TC. >Comments for the OASIS record should be posted using the form at >http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency >CAP-list mailing list >CAP-list@lists.incident.com >http://lists.incident.com/mailman/listinfo/cap-list > >This list is not for announcements, advertising or advocacy of any >particular program or product other than the CAP itself. > > > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From daylward@natstrat.com Mon Jul 13 10:26:38 2009 Return-Path: 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 0AF5D28C4F5 for ; Mon, 13 Jul 2009 10:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] 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 Pco0UkRIrqtW for ; Mon, 13 Jul 2009 10:26:33 -0700 (PDT) Received: from server514.appriver.com (server514d.exghost.com [72.32.253.69]) by core3.amsl.com (Postfix) with ESMTP id 365CB28C513 for ; Mon, 13 Jul 2009 10:24:38 -0700 (PDT) Received: by server514.appriver.com (CommuniGate Pro PIPE 5.2.14) with PIPE id 59809050; Mon, 13 Jul 2009 12:24:41 -0500 Received: from [72.32.253.141] (HELO FE02.exg4.exghost.com) by server514.appriver.com (CommuniGate Pro SMTP 5.2.14) with ESMTP id 59809027; Mon, 13 Jul 2009 12:24:38 -0500 Received: from FE02.exg4.exghost.com ([10.242.228.18]) by FE02.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 12:25:05 -0500 Received: from DavidPC ([67.192.118.156]) by FE02.exg4.exghost.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 12:25:05 -0500 From: "David Aylward \(Comcare\)" To: "'Rex Buddenberg'" , "Bob Robinson" References: <901124.96019.qm@web50909.mail.re2.yahoo.com> <1247504112.2203.67.camel@localhost.localdomain> In-Reply-To: <1247504112.2203.67.camel@localhost.localdomain> Date: Mon, 13 Jul 2009 13:25:04 -0400 Message-ID: <003601ca03de$dcc03ed0$9640bc70$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoD2pE40aXC+Va5TFSEsrB4fVCyAgAAsUow Content-Language: en-us X-OriginalArrivalTime: 13 Jul 2009 17:25:05.0456 (UTC) FILETIME=[DCBE4300:01CA03DE] X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Policy: GLOBAL - natstrat.com X-Policy: Too many policies to list X-Primary: daylward@natstrat.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: daylward@natstrat.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: UNITED STATES->PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.253.141 X-Note-Reverse-DNS: fe02.exg4.exghost.com X-Note-WHTLIST: daylward@natstrat.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 114 115 116 117 121 122 133 214 X-Note: Mail Class: ALLOWEDSENDER Cc: EM Groups , earlywarning@ietf.org, IAEM List , cap-list@incident.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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, 13 Jul 2009 17:26:38 -0000 Rex: Very insightful comments. Certainly you are pointing in the right direction. Many of us are working with alliances to make sure that safety uses are part of this stimulus. The law and regulations call for safety to be part of the mix. However, our enthusiasm should be tempered a bit by the emphasis the recently issued rules make for use of the funds. With a relatively small amount of money (a one time shot of $7 billion is small potatoes compared to something like $35-40 billion annually in industry capex), many of us had hoped that the rules would leverage this one time investment by focusing on building integrated demand, i.e. get safety, healthcare, etc sharing information and thus using broad band more and more. However, the predominant designated use for the first tranche of the stimulus funds (only 1/3 of the NTIA amount) is digging trenches for fiber into rural America. Nothing inherently wrong with that if someone has a future business model to support the capex. But the problem in the safety/healthcare eco-system is not primarily access to IP communications trunks, but application layer capability and interoperability issues. Part of the first part of the stimulus funds are devoted to "Innovative and sustainable uses of broadband". Hopefully more will be in the future. -----Original Message----- From: cap-list-bounces@lists.incident.com [mailto:cap-list-bounces@lists.incident.com] On Behalf Of Rex Buddenberg Sent: Monday, July 13, 2009 12:55 PM To: Bob Robinson Cc: IAEM List; EM Groups; earlywarning@ietf.org; cap-list@incident.com; Art Botterell Subject: Re: [CAP] Definition of Warning Categories Bob, You point into a very interesting parallel development out there in the world. In the stimulus bill last spring was $7.2B in grant money that went to USDA ('broadband' and 'reach to rural') and NTIA in Commerce ('broadband' and 'reach to underserved'). The FCC was also charged with drafting a 'national broadband plan'. FCC published a Notice of Inquiry, for which the comment period just closed last week. About the first comment they sought was a definition of 'broadband'. (For paper coming from inside the beltway, this NOI is pretty good stuff, IMHO). Whatever your definition of broadband, you can look behind it and see 'extension of the internet'. And you should recognize that extension of internet to rural and extension of internet to emergency services has a whole lot of overlap. Just to complete the federal nethead - bellhead list of players, DHS and DoJ are still in circuit-switch. ... and didn't get this batch of grant money. What you ought to get out of this is is that - emergency services vehicles will soon be routinely on the internet. - the citizenry that emergency services exists to serve will increasingly be on the internet. This observation is progressively true in any event -- the netheads always win -- but the stimulus subsidies are probably going to be a substantial accelerant.... Santa Ana winds behind a California wildfire. On Sun, 2009-07-12 at 17:50 -0700, Bob Robinson wrote: > Art, > > Very good analysis. In fact I think the question of user (consumer) disconnect can be put to the broader field of general emergency management communications and in fact it can be a very important part of any attempt to build "standards" that are to be applied across groups/agencies/etc. involved in emergency management. But what the heck, that's just my nickels worth based on 25+ years of EM experience. > > Bob Robinson > > --- On Sun, 7/12/09, Art Botterell wrote: > > > From: Art Botterell > > Subject: Re: [CAP] Definition of Warning Categories > > To: earlywarning@ietf.org, cap-list@incident.com > > Date: Sunday, July 12, 2009, 2:23 PM > > > I'm wondering whether it might be > > simpler, at least in the near term, to let consumers > > subscribe to selected sources rather than to topical > > categories. That pushes the question of message > > authoritativeness / jurisdiction /credibility out of > > the CAP infrastructure and into the larger field of > > inter-agency and inter-jurisidictional coordination, where > > it more properly belongs. > > > > Taxonomies tend to be culturally loaded and can never be > > guaranteed to be complete. Thus there's a real risk of > > "categorical disconnects" leading to missed alerts either > > because of differing interpretations of categories or of > > unforeseen events that don't fit our preconceived > > categories. Maybe someday we'll have a reliable > > taxonomy of the unexpected, but right now a degree of > > deliberate imprecision seems to be the best we can do... and > > I sometimes wonder whether even that is more helpful than it > > is risky. > > > > - Art > > > > > > On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig > > wrote: > > > > > I should provide a bit more feedback about the > > background to my question. > > > > > > If you only set the value in the category field for > > the purpose of human > > > consumption then there is not really an > > interoperability issue. > > > > > > Now, with the work on http://tools.ietf.org/html/draft-rosen-sipping-cap-03 > > > we wanted to define an event package for SIP that > > allows you to "subscribe" > > > to certain type of events: you might indicate > > something like location and > > > the type of events you are interested in. > > > > > > Now, the semantic of the category field suddently > > matters. With the > > > individuals-to-citizen emergency services we tried to > > come up with a > > > description of the emergency services categories, see > > RFC 5031. > > > > > > Ciao > > > Hannes > > > > > _______________________________________________ > This list is for public discussion of the Common Alerting Protocol. This list is NOT part of the formal record of the OASIS Emergency Management TC. Comments for the OASIS record should be posted using the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency > CAP-list mailing list > CAP-list@lists.incident.com > http://lists.incident.com/mailman/listinfo/cap-list > > This list is not for announcements, advertising or advocacy of any particular program or product other than the CAP itself. -- Rex Buddenberg Naval Postgraduate School Code IS/Bu Monterey, Ca 93943 831/656-3576 _______________________________________________ This list is for public discussion of the Common Alerting Protocol. This list is NOT part of the formal record of the OASIS Emergency Management TC. Comments for the OASIS record should be posted using the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency CAP-list mailing list CAP-list@lists.incident.com http://lists.incident.com/mailman/listinfo/cap-list This list is not for announcements, advertising or advocacy of any particular program or product other than the CAP itself. From Hannes.Tschofenig@gmx.net Mon Jul 13 13:27:07 2009 Return-Path: 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 6D3313A683E for ; Mon, 13 Jul 2009 13:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599] 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 kxlPFAr4884e for ; Mon, 13 Jul 2009 13:27:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id B9A4F3A67F3 for ; Mon, 13 Jul 2009 13:27:05 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2009 20:27:22 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp007) with SMTP; 13 Jul 2009 22:27:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/lXPNvEfDlCIMvWmhspQGFWhWEAO5MUyRghPtMdv 0U0EmJPCIo/4cq From: "Hannes Tschofenig" To: Date: Mon, 13 Jul 2009 23:29:38 +0300 Message-ID: <075f01ca03f8$a7c7eab0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoD+KS55Wg66zDsSGuL+vHhTEGsAQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.7 Subject: [earlywarning] Requirements, Terminology and Framework for Exigent Communications X-BeenThere: earlywarning@ietf.org 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, 13 Jul 2009 20:27:07 -0000 Hi all, I updated the terminology, architecture and requirements draft but had to go for a manual submission (i.e., it takes some time for the draft announcement to arrive). In the meanwhile please look at: http://www.tschofenig.priv.at/svn/draft-norreys-ecrit-authority2individuals/ draft-norreys-ecrit-authority2individuals-requirements-03.txt or http://tinyurl.com/lvem9g The document changed quite a bit based on the feedback from Carl and Art. To avoid too much problems with terminology that has a lot of history we picked up the terminology from the email community (based on a recent Email architecture draft by Dave Crocker). I am personally quite happy with the result (even though the document still requires more work). Ciao Hannes From drage@alcatel-lucent.com Wed Jul 15 06:10:24 2009 Return-Path: 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 4F85B3A69CF for ; Wed, 15 Jul 2009 06:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_36=0.6, MANGLED_EMRG=2.3, RCVD_IN_DNSWL_MED=-4] 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 uqlQB0epKBpQ for ; Wed, 15 Jul 2009 06:10:22 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 59C963A69B3 for ; Wed, 15 Jul 2009 06:10:22 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6FD9BWj027290 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 15 Jul 2009 15:09:54 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 15 Jul 2009 15:09:22 +0200 From: "DRAGE, Keith (Keith)" To: "earlywarning@ietf.org" Date: Wed, 15 Jul 2009 15:09:19 +0200 Thread-Topic: [earlywarning] [CAP] Definition of Warning Categories Thread-Index: AcoDXWRGX51QjTguSAGj9+AjsimLYAB7Jjjw Message-ID: References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> <34E56644D3334E8D876CD9368814657E@xppc1> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Wed, 15 Jul 2009 13:10:24 -0000 Firstly, I am not sure the identification of the types of warnings I wish t= o subscribe to, and the nature of the warning, are necessarily one and the = same thing, yet that seems to be assumed by the drafts.=20 Secondly, surely we should be seeking some alignment of warning types betwe= en the different delivery mechanisms. I note that we have lists in http://t= ools.ietf.org/html/draft-rosen-sipping-cap-04 and http://tools.ietf.org/htm= l/draft-rosen-ecrit-lost-early-warning-01 that are aligned with each other,= but bear no relationship with those being defined in other bodies. For example 3GPP TS 22.268 defines the umbrella for warnings provided by th= e cell broadcast service=20 http://www.3gpp.org/ftp/Specs/html-info/22268.htm This defines a structure that incorporates at least ETWS for the far east, = and CMAS for north america. Europe is still working on a coordinated set of= requirements. and you will find the message identifiers for these two in 3GPP TS 23.041 http://www.3gpp.org/ftp/Specs/html-info/23041.htm Including recent expansions which have not yet appeared in the published do= cument these come down to: ETWS CBS Message Identifier for earthquake warning message. ETWS CBS Message Identifier for tsunami warning message. ETWS CBS Message Identifier for earthquake and tsunami combined warning mes= sage. ETWS CBS Message Identifier for test message. ETWS CBS Message Identifier for messages related to other emergency types. ETWS CBS Message Identifier for future extension. CMAS CBS Message Identifier for Presidential Level Alerts. CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Ur= gency of Immediate, and Certainty of Observed. CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Ur= gency of Immediate, and Certainty of Likely. CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Ur= gency of Expected, and Certainty of Observed. CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Ur= gency of Expected, and Certainty of Likely. CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urge= ncy of Immediate, and Certainty of Observed. CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urge= ncy of Immediate, and Certainty of Likely. CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urge= ncy of Expected, and Certainty of Observed. CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urge= ncy of Expected, and Certainty of Likely. CMAS CBS Message Identifier for Child Abduction Emergency (or Amber Alert). CMAS CBS Message Identifier for the Required Monthly Test. CMAS CBS Message Identifier for CMAS Exercise. CMAS CBS Message Identifier for operator defined use. CMAS CBS Message Identifier for future extension. I don't see any alignment between these lists and those in the internet-dra= fts, yet surely you will have the same content providers generating these m= essages, and the same receivers receiving these messages. Note that the ETWS set are already in deployment (they formed part of 3GPP = release 8). I believe the CMAS ones are based on input discussed first in A= TIS. ITU-T SG2 also believe they are playing in this space. regards Keith > -----Original Message----- > From: earlywarning-bounces@ietf.org=20 > [mailto:earlywarning-bounces@ietf.org] On Behalf Of James M. Polk > Sent: Monday, July 13, 2009 2:58 AM > To: David Aylward (Comcare); 'Art Botterell';=20 > earlywarning@ietf.org; cap-list@incident.com > Cc: Timothy Grapes; ltincher@evotecinc.com > Subject: Re: [earlywarning] [CAP] Definition of Warning Categories >=20 > All >=20 > While I might agree with the reasons you have stated for the=20 > vagueness of categories, I have to look at Henning's example=20 > as a why I don't necessarily want "all warnings" from a=20 > geography. For example, he rightfully stated that just=20 > because I listed Tsunami warnings as something I care about,=20 > I should also care about the chemical leaks, or Tornados in=20 > my area too. >=20 > And there's the rub - who decides what warnings I get? >=20 > If I subscribe to (conceivably) all warnings in my area, do I=20 > really care when Dave has falen and can't reach his beer? Is=20 > that so monumental to anyone else? Local policy might=20 > dictate that yeah - everyone should do what it takes to get=20 > Dave his beer, but I don't necessarily need to care,=20 > therefore I will likely NOT want to get this messages. >=20 > Too many warning messages will create a "cry wolf" mode of me=20 > eventually believing none of them are useful, regardless of=20 > what they say. I just won't reach for my (whatever) device if=20 > it's just out of my reach. >=20 > Perhaps general categories ought to be looked at, because I=20 > think I can see exactly where Hannes is going, and I believe=20 > I'm in the same ballpark as him thinking this ought to be a=20 > little more specific for subscriptions. >=20 > James >=20 > At 03:41 PM 7/12/2009, David Aylward \(Comcare\) wrote: > >Hannes: > > > >That is exactly what I was talking about, but CAP was not=20 > designed for that. > >It is a > >"broadcast to the world" standard. It is excellent for that=20 > purpose,=20 > >but not for the more refined purpose you are pursuing. > > > >The OASIS EDXL Distribution Element was designed for exactly=20 > that purpose: > >machine to machine routing based on incident type, role and similar=20 > >factors, and primarily as Art suggests in the "wholesale",=20 > inter-organization world. > > > > > >Organizations (and individuals connected to them) subscribe=20 > to "hear"=20 > >about incident types within certain geographies. > > > >We have talked in the past, Hannes, about "core services",=20 > the purpose=20 > >of them is to provision queries such as you suggest, and=20 > govern rights=20 > >to send and receive such messages. > > > >Lots of work has been done on these ideas outside of the=20 > >message-specific standards that they would enable. > > > > > >David K. Aylward, President > >COMCARE Emergency Response Technology Group > >1351 Independence Court, SE > >Washington, DC 20003 > >202.255.3215 (mobile) > >202.295.0136 (office) > >202.521.4047 (fax) > >daylward@comcare.org > > > >This communication is intended for the use of the recipient=20 > to which it=20 > >is addressed, and may contain confidential, personal and/or=20 > privileged=20 > >information. Please contact us immediately if you are not=20 > the intended=20 > >recipient of this communication, and do not copy,=20 > distribute, or take=20 > >action relying on it. Any communication received in error, or=20 > >subsequent reply, should be deleted or destroyed. > > > > > >-----Original Message----- > >From: cap-list-bounces@lists.incident.com > >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of=20 > Art Botterell > >Sent: Sunday, July 12, 2009 3:23 PM > >To: earlywarning@ietf.org; cap-list@incident.com > >Subject: Re: [CAP] Definition of Warning Categories > > > >I'm wondering whether it might be simpler, at least in the=20 > near term,=20 > >to let consumers subscribe to selected sources rather than=20 > to topical=20 > >categories. That pushes the question of message authoritativeness /=20 > >jurisdiction /credibility out of the CAP infrastructure and=20 > into the=20 > >larger field of inter-agency and inter-jurisidictional coordination,=20 > >where it more properly belongs. > > > >Taxonomies tend to be culturally loaded and can never be=20 > guaranteed to=20 > >be complete. Thus there's a real risk of "categorical disconnects" > >leading to missed alerts either because of differing=20 > interpretations of=20 > >categories or of unforeseen events that don't fit our preconceived=20 > >categories. Maybe someday we'll have a reliable taxonomy of the=20 > >unexpected, but right now a degree of deliberate imprecision=20 > seems to=20 > >be the best we can do... and I sometimes wonder whether even that is=20 > >more helpful than it is risky. > > > >- Art > > > > > >On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: > > > > > I should provide a bit more feedback about the background to my=20 > > > question. > > > > > > If you only set the value in the category field for the=20 > purpose of=20 > > > human consumption then there is not really an interoperability=20 > > > issue. > > > > > > Now, with the work on > >http://tools.ietf.org/html/draft-rosen-sipping-cap-03 > > > we wanted to define an event package for SIP that allows you to=20 > > > "subscribe" > > > to certain type of events: you might indicate something like=20 > > > location and the type of events you are interested in. > > > > > > Now, the semantic of the category field suddently=20 > matters. With the=20 > > > individuals-to-citizen emergency services we tried to=20 > come up with a=20 > > > description of the emergency services categories, see RFC 5031. > > > > > > Ciao > > > Hannes > > > >_______________________________________________ > >This list is for public discussion of the Common Alerting Protocol. =20 > >This list is NOT part of the formal record of the OASIS=20 > Emergency Management TC. > >Comments for the OASIS record should be posted using the form at=20 > >http://www.oasis-open.org/committees/comments/form.php?wg_abb > rev=3Demerge > >ncy > >CAP-list mailing list > >CAP-list@lists.incident.com > >http://lists.incident.com/mailman/listinfo/cap-list > > > >This list is not for announcements, advertising or advocacy of any=20 > >particular program or product other than the CAP itself. > > > > > > > >_______________________________________________ > >earlywarning mailing list > >earlywarning@ietf.org > >https://www.ietf.org/mailman/listinfo/earlywarning >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > = From trutkowski@netmagic.com Wed Jul 15 06:23:31 2009 Return-Path: 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 123903A6D03 for ; Wed, 15 Jul 2009 06:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 XjZYK8RnhLmE for ; Wed, 15 Jul 2009 06:23:30 -0700 (PDT) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by core3.amsl.com (Postfix) with ESMTP id 5CFBE3A68EA for ; Wed, 15 Jul 2009 06:23:30 -0700 (PDT) Received: from [192.168.1.4] ([96.247.197.77]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KMT005PGRTQCAQ5@vms173005.mailsrvcs.net> for earlywarning@ietf.org; Wed, 15 Jul 2009 08:22:43 -0500 (CDT) Message-id: <4A5DD81E.7090803@netmagic.com> Date: Wed, 15 Jul 2009 09:22:38 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-version: 1.0 To: "DRAGE, Keith (Keith)" References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> <34E56644D3334E8D876CD9368814657E@xppc1> In-reply-to: Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: "earlywarning@ietf.org" Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com 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: Wed, 15 Jul 2009 13:23:31 -0000 DRAGE, Keith (Keith) wrote: > Firstly, I am not sure the identification of the types of warnings I wish to subscribe to, and the nature of the warning, are necessarily one and the same thing, yet that seems to be assumed by the drafts. > These are all subjects that were discussed at some length at the recent Geneva workshop on alert identifiers. It's also apparent that there are many active user communities worldwide who have evolved their implementations, secretariats, and administrative processes. The WMO has its own ecosystem based on international agreements and has served as a point of convergence - especially with Eliot Christian's presence. Somehow the dialogue on this list seems disconnected from this larger active global ecosystem. It's not clear what you do about this, but the "they should come here" approach will not work. --tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 From Hannes.Tschofenig@gmx.net Wed Jul 15 06:26:22 2009 Return-Path: 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 46B5128C0FC for ; Wed, 15 Jul 2009 06:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, MANGLED_EMRG=2.3] 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 6p68fvJX1t3d for ; Wed, 15 Jul 2009 06:26:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7573B28C0F3 for ; Wed, 15 Jul 2009 06:26:19 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2009 13:18:59 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp066) with SMTP; 15 Jul 2009 15:18:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18p9dglPo4pwYEJIOs2koGHmZDharwj9i2LhsyKWQ en44bJzgfFbIdJ From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai><18ee01ca0322$b7a97d30$501ca20a@nsnintra.net><30076E62-60BC-4488-9F10-33686E82E657@incident.com><34E56644D3334E8D876CD9368814657E@xppc1> Date: Wed, 15 Jul 2009 16:21:17 +0300 Message-ID: <020e01ca054f$23a96620$1116a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: thread-index: AcoDXWRGX51QjTguSAGj9+AjsimLYAB7JjjwAAEXBhA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Wed, 15 Jul 2009 13:26:22 -0000 Hi Keith, >Firstly, I am not sure the identification of the types of >warnings I wish to subscribe to, and the nature of the >warning, are necessarily one and the same thing, yet that >seems to be assumed by the drafts. If you want to subscribe to certain alerts then there better should be a relationship otherwise the point of including any information about desired alerts is a bit mood. Henning was a bit doubtful of the benefit of subscribing to separate categories of alerts. Someone else suggested that this should be left to a manual procedure of picking the right server that has a certain type of alert messages to distribute, e.g., weather alerts. > >Secondly, surely we should be seeking some alignment of >warning types between the different delivery mechanisms. This is not the feedback I got from others. >I >note that we have lists in >http://tools.ietf.org/html/draft-rosen-sipping-cap-04 and >http://tools.ietf.org/html/draft-rosen-ecrit-lost-early-warning >-01 that are aligned with each other, but bear no relationship >with those being defined in other bodies. Well. I took these terms from the categories in the CAP specification. > >For example 3GPP TS 22.268 defines the umbrella for warnings >provided by the cell broadcast service > >http://www.3gpp.org/ftp/Specs/html-info/22268.htm > >This defines a structure that incorporates at least ETWS for >the far east, and CMAS for north america. Europe is still >working on a coordinated set of requirements. > >and you will find the message identifiers for these two in >3GPP TS 23.041 > >http://www.3gpp.org/ftp/Specs/html-info/23041.htm > >Including recent expansions which have not yet appeared in the >published document these come down to: > >ETWS CBS Message Identifier for earthquake warning message. >ETWS CBS Message Identifier for tsunami warning message. >ETWS CBS Message Identifier for earthquake and tsunami >combined warning message. >ETWS CBS Message Identifier for test message. >ETWS CBS Message Identifier for messages related to other >emergency types. >ETWS CBS Message Identifier for future extension. Thanks for these pointers. Interesting to see that there are different categories being used compared to the CAP work. Ciao Hannes >regards > >Keith > > > >> -----Original Message----- >> From: earlywarning-bounces@ietf.org >> [mailto:earlywarning-bounces@ietf.org] On Behalf Of James M. Polk >> Sent: Monday, July 13, 2009 2:58 AM >> To: David Aylward (Comcare); 'Art Botterell'; earlywarning@ietf.org; >> cap-list@incident.com >> Cc: Timothy Grapes; ltincher@evotecinc.com >> Subject: Re: [earlywarning] [CAP] Definition of Warning Categories >> >> All >> >> While I might agree with the reasons you have stated for the >vagueness >> of categories, I have to look at Henning's example as a why I don't >> necessarily want "all warnings" from a geography. For example, he >> rightfully stated that just because I listed Tsunami warnings as >> something I care about, I should also care about the chemical leaks, >> or Tornados in my area too. >> >> And there's the rub - who decides what warnings I get? >> >> If I subscribe to (conceivably) all warnings in my area, do I really >> care when Dave has falen and can't reach his beer? Is that so >> monumental to anyone else? Local policy might dictate that yeah - >> everyone should do what it takes to get Dave his beer, but I don't >> necessarily need to care, therefore I will likely NOT want >to get this >> messages. >> >> Too many warning messages will create a "cry wolf" mode of me >> eventually believing none of them are useful, regardless of >what they >> say. I just won't reach for my (whatever) device if it's just out of >> my reach. >> >> Perhaps general categories ought to be looked at, because I think I >> can see exactly where Hannes is going, and I believe I'm in the same >> ballpark as him thinking this ought to be a little more >specific for >> subscriptions. >> >> James >> >> At 03:41 PM 7/12/2009, David Aylward \(Comcare\) wrote: >> >Hannes: >> > >> >That is exactly what I was talking about, but CAP was not >> designed for that. >> >It is a >> >"broadcast to the world" standard. It is excellent for that >> purpose, >> >but not for the more refined purpose you are pursuing. >> > >> >The OASIS EDXL Distribution Element was designed for exactly >> that purpose: >> >machine to machine routing based on incident type, role and similar >> >factors, and primarily as Art suggests in the "wholesale", >> inter-organization world. >> > >> > >> >Organizations (and individuals connected to them) subscribe >> to "hear" >> >about incident types within certain geographies. >> > >> >We have talked in the past, Hannes, about "core services", >> the purpose >> >of them is to provision queries such as you suggest, and >> govern rights >> >to send and receive such messages. >> > >> >Lots of work has been done on these ideas outside of the >> >message-specific standards that they would enable. >> > >> > >> >David K. Aylward, President >> >COMCARE Emergency Response Technology Group >> >1351 Independence Court, SE >> >Washington, DC 20003 >> >202.255.3215 (mobile) >> >202.295.0136 (office) >> >202.521.4047 (fax) >> >daylward@comcare.org >> > >> >This communication is intended for the use of the recipient >> to which it >> >is addressed, and may contain confidential, personal and/or >> privileged >> >information. Please contact us immediately if you are not >> the intended >> >recipient of this communication, and do not copy, >> distribute, or take >> >action relying on it. Any communication received in error, or >> >subsequent reply, should be deleted or destroyed. >> > >> > >> >-----Original Message----- >> >From: cap-list-bounces@lists.incident.com >> >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of >> Art Botterell >> >Sent: Sunday, July 12, 2009 3:23 PM >> >To: earlywarning@ietf.org; cap-list@incident.com >> >Subject: Re: [CAP] Definition of Warning Categories >> > >> >I'm wondering whether it might be simpler, at least in the >> near term, >> >to let consumers subscribe to selected sources rather than >> to topical >> >categories. That pushes the question of message >authoritativeness / >> >jurisdiction /credibility out of the CAP infrastructure and >> into the >> >larger field of inter-agency and inter-jurisidictional >coordination, >> >where it more properly belongs. >> > >> >Taxonomies tend to be culturally loaded and can never be >> guaranteed to >> >be complete. Thus there's a real risk of "categorical disconnects" >> >leading to missed alerts either because of differing >> interpretations of >> >categories or of unforeseen events that don't fit our preconceived >> >categories. Maybe someday we'll have a reliable taxonomy of the >> >unexpected, but right now a degree of deliberate imprecision >> seems to >> >be the best we can do... and I sometimes wonder whether >even that is >> >more helpful than it is risky. >> > >> >- Art >> > >> > >> >On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: >> > >> > > I should provide a bit more feedback about the background to my >> > > question. >> > > >> > > If you only set the value in the category field for the >> purpose of >> > > human consumption then there is not really an interoperability >> > > issue. >> > > >> > > Now, with the work on >> >http://tools.ietf.org/html/draft-rosen-sipping-cap-03 >> > > we wanted to define an event package for SIP that allows you to >> > > "subscribe" >> > > to certain type of events: you might indicate something like >> > > location and the type of events you are interested in. >> > > >> > > Now, the semantic of the category field suddently >> matters. With the >> > > individuals-to-citizen emergency services we tried to >> come up with a >> > > description of the emergency services categories, see RFC 5031. >> > > >> > > Ciao >> > > Hannes >> > >> >_______________________________________________ >> >This list is for public discussion of the Common Alerting >Protocol. >> >This list is NOT part of the formal record of the OASIS >> Emergency Management TC. >> >Comments for the OASIS record should be posted using the form at >> >http://www.oasis-open.org/committees/comments/form.php?wg_abb >> rev=emerge >> >ncy >> >CAP-list mailing list >> >CAP-list@lists.incident.com >> >http://lists.incident.com/mailman/listinfo/cap-list >> > >> >This list is not for announcements, advertising or advocacy of any >> >particular program or product other than the CAP itself. >> > >> > >> > >> >_______________________________________________ >> >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 mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning > From trutkowski@netmagic.com Wed Jul 15 07:18:40 2009 Return-Path: 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 D07D93A6BDB for ; Wed, 15 Jul 2009 07:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 YUmAu31BFU+m for ; Wed, 15 Jul 2009 07:18:39 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id 90EBF3A6BA5 for ; Wed, 15 Jul 2009 07:18:39 -0700 (PDT) Received: from [192.168.1.4] ([96.247.197.77]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KMT000FOUE32WCC@vms173017.mailsrvcs.net> for earlywarning@ietf.org; Wed, 15 Jul 2009 09:18:04 -0500 (CDT) Message-id: <4A5DE51B.4070706@netmagic.com> Date: Wed, 15 Jul 2009 10:18:03 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-version: 1.0 To: Hannes Tschofenig References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai><18ee01ca0322$b7a97d30$501ca20a@nsnintra.net><30076E62-60BC-4488-9F10-33686E82E657@incident.com><34E56644D3334E8D876CD9368814657E@xppc1> <4A5DD81E.7090803@netmagic.com> <021501ca0551$bca043b0$1116a20a@nsnintra.net> In-reply-to: <021501ca0551$bca043b0$1116a20a@nsnintra.net> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: earlywarning@ietf.org Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com 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: Wed, 15 Jul 2009 14:18:40 -0000 Hi Hannes, > Are there meeting minutes available from the workshop? > All docs are at The output is Doc. 4.1 > What specific part do you think is disconnected from the "global > ecosystem"? User communities and implementors. These are active, globally distributed communities that seem to have their own networks of communication and collaboration. Many are not in the "West." Even in West, they are stovepiped in different agencies and disciplines. I appreciate the challenge, as my Q.4/17 standards group in ITU-T is responsible for the international version of the CAP Standard, X.1303, including the ASN.1 translation, and it's constantly a "wack a mole" effort of keeping track of who is doing what. > As we have learned already from the previous discussion about the emergency > services categories there is no single overall community to talk to, as this > community seems to be quite fragmented. From my citizen-to-authority > emergency services experience I can tell you that you cannot create such a > "single community" regardless of how much work you spend. > Yes and no. The authority-to-citizen realm has been around for many decades, and threads through countless generic and specialized local, national, regional, and international bodies/agencies and activities. You can't ignore them. On the other hand, you don't want to spend all of your efforts playing the liaison game and getting no work done. Eliot Christian has spent the past several years facilitating US national and now global coordination among these communities - especially with respect to CAP use. He works full time doing this in Geneva for one of the core international organizations in this arena - WMO. As he indicated: > WMO recently compiled responses to a questionnaire concerning > official alerting authorities. This should give us a database of > alerting authorities of the 132 responding nations. A WMO office > in China (Hong Kong Observatory) is putting that online. I imagine > we can use this as a seed for rationalizing among the various > official directories that exist at other international venues. Seems like a good path forward. --tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 From Hannes.Tschofenig@gmx.net Wed Jul 15 07:26:43 2009 Return-Path: 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 2DA5D3A6A30 for ; Wed, 15 Jul 2009 07:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599] 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 afkwX2Kepajy for ; Wed, 15 Jul 2009 07:26:41 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C2F663A68B5 for ; Wed, 15 Jul 2009 07:26:40 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2009 13:37:34 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp067) with SMTP; 15 Jul 2009 15:37:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/O0EFRlXbOZMcnGivrkKG9Gz+RwKDMlxK3I0taYq eSAkroqvN2TjTu From: "Hannes Tschofenig" To: , "'DRAGE, Keith \(Keith\)'" References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai><18ee01ca0322$b7a97d30$501ca20a@nsnintra.net><30076E62-60BC-4488-9F10-33686E82E657@incident.com><34E56644D3334E8D876CD9368814657E@xppc1> <4A5DD81E.7090803@netmagic.com> Date: Wed, 15 Jul 2009 16:39:52 +0300 Message-ID: <021501ca0551$bca043b0$1116a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A5DD81E.7090803@netmagic.com> thread-index: AcoFT4cPFoFACjuASxKP7PzA4unhcwAARG9Q X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 Cc: earlywarning@ietf.org Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Wed, 15 Jul 2009 14:26:43 -0000 Hi Tony, >DRAGE, Keith (Keith) wrote: >> Firstly, I am not sure the identification of the types of >warnings I wish to subscribe to, and the nature of the >warning, are necessarily one and the same thing, yet that >seems to be assumed by the drafts. >> >These are all subjects that were discussed at some length at >the recent Geneva workshop on alert identifiers. Are there meeting minutes available from the workshop? > It's also >apparent that there are many active user communities worldwide >who have evolved their implementations, secretariats, and >administrative processes. The WMO has its own ecosystem based >on international agreements and has served as a point of >convergence - especially with Eliot Christian's presence. > >Somehow the dialogue on this list seems disconnected from this >larger active global ecosystem. It's not clear what you do >about this, but the "they should come here" approach will not work. What specific part do you think is disconnected from the "global ecosystem"? As we have learned already from the previous discussion about the emergency services categories there is no single overall community to talk to, as this community seems to be quite fragmented. From my citizen-to-authority emergency services experience I can tell you that you cannot create such a "single community" regardless of how much work you spend. Ciao Hannes From creed@opengeospatial.org Wed Jul 15 09:45:09 2009 Return-Path: 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 09A103A6F30 for ; Wed, 15 Jul 2009 09:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] 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 rUWgUewJLr-m for ; Wed, 15 Jul 2009 09:45:07 -0700 (PDT) Received: from mail.opengeospatial.org (mail.opengeospatial.org [66.244.86.40]) by core3.amsl.com (Postfix) with ESMTP id 5D80C3A6F2D for ; Wed, 15 Jul 2009 09:45:07 -0700 (PDT) Received: from mail.opengeospatial.org (localhost [127.0.0.1]) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3) with ESMTP id n6FGiO3J030330; Wed, 15 Jul 2009 12:44:24 -0400 Received: from 75.71.192.203 (SquirrelMail authenticated user creed) by mail.opengeospatial.org with HTTP; Wed, 15 Jul 2009 12:44:24 -0400 (EDT) Message-ID: <52348.75.71.192.203.1247676264.squirrel@mail.opengeospatial.org> In-Reply-To: <020e01ca054f$23a96620$1116a20a@nsnintra.net> References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai><18ee01ca0322$b7a97d30$501ca20a@nsnintra.net><30076E62-60BC-4488-9F10-33686E82E657@incident.com><34E56644D3334E8D876CD9368814657E@xppc1> <020e01ca054f$23a96620$1116a20a@nsnintra.net> Date: Wed, 15 Jul 2009 12:44:24 -0400 (EDT) From: creed@opengeospatial.org To: "Hannes Tschofenig" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV 0.92.1/9569/Wed Jul 15 01:55:56 2009 on mail.opengeospatial.org X-Virus-Status: Clean Cc: earlywarning@ietf.org Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Wed, 15 Jul 2009 16:45:09 -0000 CAP was originally developed based primarily on US requirements and as such may not reflect non-US regional considerations, policies, etc. This may be why groups outside the US are developing profiles with extensions - which is not necessarily good for interoperability. That said, there is some coordination of these activities occurring in OASIS as part of the CAP profiling and CAP 2.0 activity. I am sure Art can add more of a perspective on this. Another touch point is that the European community is defining and prototyping an event based alerting architecture that is coordinated with the INSPIRE (pan-European spatial data infrastructure) activity. The architecture is payload agnostic and can support any number of alerting payload encodings (CAP, GeoRSS, Atom based, other). Carl > Hi Keith, > >>Firstly, I am not sure the identification of the types of >>warnings I wish to subscribe to, and the nature of the >>warning, are necessarily one and the same thing, yet that >>seems to be assumed by the drafts. > > If you want to subscribe to certain alerts then there better should be a > relationship otherwise the point of including any information about > desired > alerts is a bit mood. > > Henning was a bit doubtful of the benefit of subscribing to separate > categories of alerts. Someone else suggested that this should be left to a > manual procedure of picking the right server that has a certain type of > alert messages to distribute, e.g., weather alerts. > >> >>Secondly, surely we should be seeking some alignment of >>warning types between the different delivery mechanisms. > > This is not the feedback I got from others. > >>I >>note that we have lists in >>http://tools.ietf.org/html/draft-rosen-sipping-cap-04 and >>http://tools.ietf.org/html/draft-rosen-ecrit-lost-early-warning >>-01 that are aligned with each other, but bear no relationship >>with those being defined in other bodies. > > Well. I took these terms from the categories in the CAP specification. > > >> >>For example 3GPP TS 22.268 defines the umbrella for warnings >>provided by the cell broadcast service >> >>http://www.3gpp.org/ftp/Specs/html-info/22268.htm >> >>This defines a structure that incorporates at least ETWS for >>the far east, and CMAS for north america. Europe is still >>working on a coordinated set of requirements. >> >>and you will find the message identifiers for these two in >>3GPP TS 23.041 >> >>http://www.3gpp.org/ftp/Specs/html-info/23041.htm >> >>Including recent expansions which have not yet appeared in the >>published document these come down to: >> >>ETWS CBS Message Identifier for earthquake warning message. >>ETWS CBS Message Identifier for tsunami warning message. >>ETWS CBS Message Identifier for earthquake and tsunami >>combined warning message. >>ETWS CBS Message Identifier for test message. >>ETWS CBS Message Identifier for messages related to other >>emergency types. >>ETWS CBS Message Identifier for future extension. > > Thanks for these pointers. Interesting to see that there are different > categories being used compared to the CAP work. > > > Ciao > Hannes > >>regards >> >>Keith >> >> >> >>> -----Original Message----- >>> From: earlywarning-bounces@ietf.org >>> [mailto:earlywarning-bounces@ietf.org] On Behalf Of James M. Polk >>> Sent: Monday, July 13, 2009 2:58 AM >>> To: David Aylward (Comcare); 'Art Botterell'; earlywarning@ietf.org; >>> cap-list@incident.com >>> Cc: Timothy Grapes; ltincher@evotecinc.com >>> Subject: Re: [earlywarning] [CAP] Definition of Warning Categories >>> >>> All >>> >>> While I might agree with the reasons you have stated for the >>vagueness >>> of categories, I have to look at Henning's example as a why I don't >>> necessarily want "all warnings" from a geography. For example, he >>> rightfully stated that just because I listed Tsunami warnings as >>> something I care about, I should also care about the chemical leaks, >>> or Tornados in my area too. >>> >>> And there's the rub - who decides what warnings I get? >>> >>> If I subscribe to (conceivably) all warnings in my area, do I really >>> care when Dave has falen and can't reach his beer? Is that so >>> monumental to anyone else? Local policy might dictate that yeah - >>> everyone should do what it takes to get Dave his beer, but I don't >>> necessarily need to care, therefore I will likely NOT want >>to get this >>> messages. >>> >>> Too many warning messages will create a "cry wolf" mode of me >>> eventually believing none of them are useful, regardless of >>what they >>> say. I just won't reach for my (whatever) device if it's just out of >>> my reach. >>> >>> Perhaps general categories ought to be looked at, because I think I >>> can see exactly where Hannes is going, and I believe I'm in the same >>> ballpark as him thinking this ought to be a little more >>specific for >>> subscriptions. >>> >>> James >>> >>> At 03:41 PM 7/12/2009, David Aylward \(Comcare\) wrote: >>> >Hannes: >>> > >>> >That is exactly what I was talking about, but CAP was not >>> designed for that. >>> >It is a >>> >"broadcast to the world" standard. It is excellent for that >>> purpose, >>> >but not for the more refined purpose you are pursuing. >>> > >>> >The OASIS EDXL Distribution Element was designed for exactly >>> that purpose: >>> >machine to machine routing based on incident type, role and similar >>> >factors, and primarily as Art suggests in the "wholesale", >>> inter-organization world. >>> > >>> > >>> >Organizations (and individuals connected to them) subscribe >>> to "hear" >>> >about incident types within certain geographies. >>> > >>> >We have talked in the past, Hannes, about "core services", >>> the purpose >>> >of them is to provision queries such as you suggest, and >>> govern rights >>> >to send and receive such messages. >>> > >>> >Lots of work has been done on these ideas outside of the >>> >message-specific standards that they would enable. >>> > >>> > >>> >David K. Aylward, President >>> >COMCARE Emergency Response Technology Group >>> >1351 Independence Court, SE >>> >Washington, DC 20003 >>> >202.255.3215 (mobile) >>> >202.295.0136 (office) >>> >202.521.4047 (fax) >>> >daylward@comcare.org >>> > >>> >This communication is intended for the use of the recipient >>> to which it >>> >is addressed, and may contain confidential, personal and/or >>> privileged >>> >information. Please contact us immediately if you are not >>> the intended >>> >recipient of this communication, and do not copy, >>> distribute, or take >>> >action relying on it. Any communication received in error, or >>> >subsequent reply, should be deleted or destroyed. >>> > >>> > >>> >-----Original Message----- >>> >From: cap-list-bounces@lists.incident.com >>> >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of >>> Art Botterell >>> >Sent: Sunday, July 12, 2009 3:23 PM >>> >To: earlywarning@ietf.org; cap-list@incident.com >>> >Subject: Re: [CAP] Definition of Warning Categories >>> > >>> >I'm wondering whether it might be simpler, at least in the >>> near term, >>> >to let consumers subscribe to selected sources rather than >>> to topical >>> >categories. That pushes the question of message >>authoritativeness / >>> >jurisdiction /credibility out of the CAP infrastructure and >>> into the >>> >larger field of inter-agency and inter-jurisidictional >>coordination, >>> >where it more properly belongs. >>> > >>> >Taxonomies tend to be culturally loaded and can never be >>> guaranteed to >>> >be complete. Thus there's a real risk of "categorical disconnects" >>> >leading to missed alerts either because of differing >>> interpretations of >>> >categories or of unforeseen events that don't fit our preconceived >>> >categories. Maybe someday we'll have a reliable taxonomy of the >>> >unexpected, but right now a degree of deliberate imprecision >>> seems to >>> >be the best we can do... and I sometimes wonder whether >>even that is >>> >more helpful than it is risky. >>> > >>> >- Art >>> > >>> > >>> >On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: >>> > >>> > > I should provide a bit more feedback about the background to my >>> > > question. >>> > > >>> > > If you only set the value in the category field for the >>> purpose of >>> > > human consumption then there is not really an interoperability >>> > > issue. >>> > > >>> > > Now, with the work on >>> >http://tools.ietf.org/html/draft-rosen-sipping-cap-03 >>> > > we wanted to define an event package for SIP that allows you to >>> > > "subscribe" >>> > > to certain type of events: you might indicate something like >>> > > location and the type of events you are interested in. >>> > > >>> > > Now, the semantic of the category field suddently >>> matters. With the >>> > > individuals-to-citizen emergency services we tried to >>> come up with a >>> > > description of the emergency services categories, see RFC 5031. >>> > > >>> > > Ciao >>> > > Hannes >>> > >>> >_______________________________________________ >>> >This list is for public discussion of the Common Alerting >>Protocol. >>> >This list is NOT part of the formal record of the OASIS >>> Emergency Management TC. >>> >Comments for the OASIS record should be posted using the form at >>> >http://www.oasis-open.org/committees/comments/form.php?wg_abb >>> rev=emerge >>> >ncy >>> >CAP-list mailing list >>> >CAP-list@lists.incident.com >>> >http://lists.incident.com/mailman/listinfo/cap-list >>> > >>> >This list is not for announcements, advertising or advocacy of any >>> >particular program or product other than the CAP itself. >>> > >>> > >>> > >>> >_______________________________________________ >>> >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 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 > From artbotterell@gmail.com Wed Jul 15 10:02:19 2009 Return-Path: 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 DC60B28C24A for ; Wed, 15 Jul 2009 10:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 A17Ni9M2xPJp for ; Wed, 15 Jul 2009 10:02:19 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id D6AA628C10D for ; Wed, 15 Jul 2009 10:02:18 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1750820anc.4 for ; Wed, 15 Jul 2009 10:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=TqG12c3eUjTXr0YmOo26fHClAYbvEzj+3gv84s3B8dw=; b=HAx5DLd5P1TNqPanqrIqNUzK1/G1CwuBGrPWFyiHwCxLtRoy2WkTsQcMN+VlL8FR6i 77YqQVc1zPPd900+UclI+4TEp8pT9FrRFeCmmuxHcyiBefFpL/GibaR3qUCpmIpDXuGr 86mGD8844Y8uuzRuwv9EesX7AqjGl5MMqpAE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=f5RIc9tpmgye1VSIGPNFPkM8IJmbQDilL6/id6VPqvPIMW68E+4WSwtN3dXYohRMmj Wqm44TYsBJH8ln0rWn73wWSan8hHm8oCqi9yQ2E0/ARkf7f0Z/HDIia+9tzpbCgnw4vB q/2NBoR0aIbVmxJQL/3039MdJyMgoXsx3cco8= MIME-Version: 1.0 Received: by 10.100.144.14 with SMTP id r14mr10526342and.65.1247677339105; Wed, 15 Jul 2009 10:02:19 -0700 (PDT) In-Reply-To: <021501ca0551$bca043b0$1116a20a@nsnintra.net> References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> <34E56644D3334E8D876CD9368814657E@xppc1> <4A5DD81E.7090803@netmagic.com> <021501ca0551$bca043b0$1116a20a@nsnintra.net> Date: Wed, 15 Jul 2009 10:02:19 -0700 Message-ID: <2e53e6590907151002k4b12905di6e29ac0bbda8721c@mail.gmail.com> From: Art Botterell To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=0016e644cc6e977a04046ec18422 Cc: earlywarning@ietf.org Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: acb@incident.com 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: Wed, 15 Jul 2009 17:16:11 -0000 --0016e644cc6e977a04046ec18422 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Jul 15, 2009 at 6:39 AM, Hannes Tschofenig < Hannes.Tschofenig@gmx.net> wrote: > From my citizen-to-authority emergency services experience I can tell you > that you cannot create such a > "single community" regardless of how much work you spend. I think that's right. Emergency services don't function as a separate community, but rather as a facet of the larger communities and cultures they serve. Notions like "authority" and even "emergency" are constructed very differently in different places and in different contexts. (For an example of how subtle and controversial even seemingly simple notions of emergency response can be, see my blog entry on standards of practice for public warning at ... I'm presenting it at the Natural Hazards Workshop in Boulder Colorado this week. Note also that "public warning" in the tactical sense and "early warning" of significant events are themselves quite different topics.) What we're really talking about here seems to be how to apply SIP to urgent one-to-many notifications. Maybe if it were explicit that narrower, more technical goal would be more tractable. - Art --0016e644cc6e977a04046ec18422 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 15, 2009 at 6:39 AM, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>= ; wrote:
=A0From my citizen-to-authority emergency services experience I can tell yo= u that you cannot create such a
"single community" regardless of how much work you spend.
I think that's right.=A0 Emergency services don't fu= nction as a separate community, but rather as a facet of the larger communi= ties and cultures they serve.=A0 Notions like "authority" and eve= n "emergency" are constructed very differently in different place= s and in different contexts.

(For an example of how subtle and controversial even seemingly simple n= otions of emergency response can be, see my blog entry on standards of prac= tice for public warning at <htt= p://www.incident.com/blog>... I'm presenting it at the Natural H= azards Workshop in Boulder Colorado this week.=A0 Note also that "publ= ic warning" in the tactical sense and "early warning" of sig= nificant events are themselves quite different topics.)

What we're really talking about here seems to be how to apply SIP t= o urgent one-to-many notifications.=A0 Maybe if it were explicit that narro= wer, more technical goal would be more tractable.

- Art

--0016e644cc6e977a04046ec18422-- From artbotterell@gmail.com Wed Jul 15 10:14:35 2009 Return-Path: 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 518E03A6CB8 for ; Wed, 15 Jul 2009 10:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 JnZ7tkb-21Ui for ; Wed, 15 Jul 2009 10:14:34 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id 2CDA53A6995 for ; Wed, 15 Jul 2009 10:14:07 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1754121anc.4 for ; Wed, 15 Jul 2009 10:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HBamGH7Z5NbG56qqlmyzgTakotrqy3AnB4DXOzjd5k0=; b=ku23rp+jfcpRqx7NW8pxJW5K9d6YhuWgttmIo50ZCNF5QGBzpju9yGzMxiF5D8NUiu p05Wn4rMOzRNPTzeYjsiTpGt9nOmCxjO4CIJFc5jmlhxeJMqnCF0Dpu/3lQ8S44+lxxo KJu5MhybDp83WD92NvR7hL3tIBVqZglyTxICc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=Rj6djYH0vAmldtYgdtQjsjuUVaDv6gm+cmzJWEvuS59HpGuB86H/7CpiO5rdKKzsDP QbUv15PoPPmOYxT2FwQgilkxR75m872yo+0fQVwZ6s/O1mMXfq19nTpmW+uyPQzMOleF LnqCtEoy2YGtft7md6CWCKmuXRHjgyEIw0xKc= MIME-Version: 1.0 Received: by 10.100.151.1 with SMTP id y1mr10460504and.119.1247677986855; Wed, 15 Jul 2009 10:13:06 -0700 (PDT) In-Reply-To: <52348.75.71.192.203.1247676264.squirrel@mail.opengeospatial.org> References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> <34E56644D3334E8D876CD9368814657E@xppc1> <020e01ca054f$23a96620$1116a20a@nsnintra.net> <52348.75.71.192.203.1247676264.squirrel@mail.opengeospatial.org> Date: Wed, 15 Jul 2009 10:13:06 -0700 Message-ID: <2e53e6590907151013n9af4e69m484d2326a0cf76b3@mail.gmail.com> From: Art Botterell To: creed@opengeospatial.org Content-Type: multipart/alternative; boundary=001636164b37335a4f046ec1abf9 Cc: Hannes Tschofenig , earlywarning@ietf.org Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: acb@incident.com 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: Wed, 15 Jul 2009 17:19:44 -0000 --001636164b37335a4f046ec1abf9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Jul 15, 2009 at 9:44 AM, wrote: > CAP was originally developed based primarily on US requirements and as > such may not reflect non-US regional considerations, policies, etc. Um... I'm not sure that's entirely correct. The basis of the CAP design was social science research on warning message effectiveness, and both that body of research and the membership of the original CAP Working Group were quite international. It's true that a lot of the application of CAP has taken place in the U.S., and that's a constant concern. However, we've managed to keep CAP international enough that the ITU was able to endorse it (as recommendation x.1303). Profiles, as long at they're truly profiles (which is to say, strict subsets of the CAP specification) enable different communities to define local usages without breaking basic compatibility with other CAP implementations. Again, it's been a struggle sometimes to prevent profiles from becoming localized extensions of the standard, which wouldn't be interoperable, but I think we've done reasonably well so far. I'd also suggest that it may be confusing to talk about CAP in the same breath with GeoRSS or Atom. CAP is a content structure, while RSS and Atom are indexing schemes that themselves refer to other content, including sometimes CAP. - Art --001636164b37335a4f046ec1abf9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 15, 2009 at 9:44 AM, <creed@opengeospatial.org> wrote:
=
CAP was originally developed based primarily on US requirements and as
such may not reflect non-US regional considerations, policies, etc.

Um... I'm not sure that's entirely correct.=A0 The b= asis of the CAP design was social science research on warning message effec= tiveness, and both that body of research and the membership of the original= CAP Working Group were quite international.

It's true that a lot of the application of CAP has taken place in t= he U.S., and that's a constant concern.=A0 However, we've managed t= o keep CAP international enough that the ITU was able to endorse it (as rec= ommendation x.1303).

Profiles, as long at they're truly profiles (which is to say, stric= t subsets of the CAP specification) enable different communities to define = local usages without breaking basic compatibility with other CAP implementa= tions.=A0 Again, it's been a struggle sometimes to prevent profiles fro= m becoming localized extensions of the standard, which wouldn't be inte= roperable, but I think we've done reasonably well so far.

I'd also suggest that it may be confusing to talk about CAP in the = same breath with GeoRSS or Atom.=A0 CAP is a content structure, while RSS a= nd Atom are indexing schemes that themselves refer to other content, includ= ing sometimes CAP.
=A0
- Art

--001636164b37335a4f046ec1abf9-- From Hannes.Tschofenig@gmx.net Wed Jul 15 10:25:41 2009 Return-Path: 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 73E8F3A6BF8 for ; Wed, 15 Jul 2009 10:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] 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 HTr5fU--5P1Q for ; Wed, 15 Jul 2009 10:25:39 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7EE873A6BBB for ; Wed, 15 Jul 2009 10:25:38 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2009 17:24:43 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp037) with SMTP; 15 Jul 2009 19:24:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Vqix5tubVCsKL4BQeaBdAZ12EOo0/yM91VuSWxK H7oBonVzR3F5eO From: "Hannes Tschofenig" To: References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai><18ee01ca0322$b7a97d30$501ca20a@nsnintra.net><30076E62-60BC-4488-9F10-33686E82E657@incident.com><34E56644D3334E8D876CD9368814657E@xppc1><020e01ca054f$23a96620$1116a20a@nsnintra.net> <52348.75.71.192.203.1247676264.squirrel@mail.opengeospatial.org> Date: Wed, 15 Jul 2009 20:27:02 +0300 Message-ID: <022f01ca0571$78164850$1116a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <52348.75.71.192.203.1247676264.squirrel@mail.opengeospatial.org> thread-index: AcoFa7IIMsQpGf4mRtikVIa82qVO8wABaqcQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 Cc: earlywarning@ietf.org Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Wed, 15 Jul 2009 17:25:41 -0000 Hey Carl, >Another touch point is that the European community is defining >and prototyping an event based alerting architecture that is >coordinated with the INSPIRE (pan-European spatial data >infrastructure) activity. The architecture is payload agnostic >and can support any number of alerting payload encodings (CAP, >GeoRSS, Atom based, other). I like the idea of carrying generic alerting payloads. This is probably something we should pick up. Ciao Hannes > >Carl > > > > > Hi Keith, >> >>>Firstly, I am not sure the identification of the types of warnings I >>>wish to subscribe to, and the nature of the warning, are necessarily >>>one and the same thing, yet that seems to be assumed by the drafts. >> >> If you want to subscribe to certain alerts then there better >should be >> a relationship otherwise the point of including any >information about >> desired alerts is a bit mood. >> >> Henning was a bit doubtful of the benefit of subscribing to separate >> categories of alerts. Someone else suggested that this >should be left >> to a manual procedure of picking the right server that has a certain >> type of alert messages to distribute, e.g., weather alerts. >> >>> >>>Secondly, surely we should be seeking some alignment of >warning types >>>between the different delivery mechanisms. >> >> This is not the feedback I got from others. >> >>>I >>>note that we have lists in >>>http://tools.ietf.org/html/draft-rosen-sipping-cap-04 and >>>http://tools.ietf.org/html/draft-rosen-ecrit-lost-early-warning >>>-01 that are aligned with each other, but bear no relationship with >>>those being defined in other bodies. >> >> Well. I took these terms from the categories in the CAP >specification. >> >> >>> >>>For example 3GPP TS 22.268 defines the umbrella for warnings >provided >>>by the cell broadcast service >>> >>>http://www.3gpp.org/ftp/Specs/html-info/22268.htm >>> >>>This defines a structure that incorporates at least ETWS for the far >>>east, and CMAS for north america. Europe is still working on a >>>coordinated set of requirements. >>> >>>and you will find the message identifiers for these two in 3GPP TS >>>23.041 >>> >>>http://www.3gpp.org/ftp/Specs/html-info/23041.htm >>> >>>Including recent expansions which have not yet appeared in the >>>published document these come down to: >>> >>>ETWS CBS Message Identifier for earthquake warning message. >>>ETWS CBS Message Identifier for tsunami warning message. >>>ETWS CBS Message Identifier for earthquake and tsunami combined >>>warning message. >>>ETWS CBS Message Identifier for test message. >>>ETWS CBS Message Identifier for messages related to other emergency >>>types. >>>ETWS CBS Message Identifier for future extension. >> >> Thanks for these pointers. Interesting to see that there are >different >> categories being used compared to the CAP work. >> >> >> Ciao >> Hannes >> >>>regards >>> >>>Keith >>> >>> >>> >>>> -----Original Message----- >>>> From: earlywarning-bounces@ietf.org >>>> [mailto:earlywarning-bounces@ietf.org] On Behalf Of James M. Polk >>>> Sent: Monday, July 13, 2009 2:58 AM >>>> To: David Aylward (Comcare); 'Art Botterell'; >earlywarning@ietf.org; >>>> cap-list@incident.com >>>> Cc: Timothy Grapes; ltincher@evotecinc.com >>>> Subject: Re: [earlywarning] [CAP] Definition of Warning Categories >>>> >>>> All >>>> >>>> While I might agree with the reasons you have stated for the >>>vagueness >>>> of categories, I have to look at Henning's example as a >why I don't >>>> necessarily want "all warnings" from a geography. For example, he >>>> rightfully stated that just because I listed Tsunami warnings as >>>> something I care about, I should also care about the >chemical leaks, >>>> or Tornados in my area too. >>>> >>>> And there's the rub - who decides what warnings I get? >>>> >>>> If I subscribe to (conceivably) all warnings in my area, >do I really >>>> care when Dave has falen and can't reach his beer? Is that so >>>> monumental to anyone else? Local policy might dictate that yeah - >>>> everyone should do what it takes to get Dave his beer, but I don't >>>> necessarily need to care, therefore I will likely NOT want >>>to get this >>>> messages. >>>> >>>> Too many warning messages will create a "cry wolf" mode of me >>>> eventually believing none of them are useful, regardless of >>>what they >>>> say. I just won't reach for my (whatever) device if it's >just out of >>>> my reach. >>>> >>>> Perhaps general categories ought to be looked at, because >I think I >>>> can see exactly where Hannes is going, and I believe I'm >in the same >>>> ballpark as him thinking this ought to be a little more >>>specific for >>>> subscriptions. >>>> >>>> James >>>> >>>> At 03:41 PM 7/12/2009, David Aylward \(Comcare\) wrote: >>>> >Hannes: >>>> > >>>> >That is exactly what I was talking about, but CAP was not >>>> designed for that. >>>> >It is a >>>> >"broadcast to the world" standard. It is excellent for that >>>> purpose, >>>> >but not for the more refined purpose you are pursuing. >>>> > >>>> >The OASIS EDXL Distribution Element was designed for exactly >>>> that purpose: >>>> >machine to machine routing based on incident type, role >and similar >>>> >factors, and primarily as Art suggests in the "wholesale", >>>> inter-organization world. >>>> > >>>> > >>>> >Organizations (and individuals connected to them) subscribe >>>> to "hear" >>>> >about incident types within certain geographies. >>>> > >>>> >We have talked in the past, Hannes, about "core services", >>>> the purpose >>>> >of them is to provision queries such as you suggest, and >>>> govern rights >>>> >to send and receive such messages. >>>> > >>>> >Lots of work has been done on these ideas outside of the >>>> >message-specific standards that they would enable. >>>> > >>>> > >>>> >David K. Aylward, President >>>> >COMCARE Emergency Response Technology Group >>>> >1351 Independence Court, SE >>>> >Washington, DC 20003 >>>> >202.255.3215 (mobile) >>>> >202.295.0136 (office) >>>> >202.521.4047 (fax) >>>> >daylward@comcare.org >>>> > >>>> >This communication is intended for the use of the recipient >>>> to which it >>>> >is addressed, and may contain confidential, personal and/or >>>> privileged >>>> >information. Please contact us immediately if you are not >>>> the intended >>>> >recipient of this communication, and do not copy, >>>> distribute, or take >>>> >action relying on it. Any communication received in error, or >>>> >subsequent reply, should be deleted or destroyed. >>>> > >>>> > >>>> >-----Original Message----- >>>> >From: cap-list-bounces@lists.incident.com >>>> >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of >>>> Art Botterell >>>> >Sent: Sunday, July 12, 2009 3:23 PM >>>> >To: earlywarning@ietf.org; cap-list@incident.com >>>> >Subject: Re: [CAP] Definition of Warning Categories >>>> > >>>> >I'm wondering whether it might be simpler, at least in the >>>> near term, >>>> >to let consumers subscribe to selected sources rather than >>>> to topical >>>> >categories. That pushes the question of message >>>authoritativeness / >>>> >jurisdiction /credibility out of the CAP infrastructure and >>>> into the >>>> >larger field of inter-agency and inter-jurisidictional >>>coordination, >>>> >where it more properly belongs. >>>> > >>>> >Taxonomies tend to be culturally loaded and can never be >>>> guaranteed to >>>> >be complete. Thus there's a real risk of "categorical >disconnects" >>>> >leading to missed alerts either because of differing >>>> interpretations of >>>> >categories or of unforeseen events that don't fit our >preconceived >>>> >categories. Maybe someday we'll have a reliable taxonomy of the >>>> >unexpected, but right now a degree of deliberate imprecision >>>> seems to >>>> >be the best we can do... and I sometimes wonder whether >>>even that is >>>> >more helpful than it is risky. >>>> > >>>> >- Art >>>> > >>>> > >>>> >On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: >>>> > >>>> > > I should provide a bit more feedback about the >background to my >>>> > > question. >>>> > > >>>> > > If you only set the value in the category field for the >>>> purpose of >>>> > > human consumption then there is not really an interoperability >>>> > > issue. >>>> > > >>>> > > Now, with the work on >>>> >http://tools.ietf.org/html/draft-rosen-sipping-cap-03 >>>> > > we wanted to define an event package for SIP that >allows you to >>>> > > "subscribe" >>>> > > to certain type of events: you might indicate something like >>>> > > location and the type of events you are interested in. >>>> > > >>>> > > Now, the semantic of the category field suddently >>>> matters. With the >>>> > > individuals-to-citizen emergency services we tried to >>>> come up with a >>>> > > description of the emergency services categories, see RFC 5031. >>>> > > >>>> > > Ciao >>>> > > Hannes >>>> > >>>> >_______________________________________________ >>>> >This list is for public discussion of the Common Alerting >>>Protocol. >>>> >This list is NOT part of the formal record of the OASIS >>>> Emergency Management TC. >>>> >Comments for the OASIS record should be posted using the form at >>>> >http://www.oasis-open.org/committees/comments/form.php?wg_abb >>>> rev=emerge >>>> >ncy >>>> >CAP-list mailing list >>>> >CAP-list@lists.incident.com >>>> >http://lists.incident.com/mailman/listinfo/cap-list >>>> > >>>> >This list is not for announcements, advertising or >advocacy of any >>>> >particular program or product other than the CAP itself. >>>> > >>>> > >>>> > >>>> >_______________________________________________ >>>> >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 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 mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning > From Hannes.Tschofenig@gmx.net Wed Jul 15 12:10:54 2009 Return-Path: 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 495823A69CD for ; Wed, 15 Jul 2009 12:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] 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 CqShV2zXYaw6 for ; Wed, 15 Jul 2009 12:10:52 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5A8AF3A6A56 for ; Wed, 15 Jul 2009 12:10:52 -0700 (PDT) Received: (qmail invoked by alias); 15 Jul 2009 17:22:49 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp026) with SMTP; 15 Jul 2009 19:22:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/XBjtUHN7X0p/SzY004SlaWL05XSnNRYNMbdIulN FnBiUkkT0MwrKN From: "Hannes Tschofenig" To: References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> <34E56644D3334E8D876CD9368814657E@xppc1> <4A5DD81E.7090803@netmagic.com> <021501ca0551$bca043b0$1116a20a@nsnintra.net> <2e53e6590907151002k4b12905di6e29ac0bbda8721c@mail.gmail.com> Date: Wed, 15 Jul 2009 20:25:07 +0300 Message-ID: <022b01ca0571$33de2400$1116a20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <2e53e6590907151002k4b12905di6e29ac0bbda8721c@mail.gmail.com> thread-index: AcoFbgMZx0rAXyhDSIeq94f6rP5cPgAAeEow X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63 Cc: earlywarning@ietf.org Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Wed, 15 Jul 2009 19:10:54 -0000 Hi Art, ~snip~ # What we're really talking about here seems to be how to apply SIP to urgent one-to-many notifications. Maybe if it were explicit that narrower, more technical goal would be more tractable. For me the scope of the work is quite narrow. I re-wrote the requirements, terminology and framework document http://tools.ietf.org/id/draft-norreys-ecrit-authority2individuals-requireme nts-03.txt based also on your feedback to re-scope the work. Then, there is the SIP CAP document http://tools.ietf.org/html/draft-rosen-sipping-cap-04 (It needs to get re-written a bit to better incorporate the new terminology. Maybe requesting specific warning categories is a bad idea and needs to be deleted.) There is also a document http://tools.ietf.org/id/draft-rosen-ecrit-lost-early-warning-01.txt that may be needed to discover servers dynamically. But this is clearly more into the future. Looking at the XMPP work http://xmpp.org/extensions/xep-0127.html we could get away with only a single document, namely the SIP CAP stuff. I would scope the initial work in that way. Ciao Hannes - Art From tgrapes@evotecinc.com Mon Jul 13 07:57:05 2009 Return-Path: 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 679103A689B for ; Mon, 13 Jul 2009 07:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 1IzOGVe3t+N0 for ; Mon, 13 Jul 2009 07:57:04 -0700 (PDT) Received: from outbound-mail-101.bluehost.com (outbound-mail-101.bluehost.com [69.89.22.11]) by core3.amsl.com (Postfix) with SMTP id 3E5EB3A6DE8 for ; Mon, 13 Jul 2009 07:57:04 -0700 (PDT) Received: (qmail 9405 invoked by uid 0); 13 Jul 2009 14:57:05 -0000 Received: from unknown (HELO host123.hostmonster.com) (74.220.207.123) by outboundproxy3.bluehost.com with SMTP; 13 Jul 2009 14:57:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=evotecinc.com; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=MsT05vN4lkRm+T8t369/QyX4ll0AE/8m72GoJW2v/amfz8kINMj2y+Rr7ZnPtbFOy+bqO/qnE6CzIzhX2VZrBgpKO/F7p0e+bnNjgOOUJ60BPSGb+ilolpZUY2gFQ7/p; Received: from pool-173-66-212-229.washdc.fios.verizon.net ([173.66.212.229] helo=PC276735688210) by host123.hostmonster.com with esmtpa (Exim 4.69) (envelope-from ) id 1MQMxk-00056d-5V; Mon, 13 Jul 2009 08:57:04 -0600 From: "Timothy Grapes" To: "'James M. Polk'" , "'David Aylward \(Comcare\)'" , "'Art Botterell'" , , References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> <34E56644D3334E8D876CD9368814657E@xppc1> In-Reply-To: Date: Mon, 13 Jul 2009 10:57:03 -0400 Message-ID: <049d01ca03ca$2fa79770$8ef6c650$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoDXWCKGHMVjL0jTPaEupn80frZxwAbHTJw Content-Language: en-us X-Identified-User: {575:host123.hostmonster.com:evoteci1:evotecinc.com} {sentby:smtp auth 173.66.212.229 authed with tgrapes@evotecinc.com} X-Mailman-Approved-At: Fri, 17 Jul 2009 03:28:42 -0700 Cc: ltincher@evotecinc.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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, 13 Jul 2009 15:09:16 -0000 While valid points have been made on both sides, I do suggest that the EDXL-DE be reviewed against your requirements to determine how it may address your needs. Without opening the hood further, it appears it = could do the trick in concert with registration processes etc. and a = distribution framework such as OPEN. Thanks, Tim Grapes Evolution Technologies, Inc. An SDVOB "Service Disabled Veteran-Owned Business" Office:=A0 (703) 654-6075 Mobile:=A0 (703) 304-4829 Fax: (703) 654-6001 tgrapes@evotecinc.com http://www.evotecinc.com/ "When your work speaks for itself, don't interrupt" - Henry J. Kaiser -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Sunday, July 12, 2009 9:58 PM To: David Aylward (Comcare); 'Art Botterell'; earlywarning@ietf.org; cap-list@incident.com Cc: Timothy Grapes; ltincher@evotecinc.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories All While I might agree with the reasons you have stated for the=20 vagueness of categories, I have to look at Henning's example as a why=20 I don't necessarily want "all warnings" from a geography. For=20 example, he rightfully stated that just because I listed Tsunami=20 warnings as something I care about, I should also care about the=20 chemical leaks, or Tornados in my area too. And there's the rub - who decides what warnings I get? If I subscribe to (conceivably) all warnings in my area, do I really=20 care when Dave has falen and can't reach his beer? Is that so=20 monumental to anyone else? Local policy might dictate that yeah -=20 everyone should do what it takes to get Dave his beer, but I don't=20 necessarily need to care, therefore I will likely NOT want to get=20 this messages. Too many warning messages will create a "cry wolf" mode of me=20 eventually believing none of them are useful, regardless of what they=20 say. I just won't reach for my (whatever) device if it's just out of my reach. Perhaps general categories ought to be looked at, because I think I=20 can see exactly where Hannes is going, and I believe I'm in the same=20 ballpark as him thinking this ought to be a little more specific for=20 subscriptions. James At 03:41 PM 7/12/2009, David Aylward \(Comcare\) wrote: >Hannes: > >That is exactly what I was talking about, but CAP was not designed for that. >It is a >"broadcast to the world" standard. It is excellent for that purpose, = but >not for the more refined purpose you are pursuing. > >The OASIS EDXL Distribution Element was designed for exactly that = purpose: >machine to machine routing based on incident type, role and similar factors, >and primarily as Art suggests in the "wholesale", inter-organization = world. > > >Organizations (and individuals connected to them) subscribe to "hear" = about >incident types within certain geographies. > >We have talked in the past, Hannes, about "core services", the purpose = of >them is to provision queries such as you suggest, and govern rights to = send >and receive such messages. > >Lots of work has been done on these ideas outside of the = message-specific >standards that they would enable. > > >David K. Aylward, President >COMCARE Emergency Response Technology Group >1351 Independence Court, SE >Washington, DC 20003 >202.255.3215 (mobile) >202.295.0136 (office) >202.521.4047 (fax) >daylward@comcare.org > >This communication is intended for the use of the recipient to which it = is >addressed, and may contain confidential, personal and/or privileged >information. Please contact us immediately if you are not the intended >recipient of this communication, and do not copy, distribute, or take action >relying on it. Any communication received in error, or subsequent = reply, >should be deleted or destroyed. > > >-----Original Message----- >From: cap-list-bounces@lists.incident.com >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art Botterell >Sent: Sunday, July 12, 2009 3:23 PM >To: earlywarning@ietf.org; cap-list@incident.com >Subject: Re: [CAP] Definition of Warning Categories > >I'm wondering whether it might be simpler, at least in the near term, >to let consumers subscribe to selected sources rather than to topical >categories. That pushes the question of message authoritativeness / >jurisdiction /credibility out of the CAP infrastructure and into the >larger field of inter-agency and inter-jurisidictional coordination, >where it more properly belongs. > >Taxonomies tend to be culturally loaded and can never be guaranteed to >be complete. Thus there's a real risk of "categorical disconnects" >leading to missed alerts either because of differing interpretations >of categories or of unforeseen events that don't fit our preconceived >categories. Maybe someday we'll have a reliable taxonomy of the >unexpected, but right now a degree of deliberate imprecision seems to >be the best we can do... and I sometimes wonder whether even that is >more helpful than it is risky. > >- Art > > >On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: > > > I should provide a bit more feedback about the background to my > > question. > > > > If you only set the value in the category field for the purpose of > > human > > consumption then there is not really an interoperability issue. > > > > Now, with the work on >http://tools.ietf.org/html/draft-rosen-sipping-cap-03 > > we wanted to define an event package for SIP that allows you to > > "subscribe" > > to certain type of events: you might indicate something like > > location and > > the type of events you are interested in. > > > > Now, the semantic of the category field suddently matters. With the > > individuals-to-citizen emergency services we tried to come up with a > > description of the emergency services categories, see RFC 5031. > > > > Ciao > > Hannes > >_______________________________________________ >This list is for public discussion of the Common Alerting Protocol. = This >list is NOT part of the formal record of the OASIS Emergency Management = TC. >Comments for the OASIS record should be posted using the form at >http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=3Demerg= ency >CAP-list mailing list >CAP-list@lists.incident.com >http://lists.incident.com/mailman/listinfo/cap-list > >This list is not for announcements, advertising or advocacy of any >particular program or product other than the CAP itself. > > > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From budden@nps.edu Mon Jul 13 09:55:45 2009 Return-Path: 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 6DE4428C4EE for ; Mon, 13 Jul 2009 09:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599] 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 XQtXSir2ny-K for ; Mon, 13 Jul 2009 09:55:44 -0700 (PDT) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id 5713928C502 for ; Mon, 13 Jul 2009 09:53:45 -0700 (PDT) Received: from [172.20.57.107] ([172.20.57.107]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 09:54:10 -0700 From: Rex Buddenberg To: Bob Robinson In-Reply-To: <901124.96019.qm@web50909.mail.re2.yahoo.com> References: <901124.96019.qm@web50909.mail.re2.yahoo.com> Content-Type: text/plain Date: Mon, 13 Jul 2009 09:55:12 -0700 Message-Id: <1247504112.2203.67.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 (2.26.1-2.fc11) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 16:54:10.0124 (UTC) FILETIME=[8AE110C0:01CA03DA] X-Mailman-Approved-At: Fri, 17 Jul 2009 03:28:41 -0700 Cc: IAEM List , EM Groups , earlywarning@ietf.org, cap-list@incident.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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, 13 Jul 2009 16:55:45 -0000 Bob, You point into a very interesting parallel development out there in the world. In the stimulus bill last spring was $7.2B in grant money that went to USDA ('broadband' and 'reach to rural') and NTIA in Commerce ('broadband' and 'reach to underserved'). The FCC was also charged with drafting a 'national broadband plan'. FCC published a Notice of Inquiry, for which the comment period just closed last week. About the first comment they sought was a definition of 'broadband'. (For paper coming from inside the beltway, this NOI is pretty good stuff, IMHO). Whatever your definition of broadband, you can look behind it and see 'extension of the internet'. And you should recognize that extension of internet to rural and extension of internet to emergency services has a whole lot of overlap. Just to complete the federal nethead - bellhead list of players, DHS and DoJ are still in circuit-switch. ... and didn't get this batch of grant money. What you ought to get out of this is is that - emergency services vehicles will soon be routinely on the internet. - the citizenry that emergency services exists to serve will increasingly be on the internet. This observation is progressively true in any event -- the netheads always win -- but the stimulus subsidies are probably going to be a substantial accelerant.... Santa Ana winds behind a California wildfire. On Sun, 2009-07-12 at 17:50 -0700, Bob Robinson wrote: > Art, > > Very good analysis. In fact I think the question of user (consumer) disconnect can be put to the broader field of general emergency management communications and in fact it can be a very important part of any attempt to build "standards" that are to be applied across groups/agencies/etc. involved in emergency management. But what the heck, that's just my nickels worth based on 25+ years of EM experience. > > Bob Robinson > > --- On Sun, 7/12/09, Art Botterell wrote: > > > From: Art Botterell > > Subject: Re: [CAP] Definition of Warning Categories > > To: earlywarning@ietf.org, cap-list@incident.com > > Date: Sunday, July 12, 2009, 2:23 PM > > > I'm wondering whether it might be > > simpler, at least in the near term, to let consumers > > subscribe to selected sources rather than to topical > > categories. That pushes the question of message > > authoritativeness / jurisdiction /credibility out of > > the CAP infrastructure and into the larger field of > > inter-agency and inter-jurisidictional coordination, where > > it more properly belongs. > > > > Taxonomies tend to be culturally loaded and can never be > > guaranteed to be complete. Thus there's a real risk of > > "categorical disconnects" leading to missed alerts either > > because of differing interpretations of categories or of > > unforeseen events that don't fit our preconceived > > categories. Maybe someday we'll have a reliable > > taxonomy of the unexpected, but right now a degree of > > deliberate imprecision seems to be the best we can do... and > > I sometimes wonder whether even that is more helpful than it > > is risky. > > > > - Art > > > > > > On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig > > wrote: > > > > > I should provide a bit more feedback about the > > background to my question. > > > > > > If you only set the value in the category field for > > the purpose of human > > > consumption then there is not really an > > interoperability issue. > > > > > > Now, with the work on http://tools.ietf.org/html/draft-rosen-sipping-cap-03 > > > we wanted to define an event package for SIP that > > allows you to "subscribe" > > > to certain type of events: you might indicate > > something like location and > > > the type of events you are interested in. > > > > > > Now, the semantic of the category field suddently > > matters. With the > > > individuals-to-citizen emergency services we tried to > > come up with a > > > description of the emergency services categories, see > > RFC 5031. > > > > > > Ciao > > > Hannes > > > > > _______________________________________________ > This list is for public discussion of the Common Alerting Protocol. This list is NOT part of the formal record of the OASIS Emergency Management TC. Comments for the OASIS record should be posted using the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency > CAP-list mailing list > CAP-list@lists.incident.com > http://lists.incident.com/mailman/listinfo/cap-list > > This list is not for announcements, advertising or advocacy of any particular program or product other than the CAP itself. -- Rex Buddenberg Naval Postgraduate School Code IS/Bu Monterey, Ca 93943 831/656-3576 From budden@nps.edu Mon Jul 13 10:41:52 2009 Return-Path: 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 ABC5628C557 for ; Mon, 13 Jul 2009 10:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] 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 ypJbjv08t7lX for ; Mon, 13 Jul 2009 10:41:51 -0700 (PDT) Received: from virginia.nps.edu (virginia.nps.edu [205.155.65.15]) by core3.amsl.com (Postfix) with ESMTP id 233D228C563 for ; Mon, 13 Jul 2009 10:41:24 -0700 (PDT) Received: from [172.20.57.107] ([172.20.57.107]) by virginia.nps.edu with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 10:41:54 -0700 From: Rex Buddenberg To: "David Aylward (Comcare)" In-Reply-To: <003601ca03de$dcc03ed0$9640bc70$@org> References: <901124.96019.qm@web50909.mail.re2.yahoo.com> <1247504112.2203.67.camel@localhost.localdomain> <003601ca03de$dcc03ed0$9640bc70$@org> Content-Type: text/plain Date: Mon, 13 Jul 2009 10:42:56 -0700 Message-Id: <1247506976.2203.91.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 (2.26.1-2.fc11) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 17:41:54.0807 (UTC) FILETIME=[365D0070:01CA03E1] X-Mailman-Approved-At: Fri, 17 Jul 2009 03:28:42 -0700 Cc: EM Groups , IAEM List , cap-list@incident.com, Bob Robinson , earlywarning@ietf.org Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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, 13 Jul 2009 17:41:52 -0000 On Mon, 2009-07-13 at 13:25 -0400, David Aylward (Comcare) wrote: > Rex: > > Very insightful comments. Certainly you are pointing in the right > direction. Many of us are working with alliances to make sure that safety > uses are part of this stimulus. The law and regulations call for safety to > be part of the mix. In the FCC's NOI, there are a plethora of worthy applications. Let's pick on just a couple: education and schools always makes such a list. And reach to rural has several sub-worthies including remote health care, education, etc. Now look at the problem asking the questions 'what makes emergency services different?' - the geographic coverage for 'reach to rural' and 'reach to emergency services' is about the same - the driving requirement for emergency services is high availability. This requirement makes 'emergency services broadband' a superset of all the others. - security (the FCC's NOI uses the term 'privacy'). And I'd point out that authenticity is more important than privacy (you ever been knee-deep in a situation and watched the rumor mill take off?). The point here is that these requirements belong in applications (like CAP) and not in the comms plumbing. > > However, our enthusiasm should be tempered a bit by the emphasis the > recently issued rules make for use of the funds. With a relatively small > amount of money (a one time shot of $7 billion is small potatoes compared to > something like $35-40 billion annually in industry capex), many of us had > hoped that the rules would leverage this one time investment by focusing on > building integrated demand, i.e. get safety, healthcare, etc sharing > information and thus using broad band more and more. My observation is that both emergency services and schools need internet. But every place I've looked, both are on different planning tracks. > > However, the predominant designated use for the first tranche of the > stimulus funds (only 1/3 of the NTIA amount) is digging trenches for fiber > into rural America. Nothing inherently wrong with that if someone has a > future business model to support the capex. One of the guys I discuss this stuff with is in a western state where there's miles and miles of nothing but miles and miles. His primary concern is to provide coverage, both for emergency services and motorists along the interstate highway that runs through the state. Hmmm ... the highway runs parallel to the railroad and guess where the trenches have already been dug and filled with dark fiber? Part of the problem is indeed capitalization expense, but that's at least equaled by the need to get hitherto stovepipe comms industries working together ... to extend the internet. You can see the problem in action by looking at the NPSTC working groups ... they immediately equated 'broadband' with 'LTE', naively ignoring what the CATV companies call 'broadband internet'-). > > But the problem in the safety/healthcare eco-system is not primarily access > to IP communications trunks, but application layer capability and > interoperability issues. Part of the first part of the stimulus funds are > devoted to "Innovative and sustainable uses of broadband". Hopefully more > will be in the future. David, you're right on target worrying about the sustainability (or at least who you quoted is). What doesn't make economic sense is to extend the internet to those miles and miles ... twice. Once for emergency services and once for something else. What makes a lot more sense is an anchor tenant agreement that 1) meets the emergency services needs and 2) allows the commercial vendor to sell capacity above that commercially. (apologies to Art et al for highjacking the CAP list) > > -----Original Message----- > From: cap-list-bounces@lists.incident.com > [mailto:cap-list-bounces@lists.incident.com] On Behalf Of Rex Buddenberg > Sent: Monday, July 13, 2009 12:55 PM > To: Bob Robinson > Cc: IAEM List; EM Groups; earlywarning@ietf.org; cap-list@incident.com; Art > Botterell > Subject: Re: [CAP] Definition of Warning Categories > > Bob, > > You point into a very interesting parallel development out there in the > world. > > In the stimulus bill last spring was $7.2B in grant money that went to > USDA ('broadband' and 'reach to rural') and NTIA in Commerce > ('broadband' and 'reach to underserved'). The FCC was also charged with > drafting a 'national broadband plan'. > FCC published a Notice of Inquiry, for which the comment period just > closed last week. About the first comment they sought was a definition > of 'broadband'. (For paper coming from inside the beltway, this NOI is > pretty good stuff, IMHO). Whatever your definition of broadband, you > can look behind it and see 'extension of the internet'. And you should > recognize that extension of internet to rural and extension of internet > to emergency services has a whole lot of overlap. > Just to complete the federal nethead - bellhead list of players, DHS > and DoJ are still in circuit-switch. ... and didn't get this batch of > grant money. > > > What you ought to get out of this is is that > - emergency services vehicles will soon be routinely on the > internet. > - the citizenry that emergency services exists to serve will > increasingly be on the internet. > This observation is progressively true in any event -- the netheads > always win -- but the stimulus subsidies are probably going to be a > substantial accelerant.... Santa Ana winds behind a California > wildfire. > > > On Sun, 2009-07-12 at 17:50 -0700, Bob Robinson wrote: > > Art, > > > > Very good analysis. In fact I think the question of user (consumer) > disconnect can be put to the broader field of general emergency management > communications and in fact it can be a very important part of any attempt to > build "standards" that are to be applied across groups/agencies/etc. > involved in emergency management. But what the heck, that's just my > nickels worth based on 25+ years of EM experience. > > > > Bob Robinson > > > > --- On Sun, 7/12/09, Art Botterell wrote: > > > > > From: Art Botterell > > > Subject: Re: [CAP] Definition of Warning Categories > > > To: earlywarning@ietf.org, cap-list@incident.com > > > Date: Sunday, July 12, 2009, 2:23 PM > > > > > I'm wondering whether it might be > > > simpler, at least in the near term, to let consumers > > > subscribe to selected sources rather than to topical > > > categories. That pushes the question of message > > > authoritativeness / jurisdiction /credibility out of > > > the CAP infrastructure and into the larger field of > > > inter-agency and inter-jurisidictional coordination, where > > > it more properly belongs. > > > > > > Taxonomies tend to be culturally loaded and can never be > > > guaranteed to be complete. Thus there's a real risk of > > > "categorical disconnects" leading to missed alerts either > > > because of differing interpretations of categories or of > > > unforeseen events that don't fit our preconceived > > > categories. Maybe someday we'll have a reliable > > > taxonomy of the unexpected, but right now a degree of > > > deliberate imprecision seems to be the best we can do... and > > > I sometimes wonder whether even that is more helpful than it > > > is risky. > > > > > > - Art > > > > > > > > > On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig > > > wrote: > > > > > > > I should provide a bit more feedback about the > > > background to my question. > > > > > > > > If you only set the value in the category field for > > > the purpose of human > > > > consumption then there is not really an > > > interoperability issue. > > > > > > > > Now, with the work on > http://tools.ietf.org/html/draft-rosen-sipping-cap-03 > > > > we wanted to define an event package for SIP that > > > allows you to "subscribe" > > > > to certain type of events: you might indicate > > > something like location and > > > > the type of events you are interested in. > > > > > > > > Now, the semantic of the category field suddently > > > matters. With the > > > > individuals-to-citizen emergency services we tried to > > > come up with a > > > > description of the emergency services categories, see > > > RFC 5031. > > > > > > > > Ciao > > > > Hannes > > > > > > > > _______________________________________________ > > This list is for public discussion of the Common Alerting Protocol. This > list is NOT part of the formal record of the OASIS Emergency Management TC. > Comments for the OASIS record should be posted using the form at > http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergency > > CAP-list mailing list > > CAP-list@lists.incident.com > > http://lists.incident.com/mailman/listinfo/cap-list > > > > This list is not for announcements, advertising or advocacy of any > particular program or product other than the CAP itself. -- Rex Buddenberg Naval Postgraduate School Code IS/Bu Monterey, Ca 93943 831/656-3576 From trutkowski@netmagic.com Fri Jul 17 04:39:17 2009 Return-Path: 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 4204028C2B3 for ; Fri, 17 Jul 2009 04:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 IFgv+ZzOVSmO for ; Fri, 17 Jul 2009 04:39:16 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id D0C6928C2B1 for ; Fri, 17 Jul 2009 04:39:07 -0700 (PDT) Received: from [192.168.1.4] ([96.247.197.77]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KMX00LA7CDIP7Z0@vms173017.mailsrvcs.net> for earlywarning@ietf.org; Fri, 17 Jul 2009 06:39:23 -0500 (CDT) Message-id: <4A6062E6.3070503@netmagic.com> Date: Fri, 17 Jul 2009 07:39:18 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-version: 1.0 To: Rex Buddenberg References: <901124.96019.qm@web50909.mail.re2.yahoo.com> <1247504112.2203.67.camel@localhost.localdomain> In-reply-to: <1247504112.2203.67.camel@localhost.localdomain> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: IAEM List , earlywarning@ietf.org, EM Groups , Bob Robinson , cap-list@incident.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com 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: Fri, 17 Jul 2009 11:39:17 -0000 > > ('broadband' and 'reach to underserved'). The FCC was also charged with > drafting a 'national broadband plan'. > FCC published a Notice of Inquiry, for which the comment period just > closed last week. About the first comment they sought was a definition > Actually, a 25 June Order extended the Reply Comment date to 21 July. So most Replies have not been filed, and you still have time. The proceeding is Docket 09-51, and you can access all the material in the proceeding using ECFS. http://fjallfoss.fcc.gov/prod/ecfs/comsrch_v2.cgi --tony From br@brianrosen.net Fri Jul 17 06:07:24 2009 Return-Path: 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 054543A6E8C for ; Fri, 17 Jul 2009 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599] 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 tQptW9JA94te for ; Fri, 17 Jul 2009 06:07:22 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 6DF893A68A1 for ; Fri, 17 Jul 2009 06:07:22 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MRn8o-0000pj-0f; Fri, 17 Jul 2009 08:06:22 -0500 From: "Brian Rosen" To: "'Timothy Grapes'" , "'James M. Polk'" , "'David Aylward \(Comcare\)'" , "'Art Botterell'" , , References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> <34E56644D3334E8D876CD9368814657E@xppc1> <049d01ca03ca$2fa79770$8ef6c650$@com> In-Reply-To: <049d01ca03ca$2fa79770$8ef6c650$@com> Date: Fri, 17 Jul 2009 09:06:23 -0400 Message-ID: <033b01ca06df$64aa3370$2dfe9a50$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoDXWCKGHMVjL0jTPaEupn80frZxwAbHTJwAMVO7CA= Content-Language: en-us 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 X-Source: X-Source-Args: X-Source-Dir: Cc: ltincher@evotecinc.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Fri, 17 Jul 2009 13:07:24 -0000 Many of us know all about the DE. Of course, we really, really, really would appreciate CAP and EDXL being brought into alignment fully. We do wish to use CAP. =20 But EDXL-DE doesn't help with this discussion of categories, because it doesn't define them either. Brian > -----Original Message----- > From: earlywarning-bounces@ietf.org [mailto:earlywarning- > bounces@ietf.org] On Behalf Of Timothy Grapes > Sent: Monday, July 13, 2009 10:57 AM > To: 'James M. Polk'; 'David Aylward (Comcare)'; 'Art Botterell'; > earlywarning@ietf.org; cap-list@incident.com > Cc: ltincher@evotecinc.com > Subject: Re: [earlywarning] [CAP] Definition of Warning Categories >=20 > While valid points have been made on both sides, I do suggest that the > EDXL-DE be reviewed against your requirements to determine how it may > address your needs. Without opening the hood further, it appears it > could > do the trick in concert with registration processes etc. and a > distribution > framework such as OPEN. >=20 > Thanks, > Tim Grapes > Evolution Technologies, Inc. > An SDVOB "Service Disabled Veteran-Owned Business" > Office:=A0 (703) 654-6075 > Mobile:=A0 (703) 304-4829 > Fax: (703) 654-6001 > tgrapes@evotecinc.com > http://www.evotecinc.com/ > "When your work speaks for itself, don't interrupt" > - Henry J. Kaiser >=20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Sunday, July 12, 2009 9:58 PM > To: David Aylward (Comcare); 'Art Botterell'; earlywarning@ietf.org; > cap-list@incident.com > Cc: Timothy Grapes; ltincher@evotecinc.com > Subject: Re: [earlywarning] [CAP] Definition of Warning Categories >=20 > All >=20 > While I might agree with the reasons you have stated for the > vagueness of categories, I have to look at Henning's example as a why > I don't necessarily want "all warnings" from a geography. For > example, he rightfully stated that just because I listed Tsunami > warnings as something I care about, I should also care about the > chemical leaks, or Tornados in my area too. >=20 > And there's the rub - who decides what warnings I get? >=20 > If I subscribe to (conceivably) all warnings in my area, do I really > care when Dave has falen and can't reach his beer? Is that so > monumental to anyone else? Local policy might dictate that yeah - > everyone should do what it takes to get Dave his beer, but I don't > necessarily need to care, therefore I will likely NOT want to get > this messages. >=20 > Too many warning messages will create a "cry wolf" mode of me > eventually believing none of them are useful, regardless of what they > say. I just won't reach for my (whatever) device if it's just out of = my > reach. >=20 > Perhaps general categories ought to be looked at, because I think I > can see exactly where Hannes is going, and I believe I'm in the same > ballpark as him thinking this ought to be a little more specific for > subscriptions. >=20 > James >=20 > At 03:41 PM 7/12/2009, David Aylward \(Comcare\) wrote: > >Hannes: > > > >That is exactly what I was talking about, but CAP was not designed = for > that. > >It is a > >"broadcast to the world" standard. It is excellent for that purpose, > but > >not for the more refined purpose you are pursuing. > > > >The OASIS EDXL Distribution Element was designed for exactly that > purpose: > >machine to machine routing based on incident type, role and similar > factors, > >and primarily as Art suggests in the "wholesale", inter-organization > world. > > > > > >Organizations (and individuals connected to them) subscribe to "hear" > about > >incident types within certain geographies. > > > >We have talked in the past, Hannes, about "core services", the = purpose > of > >them is to provision queries such as you suggest, and govern rights = to > send > >and receive such messages. > > > >Lots of work has been done on these ideas outside of the message- > specific > >standards that they would enable. > > > > > >David K. Aylward, President > >COMCARE Emergency Response Technology Group > >1351 Independence Court, SE > >Washington, DC 20003 > >202.255.3215 (mobile) > >202.295.0136 (office) > >202.521.4047 (fax) > >daylward@comcare.org > > > >This communication is intended for the use of the recipient to which > it is > >addressed, and may contain confidential, personal and/or privileged > >information. Please contact us immediately if you are not the = intended > >recipient of this communication, and do not copy, distribute, or take > action > >relying on it. Any communication received in error, or subsequent > reply, > >should be deleted or destroyed. > > > > > >-----Original Message----- > >From: cap-list-bounces@lists.incident.com > >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art > Botterell > >Sent: Sunday, July 12, 2009 3:23 PM > >To: earlywarning@ietf.org; cap-list@incident.com > >Subject: Re: [CAP] Definition of Warning Categories > > > >I'm wondering whether it might be simpler, at least in the near term, > >to let consumers subscribe to selected sources rather than to topical > >categories. That pushes the question of message authoritativeness / > >jurisdiction /credibility out of the CAP infrastructure and into the > >larger field of inter-agency and inter-jurisidictional coordination, > >where it more properly belongs. > > > >Taxonomies tend to be culturally loaded and can never be guaranteed = to > >be complete. Thus there's a real risk of "categorical disconnects" > >leading to missed alerts either because of differing interpretations > >of categories or of unforeseen events that don't fit our preconceived > >categories. Maybe someday we'll have a reliable taxonomy of the > >unexpected, but right now a degree of deliberate imprecision seems to > >be the best we can do... and I sometimes wonder whether even that is > >more helpful than it is risky. > > > >- Art > > > > > >On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: > > > > > I should provide a bit more feedback about the background to my > > > question. > > > > > > If you only set the value in the category field for the purpose of > > > human > > > consumption then there is not really an interoperability issue. > > > > > > Now, with the work on > >http://tools.ietf.org/html/draft-rosen-sipping-cap-03 > > > we wanted to define an event package for SIP that allows you to > > > "subscribe" > > > to certain type of events: you might indicate something like > > > location and > > > the type of events you are interested in. > > > > > > Now, the semantic of the category field suddently matters. With = the > > > individuals-to-citizen emergency services we tried to come up with > a > > > description of the emergency services categories, see RFC 5031. > > > > > > Ciao > > > Hannes > > > >_______________________________________________ > >This list is for public discussion of the Common Alerting Protocol. > This > >list is NOT part of the formal record of the OASIS Emergency > Management TC. > >Comments for the OASIS record should be posted using the form at > >http://www.oasis- > open.org/committees/comments/form.php?wg_abbrev=3Demergency > >CAP-list mailing list > >CAP-list@lists.incident.com > >http://lists.incident.com/mailman/listinfo/cap-list > > > >This list is not for announcements, advertising or advocacy of any > >particular program or product other than the CAP itself. > > > > > > > >_______________________________________________ > >earlywarning mailing list > >earlywarning@ietf.org > >https://www.ietf.org/mailman/listinfo/earlywarning >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From tgrapes@evotecinc.com Fri Jul 17 06:36:35 2009 Return-Path: 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 DD7FE28C2D3 for ; Fri, 17 Jul 2009 06:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, 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 JU1JTCGdZGxF for ; Fri, 17 Jul 2009 06:36:34 -0700 (PDT) Received: from outbound-mail-35.bluehost.com (outbound-mail-35.bluehost.com [69.89.18.155]) by core3.amsl.com (Postfix) with SMTP id 7B9E13A6E8C for ; Fri, 17 Jul 2009 06:36:34 -0700 (PDT) Received: (qmail 26504 invoked by uid 0); 17 Jul 2009 13:29:44 -0000 Received: from unknown (HELO host123.hostmonster.com) (74.220.207.123) by outboundproxy2.bluehost.com with SMTP; 17 Jul 2009 13:29:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=evotecinc.com; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=nYWYu6jm5ujVl+1MvkQivRys9X/SAmpZaeokquN1S+cHXkHH/YHqbZDncquPY8dCb9llW436md+it6zj0YWMfxLIJTo+o2uBKQ7aXbVsxxvmRBVrP74NycK51SwH3Y57; Received: from pool-173-66-212-229.washdc.fios.verizon.net ([173.66.212.229] helo=PC276735688210) by host123.hostmonster.com with esmtpa (Exim 4.69) (envelope-from ) id 1MRnVO-00053q-3W; Fri, 17 Jul 2009 07:29:42 -0600 From: "Timothy Grapes" To: "'Brian Rosen'" , "'James M. Polk'" , "'David Aylward \(Comcare\)'" , "'Art Botterell'" , , References: <82AE05D27DEDB04488869E55FDAB71FDA1C0FB@s-gov-mail-4.govaxa.ai> <18ee01ca0322$b7a97d30$501ca20a@nsnintra.net> <30076E62-60BC-4488-9F10-33686E82E657@incident.com> <34E56644D3334E8D876CD9368814657E@xppc1> <049d01ca03ca$2fa79770$8ef6c650$@com> <033b01ca06df$64aa3370$2dfe9a50$@net> In-Reply-To: <033b01ca06df$64aa3370$2dfe9a50$@net> Date: Fri, 17 Jul 2009 09:29:42 -0400 Message-ID: <009a01ca06e2$a5980760$f0c81620$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoDXWCKGHMVjL0jTPaEupn80frZxwAbHTJwAMVO7CAAAJnAAA== Content-Language: en-us X-Identified-User: {575:host123.hostmonster.com:evoteci1:evotecinc.com} {sentby:smtp auth 173.66.212.229 authed with tgrapes@evotecinc.com} Cc: emergency@lists.oasis-open.org, ltincher@evotecinc.com Subject: Re: [earlywarning] [CAP] Definition of Warning Categories X-BeenThere: earlywarning@ietf.org 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: Fri, 17 Jul 2009 13:36:36 -0000 Hi Brian, FYI, the DE contains a ContentKeyword in the ContentObject element = which might be a valid usage of this element in context of wrapping and distributing a warning message. You're correct that it doesn't define categories. But if usage policies were defined and then categories were to be defined, agreed to and maintained under governance in an accessible location, ContentKeyword provides a consistent application of those categories.=20 I'm sure valid debate may ensue, but this is one reason this type of flexibility was built into the DE. I'm only suggesting this be = considered as an existing available solution / usage of the DE rather than = discounting it as an option up front. Element contentKeyword Type List and Associated Value(s) Usage OPTIONAL, MAY use multiple Definition The topic related to the message data and content, as it may determine message distribution and presentation decisions. Comments 1. The list and associated value(s) is in the form: valueListUrn value where the content of is the Uniform Resource Name of a published list of values and definitions, and the content of is a string (which may represent a number) denoting the value itself. 2. Multiple instances of the , MAY occur with a single = within the container. 3. Multiple instances of MAY occur within a single container. Examples of things might be used to describe include message processor, event stage, resource code and response type. Subelements =95 valueListUrn =95 value Used In contentObject Thanks, Tim Grapes Evolution Technologies, Inc. An SDVOB "Service Disabled Veteran-Owned Business" Office:=A0 (703) 654-6075 Mobile:=A0 (703) 304-4829 Fax: (703) 654-6001 tgrapes@evotecinc.com http://www.evotecinc.com/ "When your work speaks for itself, don't interrupt" - Henry J. Kaiser -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, July 17, 2009 9:06 AM To: 'Timothy Grapes'; 'James M. Polk'; 'David Aylward (Comcare)'; 'Art Botterell'; earlywarning@ietf.org; cap-list@incident.com Cc: ltincher@evotecinc.com Subject: RE: [earlywarning] [CAP] Definition of Warning Categories Many of us know all about the DE. Of course, we really, really, really would appreciate CAP and EDXL being brought into alignment fully. We do wish to use CAP. =20 But EDXL-DE doesn't help with this discussion of categories, because it doesn't define them either. Brian > -----Original Message----- > From: earlywarning-bounces@ietf.org [mailto:earlywarning- > bounces@ietf.org] On Behalf Of Timothy Grapes > Sent: Monday, July 13, 2009 10:57 AM > To: 'James M. Polk'; 'David Aylward (Comcare)'; 'Art Botterell'; > earlywarning@ietf.org; cap-list@incident.com > Cc: ltincher@evotecinc.com > Subject: Re: [earlywarning] [CAP] Definition of Warning Categories >=20 > While valid points have been made on both sides, I do suggest that the > EDXL-DE be reviewed against your requirements to determine how it may > address your needs. Without opening the hood further, it appears it > could > do the trick in concert with registration processes etc. and a > distribution > framework such as OPEN. >=20 > Thanks, > Tim Grapes > Evolution Technologies, Inc. > An SDVOB "Service Disabled Veteran-Owned Business" > Office:=A0 (703) 654-6075 > Mobile:=A0 (703) 304-4829 > Fax: (703) 654-6001 > tgrapes@evotecinc.com > http://www.evotecinc.com/ > "When your work speaks for itself, don't interrupt" > - Henry J. Kaiser >=20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Sunday, July 12, 2009 9:58 PM > To: David Aylward (Comcare); 'Art Botterell'; earlywarning@ietf.org; > cap-list@incident.com > Cc: Timothy Grapes; ltincher@evotecinc.com > Subject: Re: [earlywarning] [CAP] Definition of Warning Categories >=20 > All >=20 > While I might agree with the reasons you have stated for the > vagueness of categories, I have to look at Henning's example as a why > I don't necessarily want "all warnings" from a geography. For > example, he rightfully stated that just because I listed Tsunami > warnings as something I care about, I should also care about the > chemical leaks, or Tornados in my area too. >=20 > And there's the rub - who decides what warnings I get? >=20 > If I subscribe to (conceivably) all warnings in my area, do I really > care when Dave has falen and can't reach his beer? Is that so > monumental to anyone else? Local policy might dictate that yeah - > everyone should do what it takes to get Dave his beer, but I don't > necessarily need to care, therefore I will likely NOT want to get > this messages. >=20 > Too many warning messages will create a "cry wolf" mode of me > eventually believing none of them are useful, regardless of what they > say. I just won't reach for my (whatever) device if it's just out of = my > reach. >=20 > Perhaps general categories ought to be looked at, because I think I > can see exactly where Hannes is going, and I believe I'm in the same > ballpark as him thinking this ought to be a little more specific for > subscriptions. >=20 > James >=20 > At 03:41 PM 7/12/2009, David Aylward \(Comcare\) wrote: > >Hannes: > > > >That is exactly what I was talking about, but CAP was not designed = for > that. > >It is a > >"broadcast to the world" standard. It is excellent for that purpose, > but > >not for the more refined purpose you are pursuing. > > > >The OASIS EDXL Distribution Element was designed for exactly that > purpose: > >machine to machine routing based on incident type, role and similar > factors, > >and primarily as Art suggests in the "wholesale", inter-organization > world. > > > > > >Organizations (and individuals connected to them) subscribe to "hear" > about > >incident types within certain geographies. > > > >We have talked in the past, Hannes, about "core services", the = purpose > of > >them is to provision queries such as you suggest, and govern rights = to > send > >and receive such messages. > > > >Lots of work has been done on these ideas outside of the message- > specific > >standards that they would enable. > > > > > >David K. Aylward, President > >COMCARE Emergency Response Technology Group > >1351 Independence Court, SE > >Washington, DC 20003 > >202.255.3215 (mobile) > >202.295.0136 (office) > >202.521.4047 (fax) > >daylward@comcare.org > > > >This communication is intended for the use of the recipient to which > it is > >addressed, and may contain confidential, personal and/or privileged > >information. Please contact us immediately if you are not the = intended > >recipient of this communication, and do not copy, distribute, or take > action > >relying on it. Any communication received in error, or subsequent > reply, > >should be deleted or destroyed. > > > > > >-----Original Message----- > >From: cap-list-bounces@lists.incident.com > >[mailto:cap-list-bounces@lists.incident.com] On Behalf Of Art > Botterell > >Sent: Sunday, July 12, 2009 3:23 PM > >To: earlywarning@ietf.org; cap-list@incident.com > >Subject: Re: [CAP] Definition of Warning Categories > > > >I'm wondering whether it might be simpler, at least in the near term, > >to let consumers subscribe to selected sources rather than to topical > >categories. That pushes the question of message authoritativeness / > >jurisdiction /credibility out of the CAP infrastructure and into the > >larger field of inter-agency and inter-jurisidictional coordination, > >where it more properly belongs. > > > >Taxonomies tend to be culturally loaded and can never be guaranteed = to > >be complete. Thus there's a real risk of "categorical disconnects" > >leading to missed alerts either because of differing interpretations > >of categories or of unforeseen events that don't fit our preconceived > >categories. Maybe someday we'll have a reliable taxonomy of the > >unexpected, but right now a degree of deliberate imprecision seems to > >be the best we can do... and I sometimes wonder whether even that is > >more helpful than it is risky. > > > >- Art > > > > > >On Jul 12, 2009, at 7/12/09 11:58 AM, Hannes Tschofenig wrote: > > > > > I should provide a bit more feedback about the background to my > > > question. > > > > > > If you only set the value in the category field for the purpose of > > > human > > > consumption then there is not really an interoperability issue. > > > > > > Now, with the work on > >http://tools.ietf.org/html/draft-rosen-sipping-cap-03 > > > we wanted to define an event package for SIP that allows you to > > > "subscribe" > > > to certain type of events: you might indicate something like > > > location and > > > the type of events you are interested in. > > > > > > Now, the semantic of the category field suddently matters. With = the > > > individuals-to-citizen emergency services we tried to come up with > a > > > description of the emergency services categories, see RFC 5031. > > > > > > Ciao > > > Hannes > > > >_______________________________________________ > >This list is for public discussion of the Common Alerting Protocol. > This > >list is NOT part of the formal record of the OASIS Emergency > Management TC. > >Comments for the OASIS record should be posted using the form at > >http://www.oasis- > open.org/committees/comments/form.php?wg_abbrev=3Demergency > >CAP-list mailing list > >CAP-list@lists.incident.com > >http://lists.incident.com/mailman/listinfo/cap-list > > > >This list is not for announcements, advertising or advocacy of any > >particular program or product other than the CAP itself. > > > > > > > >_______________________________________________ > >earlywarning mailing list > >earlywarning@ietf.org > >https://www.ietf.org/mailman/listinfo/earlywarning >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning