Ad-hoc meeting to Authority-to-Individuals Emergency Services ("Early Warning") ------------------------------------------------------------- Facilitators: Hannes Tschofenig Steve Norreys Marc Linsner Notetaker: Roger Marshall Date: 7/23/2007 Time: 11:30- Discussion around the need, (i.e., background, London subway bombing) Discuss some of the requirements that Steve codified in a -00 draft Steve: Read excerpts from the London underground bombings All sorts of communication issues identified Recommendation 22: London's emerg. Plans revised to include specifics.... Walking wounded - just walked away Some emergency rooms set up, but one had no attendees, overall they figured 20-25% (within the hour) James W.: Telling them where to go may not be enough. Steve: Might be good to tell them how to get there as a requirement Requirements: Req-1 Real-time? Jonathan Rosenburg - what does real-time mean? Sub-150ms, as in voice? Hannes: Study in ETSI EMTEL essentially concluded that SMS was not adequate, sometimes delays up to several hours. Steve Norreys: Generally, within 15 min to 1 hour James Polk: Suggests that 15min-1hr doesn't apply well to a Tsunami, etc. Maybe there should be a comparison between different types, including Tornados, Hurricanes, Tsunamis, Earthquakes, etc., and search for the commonalities. EKR: Most of this assumes some lower level of capability, e.g., a subscribe operation, etc. Ted Hardie: Well-detailed information will be contextualized on its own. Brian Rosen: Everyone that looks at this problem, assumes a broadcast technology/solution. Broadcasting doesn't work on the Internet. EKR: I'm not sure that broadcasting won't work. Typcally, broadcast technologies in the past have taken over the service entirely, doesn't have to be true for the Internet. Jon: Whatever solution, where-ever this is worked, there must be some level of opting in. ___: Carriers may not require an opt-in process. Jon: Yeah, carriers are essentially opting-in the customer. Hannes: There is also the notion of regional context, even into a remote region, e.g., wanting to know what's happening in Munich, rather than Chicago this week. Hannes shows architecture diagram slide Peter Blatherwick: Is there something that addresses the area/region of interest? Hannes: this is in the Alert itself. Brian Carpenter: We need to make sure that the security aspects are done well, since at the first misuse, compromise, etc., the system will lose its popularity. Peter: Also, is there thought of how this alert makes it through the spam filters. James Polk: I think the idea that says "alerts rarely happen" is relative, depending on the events which people are interested in. Brian Rosen: EDXL Emergency Data eXchange Language - Gov't first, then standardized by OASIS Packages: Resource request (e.g., diesel, or hospital bed number) CAP Common Alerting Protocol Alert=warning Not a protocol - more of a messaging format Needs a transport Draft-rosen-sipping-cap-00 SIP for the transport, CAP for the messaging Ted: Is it possible to to single out the "Purple shirted firemen" Ted: Does this assume that you'd have to resubscribe if you moved out of the boundary? Brian: Personal view is that yes, would work similarly as would LoST - tells you when you've moved outside. OGC preso (Hannes rec'd from Carl Reed) COMCARE EPAD Use of GeoRSS and EM Jonathan: Is it done, what are we discussing that this doesn't solve. Ted: RSS is fundamentally pull-based. Creating a lot of traffic, fairly chatty. Alternative would be to use Notify, e.g., which is push-based. Marc: Interested? Hannes: More important question is to whether this is an interesting enough problem? Ted: Needs a bigger BOF, providing a transport may be something the IETF could do, but not necessarily a messaging format (if those already exist). James P: not sure SIP is the right transport Brian Rosen: There have been other transports suggested. Hannes: Are people willing to do this? Jon: We need to be careful to make sure that this doesn't impede the progress of ECRIT