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

["Hannes Tschofenig" <Hannes.Tschofenig at gmx.net>]

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 at ietf.org
>> [mailto:earlywarning-bounces at ietf.org] On Behalf Of James M. Polk
>> Sent: Monday, July 13, 2009 2:58 AM
>> To: David Aylward (Comcare); 'Art Botterell'; earlywarning at ietf.org; 
>> cap-list at incident.com
>> Cc: Timothy Grapes; ltincher at 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 at 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 at lists.incident.com
>> >[mailto:cap-list-bounces at lists.incident.com] On Behalf Of
>> Art Botterell
>> >Sent: Sunday, July 12, 2009 3:23 PM
>> >To: earlywarning at ietf.org; cap-list at 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 at 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 at ietf.org
>> >https://www.ietf.org/mailman/listinfo/earlywarning
>> 
>> _______________________________________________
>> earlywarning mailing list
>> earlywarning at ietf.org
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> 
>_______________________________________________
>earlywarning mailing list
>earlywarning at ietf.org
>https://www.ietf.org/mailman/listinfo/earlywarning
>