Subject: [Ecrit] draft-norreys-ecrit-authority2individuals-requirements-01.txt

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 12 Jul 2008 15:02:53 +0300

Hi all,

I have re-submitted the "Requirements for Authority-to-Individuals 
Communication for Emergency Situations" document.

Abstract

   Public safety agencies need to provide information to the general
   public before and during large-scale emergencies.  While many aspects
   of such systems are specific to national or local jurisdictions,
   emergencies span such boundaries and notifications need to reach
   visitors from other jurisdictions.  This document summarizes
   requirements for protocols to alert individuals within a defined
   geographic area.

The document can be found here:
http://www.ietf.org/proceedings/staging/draft-norreys-ecrit-authority2individuals-requirements-01.txt
(The filename was too long and hence it needs manual processing by the 
secretary.)

Btw, I noticed that the comments by Leopold Murhammer haven't been 
addressed appropriately.
His comments can be found here: 
http://www.ietf.org/mail-archive/web/ecrit/current/msg04035.html

Ciao
Hannes

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 12 Jul 2008 20:44:05 +0300

Hi Art,

thanks for your question.

Art Botterell wrote:
> Hello Hannes -
>
> Very very interesting.  I'm curious, though, your draft makes no 
> mention of the OASIS Common Alerting Protocol standard, which is also 
> ITU recommendation X.1303.  I'm sure that wasn't an oversight, but 
> maybe you could say a few words about how this initiative might relate 
> to that one.
>
We did not want to put a solution into the requirements document.

Based on the previous adhoc meeting on early warning, I guess it was mid 
last year, I got the impression that the participants were looking for a 
way to carry CAP documents using some IETF protocols. The following 
document is an example of such an approach:
http://www.ietf.org/internet-drafts/draft-rosen-sipping-cap-02.txt

Abstract:

The Common Alerting Protocol (CAP) is an XML document format for
exchanging emergency alerts and public warnings.  This document
allows CAP documents to be distributed via the event notification
mechanism available with the Session Initiation Protocol (SIP).

This is very similar to CAP over XMPP:
http://www.xmpp.org/extensions/xep-0127.html

> Also, on a more substantive level, I'm wondering whether there might 
> be a bit of a tension between Requirement 1  ("real-time delivery") 
> and Requirement 9 ("independent of the underlying access network 
> technology").  How would you envision specifying latency parameters 
> without creating dependencies on the transport layer?
>
That's a good point. We have also noticed in the early warning meeting 
(see 
http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EarlyWarningBarBOF)  
we had that there are clearly different types of alerts we need to 
differentiate and some have real-time requiremens and other do not have 
them. Additionally, it depends on the person you talk to; some prefer 
higher layer solutions only and others again want to go all the way down 
to the link layer.

So, there is a bit of an architectural question looming over us. 
Unfortunately, we haven't gotten a good grip on the big picture yet.
I believe we are still in the phase of figuring out what the "customers" 
of this technology are going to be and how we can best interact with them.

Finally, there is the question on what "real-time" precisely means. Many 
years ago I worked in a group dealing with real-time operating systems 
and using their terminology, I would argue we are talking about "soft 
real-time" here and not "hard real time". But we need to flesh these 
things out a bit more. I do see a clear problem with the deployment 
difficulty one creates when demanding too much. If we could work out a 
solution that does not require any changes to layer 2 and layer 3 
devices then we are in a much better position when it comes to a 
realistic deployment story for something on the Internet.

Ciao
Hannes

> Thanks!
>
> - Art
>
> Art Botterell
> Community Warning System Manager
> Office of the Sheriff
> Contra Costa County (California)
> http://www.cocosheriff.org/cws/
>
>
> On Jul 12, 2008, at 7/12/08 5:02 AM, Hannes Tschofenig wrote:
>
>> Hi all,
>>
>> f geographic area.
>> (The filename was too long and hence it needs manual processing by 
>> the secretary.)
>>
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning

---

From: <[email-masked]>
Date: Mon, 14 Jul 2008 16:00:10 +0100

Art

This draft is a requirements draft whereas the OASIS CAP is a protocol
solution to a part of overall problem in this space i.e. how to convey
the emergency early message. So when the solutions are agreed upon then
CAP may be part of this but first of all we need to get the requirements
agreed first.

You are correct with your second point and it was agreed that the words
should reflect the outcome of the ad hoc meeting where this point was
raised. Why is a real time solutions required for a early warning for a
flood warning in two hours does not require real time procedures,
however an early warning to get everyone out of a particular area
because a gas leak has been found does require real time solutions. What
is needed is to word the text to reflect the type of emergency scenario
e.g. "The early warning is given in a time pertinent to the emergency
situation"

Regards

Steve Norreys

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Art Botterell
Sent: 12 July 2008 18:05
To: Hannes Tschofenig
Cc: [email-masked]; 'ECRIT'; Murhammer, Leopold
Subject: Re:
[earlywarning]draft-norreys-ecrit-authority2individuals-requirements-01.
txt

Hello Hannes -

Very very interesting.  I'm curious, though, your draft makes no mention
of the OASIS Common Alerting Protocol standard, which is also ITU
recommendation X.1303.  I'm sure that wasn't an oversight, but maybe you
could say a few words about how this initiative might relate to that
one.

Also, on a more substantive level, I'm wondering whether there might be
a bit of a tension between Requirement 1  ("real-time delivery") and
Requirement 9 ("independent of the underlying access network
technology").  How would you envision specifying latency parameters
without creating dependencies on the transport layer?

Thanks!

- Art

Art Botterell

> The document can be found here:
http://www.ietf.org/proceedings/staging/draft-norreys-ecrit-authority2in
dividuals-requirements-01.txt