Authority-to-Individuals Emergency Service ("Early Warning Service") Adhoc Meeting
----------------------------------------------------------------------------------

Chaired by Hannes Tschofenig, Marc Linsner, Steve Norreys

Slides are available at:
http://www.tschofenig.com/twiki/bin/view/EmergencyServices/EarlyWarningBarBOF

Introduction
-------------

Presented by Hannes Tschofenig and Steve Norreys

-- Anticipation that regulators will want this functionality from VSPs

-- Scenario: London bombing 7/7/05
	-- Tell bystanders the situation, whether they're in danger
	-- Tell "walking wounded" where to go for help
	-- Recommendation for a way to communicate with people affected by an incident ASAP

-- Requirements document available: draft-norreys-ecrit-authority2individuals-requirements-00.txt

-- Meaning of “real time” can vary a LOT, depending on nature of the emergency. 
   Scoping of who to contact (“context”) also depends on nature of the emergency

-- Q(Ekr): What are the assumptions about recipient capabilities?
	-- (Hannes) Our scope is IP-based networks, but there are other things beyond our scope

-- Q(Hardie): The underlying requirement here is that recipients be associated with some context.  Do we have the mechanisms for establishing these associations?  If we look at how you do contextualization first, then the mechanisms for communicating might be more obvious.  If you're precise in the information you pass, you can also establish context in the message itself, and not in the dissemination medium.

-- Q(Rosen): All the versions of this I know about are broadcast -- know who you're talking to, just firing it out -- real broadcast mechanisms.  How do you form these broadcast contexts on the Internet?
	-- (ekr) One characteristic of emergency systems is that they take over everything.  Does that work for the Internet?

-- Q: Is it an “opt in” approach?   Controversial, but seems likely yes. Many scenarios really would want user to specifically opt in. However, many other important ones do not – agencies may want (or regulate) that all ES announcements go to all to whom they apply, like it or not (eg. tsunami, tornado, bomb threat, etc.). “Opting in” may be a static setting for some, automated for others (e.g., mobile cases). 

-- (JPet): If we're serious about scoping this, it's going to involve opt-in.  So it's not really about taking over everything.  
	-- (Norreys) You might get a conflict here between requirements of citizens and authorities
	-- (JPet) No doubt that authorities may compel you to opt in.  At a protocol level, should consider it separate.
	-- (Hannes) Also consider the remote notification case -- still want to know about home when I'm away.

-- (ekr) Maybe this isn't specific to authority to individual -- just urgent notifications. 
	-- (Hannes) Requirements for security and scalability.  E.g., RSS works for small cases, but not for huge events with lots of listeners.
	-- (ekr) This is not in the requirements.

-- (BCarpenter) Authentication is a critical component.  Authentication failures undermine the credibility of the system.


Example Solution: CAP Usage in SIP
----------------------------------

Presented by Brian Rosen

-- EDXL (Emergency Data Exchange Language)
	-- XML-based, developed by DHS, OASIS standard
	-- CAP (Common Alerting Protocol) preadates EDXL, basis for EDXL, now a usage of EDXL
		--> Now mandatory to distribute TV alert messages in CAP

-- draft-rosen-sipping-cap-00 defines an event package to carry CAP in SIP
	-- Needs more work to address who to send to, who to subscribe to

-- Q(Linsnser): CAP contains geography, is this extensible to other criteria?
	-- A: Pretty general, but ...

-- Q(Hardie): Say I always want to know about tsunami warnings, wherever I am.  
Do I need to periodically re-subscribe when I move?
	-- A: LoST paradigm for now, servers have geographical coverage areas.
	-- Q: This could run into limitations, e.g. with underground

Example: GeoRSS
---------------



Presented by Hannes Tschofenig & Brian Rosen 

-- Proposal by OGC

-- EPAD for authority-to-authority

-- Q(JDR): What are we doing in addition to this?
	-- A(Hardie): RSS is pull-based.  That doesn't work for rare events with high time-granularity
	-- (JDR): We need to be clear about what these differences are.
	-- (BCarpenter): There's also authentication issues
	-- (JPolk) How long are these subscriptions going to last?
	-- (Winterbottom) Lots of ways to resolve that, either with geographical disseminators or with filtering presence servers
	-- (Schwarz): This is auth-to-individual


Open Mike
----------

Q(Hannes): Is this topic something we want to get involved in?
	-- (Hardie) Yes, support doing a BOF.  Not close to asking for a WG.  Maybe we can provide a transport for CAP.
	-- (JPolk) Agree with Ted.  OASIS would be the right place to extend CAP - we shouldn't work on a CAP alternative.
           SIP might not be the best transport.  Want to discuss.
	-- (Rosen) Other people are proposing transports for CAP

Q(Hannes): Prepare for a BOF at a future IETF meeting?
	-- (JPet) Don't want this to step on other work.  If people will commit to delivering ECRIT first...
	-- Consensus to prepare a BOF sometime in the future.