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

["DRAGE, Keith (Keith)" <[e-mail]>]

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. 

Secondly, surely we should be seeking some alignment of warning types between the different delivery mechanisms. 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.

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.

CMAS CBS Message Identifier for Presidential Level Alerts.
CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Urgency of Immediate, and Certainty of Observed.
CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Urgency of Immediate, and Certainty of Likely.
CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Urgency of Expected, and Certainty of Observed.
CMAS CBS Message Identifier for Extreme Alerts with Severity of Extreme, Urgency of Expected, and Certainty of Likely.
CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urgency of Immediate, and Certainty of Observed.
CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urgency of Immediate, and Certainty of Likely.
CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urgency of Expected, and Certainty of Observed.
CMAS CBS Message Identifier for Severe Alerts with Severity of Severe, Urgency 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-drafts, yet surely you will have the same content providers generating these messages, 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 ATIS.

ITU-T SG2 also believe they are playing in this space.

regards

Keith



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