Subject: [Ecrit] Authority-to-Citizen Adhoc Meeting: Meeting Minutes now available

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Aug 2007 21:10:34 +0200

Thanks to Peter and Richard for sending me their notes.

/////////////

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.priv.at/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.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit