Re: [earlywarning] [CAP] Definition of Warning Categories

"David Aylward \(Comcare\)" <daylward@comcare.org> Sun, 12 July 2009 20:50 UTC

Return-Path: <daylward@natstrat.com>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1E83A6C5B for <earlywarning@core3.amsl.com>; 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 <earlywarning@core3.amsl.com>; 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 <earlywarning@ietf.org>; 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)" <daylward@comcare.org>
To: 'Hannes Tschofenig' <Hannes.Tschofenig@gmx.net>, cap-list@incident.com, earlywarning@ietf.org
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 " <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: 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.  

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.  

 
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: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
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, 

Is this really so difficult? 

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. 

So, is there an initial list flying around somewhere already? 

Ciao
Hannes

PS: What is the <category> element in the CAP document used for today? 

>-----Original Message-----
>From: cap-list-bounces@lists.incident.com 
>[mailto:cap-list-bounces@lists.incident.com] On Behalf Of 
>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 
>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_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.
>