Subject: [atoca] Alert signing

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 15 Sep 2011 15:09:30 +0800

(moving this topic on-list to include a few more folks)

(as individual)

On 2011-09-15 at 13:38:33, Richard L. Barnes wrote:
> > * In slide 8 you talk about the secure alert format. In the Prague
> IETF presentation I spoke about security and there was a big outcry 
> about using XML (and XMLDSIG) to protect the CAP message. Since we 
> settled with CAP as a format I wonder where we are with this issue. 
> The only alternative I see is to switch to JSON and use JSON based signing.
> This would deal with our problems, I believe.
> 
> I think CMS is also viable, but I don't care that much.  I hesitate a 
> little to use the WOES/JOSE stuff, only because it's not there yet.

I understand the reservations about JOSE, but the very fact that JOSE even exists should tell you something about this.

I think that the primary considerations are:

 - size
 - practicality of implementation

Smaller size will help us avoid some problems, such as alert fragmentation.  Smaller packets are less likely to cause congestion.  But once beyond some as-yet-undetermined threshold, size becomes a secondary concern and we have to turn to the other.

Once any hard limits are deal with, we need to optimize for adoption.  XMLDSIG is not a practically interoperable technology.  We might find that CAP in PER with CMS gives us the best size overall, but that it doesn't get implemented at all because it sucks to implement.  Or even just because it looks hard.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 15 Sep 2011 17:23:14 +0300

On Sep 15, 2011, at 10:09 AM, Thomson, Martin wrote:

> XMLDSIG is not a practically interoperable technology.  We might find that CAP in PER with CMS gives us the best size overall, but that it doesn't get implemented at all because it sucks to implement.  Or even just because it looks hard.

I wonder whether there are implementations for the ASN.1 encoding of CAP. 

You are right that the size considerations are difficult to deal with since the content of the CAP message is essentially non-restricted. Switching to JSON will not help with this issue. IP fragmentation will cause problems with NATs and firewalls, which are unfortunately found in almost every real network today.

---

From: Art Botterell <[email-masked]>
Date: Thu, 15 Sep 2011 08:03:45 -0700

Yes, I suspect the requirement for non-fragmented packets may need to be reconsidered, since it imposes an arbitrary constraint on message content with no justification other than technological legacy.  

That's the historic path toward fragmentation and non-interoperability among warning systems.  Once we start to adjust functionality to suit a particular implementation, every system operator will want to start optimizing for their particular technology.  Plus we then create a pressure to preserve the limits of current technologies into the future, which can rapidly become a real obstacle to progress.

- Art

PS - I'm not sure I totally accept the claim that XMLDSIG isn't "practically interoperable," at least without some specifics.

On Sep 15, 2011, at 7:23 AM, Hannes Tschofenig wrote:

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

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 15 Sep 2011 17:31:37 +0200

I would argue that at least short messages does create a constraint on the initiator to actually draft meaningful messages in a concise imperative form rather than finally getting around to the real message in page 5 of a sent document.

I'd also rather not provide space for each message to be front-ended by legal disclaimers saying that the sender accepts no responsibility for the information supplied, and is not responsible for any accident or damage accruing on the recipient by acting on this message.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Art Botterell
> Sent: 15 September 2011 16:04
> To: [email-masked]
> Subject: Re: [atoca] Alert signing
> 
> Yes, I suspect the requirement for non-fragmented packets may need to be
> reconsidered, since it imposes an arbitrary constraint on message content
> with no justification other than technological legacy.
> 
> That's the historic path toward fragmentation and non-interoperability
> among warning systems.  Once we start to adjust functionality to suit a
> particular implementation, every system operator will want to start
> optimizing for their particular technology.  Plus we then create a
> pressure to preserve the limits of current technologies into the future,
> which can rapidly become a real obstacle to progress.
> 
> - Art
> 
> PS - I'm not sure I totally accept the claim that XMLDSIG isn't
> "practically interoperable," at least without some specifics.
> 
> 
> >> XMLDSIG is not a practically interoperable technology.  We might find
> that CAP in PER with CMS gives us the best size overall, but that it
> doesn't get implemented at all because it sucks to implement.  Or even
> just because it looks hard.
> >
> > You are right that the size considerations are difficult to deal with
> since the content of the CAP message is essentially non-restricted.
> Switching to JSON will not help with this issue. IP fragmentation will
> cause problems with NATs and firewalls, which are unfortunately found in
> almost every real network today.
> >

---

From: Art Botterell <[email-masked]>
Date: Thu, 15 Sep 2011 08:51:39 -0700

> I would argue that at least short messages does create a constraint on the initiator to actually draft meaningful messages in a concise imperative form rather than finally getting around to the rea…

The design of CAP was based on a considerable body of social science research regarding warning effectiveness.  While brevity is generally a virtue, it turns out that it's possible to make a warning message too brief, at least if actually eliciting protective action among the recipients is the goal.  In particular, a simple "imperative" message without context will generally not result in action.  (E.g., if I merely shouted "RUN, NOW!" would you run immediately, or would you ask me "Why?  In which direction? How far? And does this really apply to me?")

Encouraging warning originators to write to the point is a worthy goal, but arguably not something that can be enforced a-priori through technology.  The whole point of CAP was to create an interoperability layer that was independent of technical constraints, in the awareness that different delivery mechanisms will impose their own limitations.  (You can think of the CAP message as the Platonic ideal of the warning message, one which casts different shadows on different walls of the cave but has an essential nature common to them all.)

> I'd also rather not provide space for each message to be front-ended by legal disclaimers saying that the sender accepts no responsibility for the information supplied, and is not responsible for a…

Not sure technology can defeat bureaucracy, but I share your desire.  However, are we really talking about what size message will maximize warning effectiveness?  Sounds to me like our true concern is how to fit standard messages into the constraints of a pre-existing technology.

- Art

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 15 Sep 2011 09:45:05 -0600

Interesting discussion.

I understand the use of CAP in many alerting cases. However, there are many 
organizations already using SMS. And in Taiwan, there are more and more 
groups using Open GeoSMS (a new OGC standard) for a variety of alerting 
applications. Other alerting applications are using GeoRSS. I suspect I 
missed something in the conversation, like use CAP for authority to 
authority alerting. Going back to Taiwan, they have a deployed nationwide 
debris flow monitoring and alerting system. They are using multiple alerting 
mechanisms to insure all potentially impacted citizens receive alerts: SMS 
for mobile devices, traditional radio and TV broadcast mechanisms, and so 
forth. 
http://www.awareforum.org/2011/03/sensor-web-enablement-application-for-debris-flow-monitoring-system-in-taiwan/ 
for more information. In Europe, there are major EU framework projects (all 
related to INSPIRE) that have been completed or are in progress that address 
various aspects of alerting, risk management, public safety, and emergency 
services.

Sorry, I just want to understand why CAP only. In the OGC community, current 
efforts have typically abstracted the alert service architecture such that 
the publish/subscribe function for alerts is independent of the alert 
format. In this way, CAP, SMS, GeoSMS, GeoRSS, or whatever format is 
required or desired can be accommodated.

Thanks for any clarification!

Carl

----- Original Message ----- 
From: "Thomson, Martin" <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>; "Hannes Tschofenig" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 15, 2011 1:09 AM
Subject: [atoca] Alert signing

> I understand the reservations about JOSE, but the very fact that JOSE even 
> exists should tell you something about this.
>
> Smaller size will help us avoid some problems, such as alert 
> fragmentation.  Smaller packets are less likely to cause congestion.  But 
> once beyond some as-yet-undetermined threshold, size becomes a secondary 
> concern and we have to turn to the other.
>
> Once any hard limits are deal with, we need to optimize for adoption. 
> XMLDSIG is not a practically interoperable technology.  We might find that 
> CAP in PER with CMS gives us the best size overall, but that it doesn't 
> get implemented at all because it sucks to implement.  Or even just 
> because it looks hard.

---

From: <[email-masked]>
Date: Thu, 15 Sep 2011 17:39:55 +0100

As a 'thought experiment';

e.g. In CellCast's EAGLE front end system, the CAP message is automatically
created by the wizard, then 'launched' into the aggregator system for
distribution, and may contain quite a lot of information that will not be
used in the final distribution to the citizen. 

For example; a JPG picture of a missing child or a map of the shelter
locations could be shown on plasma screens at gas stations but not on
mobiles, while voice clips are routed to speakers and 'dial down' banks. 

The initial verbose version is however, required because the originating
sender does not always control how many distribution methods will be used
and where. 

In addition, the rate of progress in personal communications is so fast that
new capabilities are emerging all the time, and what once seemed impractical
is now 'a given'. It would be a burden to expect the Sheriff to remember all
the new tech.   

EAGLE (for one example) assumes that the sender does not have time to make
multiple manual entries into the UI, so it tries to get it all in one CAP
(but obviously a sender can add as he goes).  So the original proposal may
be quite verbose with a lot of links to other resources or multimedia of its
own embedded in the CAP message, intended for a wide variety of distribution
systems.

The Alert Gateway(s) (AGW) is driven by the local trust protocol, in which
local decision makers (including the networks) have decided who can transmit
what and where and how. 

So AGW determines if a particular proposal will be transmitted by a specific
"instance of participating network", and therefore what degree of filtering
will be applied before it becomes a 'submission' to that "specific instance
of participating network" in accord with the trust protocol agreement with
network operating authority (e.g. AT&T or a campus enterprise network). 

[I think that in the CMAS model the network does this at its 'gateway' unit,
maybe Brian can explain that]. 

For example, an emergency manager may create a quite elaborate message on
the front end, containing images or even script for apps, which is then
packaged by front end in CAP and then parsed and trafficked to other AGWs. 

A phone company may have concurrent 2G, 3G and 4G networks covering the same
area, so need different versions of the same message trafficked to each
(This is why each 'system technology' is treated as a different
"participating network" even if it is owned by the same company). 

For example, it may be possible to 'cell broadcast' the image of the missing
child in 4G, but not in 2G. If one of the participating networks is a second
generation cell broadcast system, for example, then bearer incapable parts
will be stripped off except for the polygon and the text (and some other
control info such as the channel number) before sending on to the CBC of the
network. 

So, some CAP messages will be quite verbose at some early stages, more than
one UPD packet, while others will be sparse, depending on where in the chain
they are.

I suspect that something like Google Alert Hub will probably take the whole
CAP packet (minus security sensitive bits that the AGW strips off) and then
let subscribers filter what they want. This implies best effort push
technology, of course!

IMHO I think this means that a CAP message may indeed be bigger than one UDP
packet. 

Any comments/clarifications?

Mark

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 15 Sep 2011 18:40:27 +0200

See below

> Sent: 15 September 2011 16:52
> To: [email-masked]
> > I would argue that at least short messages does create a constraint on
> the initiator to actually draft meaningful messages in a concise
> imperative form rather than finally getting around to the real message in
> page 5 of a sent document.
> 
> The design of CAP was based on a considerable body of social science
> research regarding warning effectiveness.  While brevity is generally a
> virtue, it turns out that it's possible to make a warning message too
> brief, at least if actually eliciting protective action among the
> recipients is the goal.  In particular, a simple "imperative" message
> without context will generally not result in action.  (E.g., if I merely
> shouted "RUN, NOW!" would you run immediately, or would you ask me "Why?
> In which direction? How far? And does this really apply to me?")
> 
Agreed. 

Did the research come up with any input as to what was enough, before people ignored it. People are talking about fragmentation, which doesn't even become an issue until MTU size is exceeded in IP (1500 bytes). Cell broadcast survives on the order of a hundred bytes. 

At what point do these discussions become irrelevant because the messages should be shorter than that.

Keith

> Encouraging warning originators to write to the point is a worthy goal,
> but arguably not something that can be enforced a-priori through
> technology.  The whole point of CAP was to create an interoperability
> layer that was independent of technical constraints, in the awareness that
> different delivery mechanisms will impose their own limitations.  (You can
> think of the CAP message as the Platonic ideal of the warning message, one
> which casts different shadows on different walls of the cave but has an
> essential nature common to them all.)
> 
> > I'd also rather not provide space for each message to be front-ended by
> legal disclaimers saying that the sender accepts no responsibility for the
> information supplied, and is not responsible for any accident or damage
> accruing on the recipient by acting on this message.
> 
> Not sure technology can defeat bureaucracy, but I share your desire.
> However, are we really talking about what size message will maximize
> warning effectiveness?  Sounds to me like our true concern is how to fit
> standard messages into the constraints of a pre-existing technology.
> 
> - Art

---

From: Art Botterell <[email-masked]>
Date: Thu, 15 Sep 2011 09:54:39 -0700

On Sep 15, 2011, at 9:40 AM, DRAGE, Keith (Keith) wrote:

> Did the research come up with any input as to what was enough, before people ignored it. 

No, I'm not sure there's any strong indication that people have a maximum message size as such.  What matters most are, a) establishing personal relevance to the recipient, b) providing actionable protective-action recommendations, and c) repetition and corroboration via multiple channels (which is why we need a channel-independent meta-standard like CAP.)

The social scientists don't count bytes, of course... their results have mainly to do with what essential items of content were present.  Those elements can be expressed at different lengths depending on both level of detail and writer style.

In practice the uncompressed XML of a CAP message is typically in the range of 0.5 to about 3 KB.  "Attachments" in the resource elements... images and such... can of course, be much larger, but the preferred practice is to provide a URL for as-needed retrieval of resources rather than encoding them in-line.

- Art

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 15 Sep 2011 15:19:49 -0400

Yeah, I think that all this really argues for is having a fragmentation layer over UDP, plus maybe using GZIPped CAP.

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 16 Sep 2011 07:29:24 +0800

On 2011-09-16 at 00:23:14, Hannes Tschofenig wrote:
> cause problems with NATs and firewalls, which are unfortunately found 
> in almost every real network today.

It's quite possible that there is nothing we can do about this, and that it will always be in the hands of those who generate the alerts.  What we can do is identify how much space will be left for the real content after all the packaging and signing is added.

Maximizing the space for content will be a goal, with all the accompanying trade-offs.

--Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 16 Sep 2011 07:37:28 +0800

On 2011-09-16 at 01:45:05, Carl Reed wrote:
> Sorry, I just want to understand why CAP only. In the OGC community, 
> current efforts have typically abstracted the alert service 
> architecture such that the publish/subscribe function for alerts is 
> independent of the alert format. In this way, CAP, SMS, GeoSMS, 
> GeoRSS, or whatever format is required or desired can be accommodated.

CAP serves a useful purpose as the canonical or lowest-common-denominator form.  That shouldn't preclude other representations for domains where another form is better suited.

For instance, cell broadcast doesn't convey CAP; it uses a different representation of information that might have originated as a CAP message.

--Martin

---

From: Art Botterell <[email-masked]>
Date: Thu, 15 Sep 2011 16:56:47 -0700

> For instance, cell broadcast doesn't convey CAP; it uses a different representation of information that might have originated as a CAP message.

This is what I meant earlier about the distinction between technology-specific delivery formats and the technology-agnostic interoperability format.  Once we down-convert from the general standard to some transport-specific representation it's rarely possible to recover all the original information; thus it's generally wisest to defer such translation until the last mile, if only to keep our interoperability options open for the future.

Personally I like to think of CAP as a higher level of abstraction rather than a lesser denominator... since the content of a CAP alert is almost always richer than that of derived products... but that's probably just pride of authorship speaking. ;-)

- Art

---

From: "DALY, BRIAN K" <[email-masked]>
Date: Fri, 16 Sep 2011 01:10:30 +0000

" it uses a different representation of information that might have originated as a CAP message."

For CMAS the original alert message was originated as a CAP message, and the Federal Alert Gateway (within the iPAWS architecture) renders the information into a format suitable for CMAS.

--------
Brian K. Daly
Director, Core Network & Govn't/Regulatory Standards
AT&T Services, Inc.
+1.425.580.6873
[email-masked]

Rethink Possible

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomson, Martin
Sent: Thursday, September 15, 2011 4:37 PM
To: Carl Reed; Richard L. Barnes; Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [atoca] Alert signing

--Martin

---

From: "DALY, BRIAN K" <[email-masked]>
Date: Fri, 16 Sep 2011 01:25:43 +0000

" Did the research come up with any input as to what was enough, before people ignored it. People are talking about fragmentation, which doesn't even become an issue until MTU size is exceeded in IP (1500 bytes). Cell broadcast survives on the order of a hundred bytes."

Actually the FCC's Commercial Mobile System Alert Advisory Committee spend considerable time looking at the issue of "how long should a message be" especially when rendered on a mobile device screen AND accounted for the needs of individuals with disabilities.

Bottom line - people don't want to have to scroll through multiple screens to read information - they want to be told "to the point" with a minimal amount of scrolling through pages of text.

The input obtained from that study is one of the drivers that limited a CMAS alert message to 90 characters (although there was technical consideration as well), PLUS there was research that stated to be most effective the alert message needs to contain the following information, in this order:

1. What's happening (e.g. Tornado Warning)
2. Where it is happening (e.g. "in your/this area")
3. What action to take (e.g., "take shelter now")
4. How long it will be happening (e.g. "until 7pm")
5. Who authorized this/sent this (e.g., "NWS")

--------
Brian K. Daly

Rethink Possible

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: Thursday, September 15, 2011 9:40 AM
To: Art Botterell; [email-masked]
Subject: Re: [atoca] Alert signing

See below

Agreed. 

Keith

---

From: "DALY, BRIAN K" <[email-masked]>
Date: Fri, 16 Sep 2011 01:35:01 +0000

" The design of CAP was based on a considerable body of social science research regarding warning effectiveness.  "

But I am not sure that social science research accounted for mobile devices/device screens/etc. This is where I think the CMSAAC research came into play.

I will be interested in seeing what happens when CMAS is deployed widely and we have some real life experience to analyze - especially on the use case where everyone on a <fill in your favorite major city freeway> at rush hour gets an alert at the same time to "take cover now".

--------
Brian K. Daly

Rethink Possible

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Art Botterell
Sent: Thursday, September 15, 2011 8:52 AM
To: [email-masked]
Subject: Re: [atoca] Alert signing

- Art

---

From: Art Botterell <[email-masked]>
Date: Thu, 15 Sep 2011 19:32:56 -0700

> But I am not sure that social science research accounted for mobile devices/device screens/etc. This is where I think the CMSAAC research came into play.

Not sure to what extent mobile devices and other small screens have changed human psychology and sociology; evolution doesn't generally work all that fast.  As I mentioned before, the science hasn't generally been cast in terms of bytes or pixels.  But if there's research out there that suggests the 90 character CMAS limit (in English, that is, potentially less in some other languages) is anywhere near optimal from a warning effectiveness perspective, I'd love to see a citation.

As you know, Brian, I was one of the first and strongest advocates on the CMSAAC for the automatic construction of a concise string from the CAP enumerated values as a way to accommodate the technical 90-character constraint.  There were folks who wanted the originating officials to construct the 90-character string "freehand," but I was concerned that they didn't appreciate how difficult it can be to write a good headline-sized message, especially under stress and time pressure... and also that it would force time-pressed alert originators to duplicate work by having to write multiple versions of the same message, which was another of the things CAP was invented to avoid.

I should also point out that CMAS isn't the first or even the worst instance of this problem.  Variable message signs on freeways and in transit stations tend to permit even fewer characters and are even more challenging if we want not to wrap words around line breaks .

But my real point is that we should be intellectually honest about this.  We each may have personal opinions about message length, and in any event each delivery medium will impose its own constraints one way or another... but what's really at the heart of this conversation are technological constraints and to what extend we should let them wag the messaging dog.  Fortunately, using CAP on the backbone allows us to compartmentalize such constraints so they don't metastasize beyond their own technical and temporal context.

> I will be interested in seeing what happens when CMAS is deployed widely and we have some real life experience to analyze - especially on the use case where everyone on a <fill in your favorite maj…

Yes, that's a potential problem, and the best way I know of to mitigate it is to target alert delivery as precisely as possible to the folks actually at risk.  This is another area where the technical limitations of particular delivery systems sometimes get confused with best warning practice.

- Art

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 15 Sep 2011 20:37:49 -0600

Martin -

Thanks for the feedback.

Regards

Carl

----- Original Message ----- 
From: "Thomson, Martin" <[email-masked]>
To: "Carl Reed" <[email-masked]>; "Richard L. Barnes" 
<[email-masked]>; "Hannes Tschofenig" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 15, 2011 5:37 PM
Subject: RE: [atoca] Alert signing

> GeoRSS, or whatever format is required or desired can be accommodated.

CAP serves a useful purpose as the canonical or lowest-common-denominator 
form.  That shouldn't preclude other representations for domains where 
another form is better suited.

For instance, cell broadcast doesn't convey CAP; it uses a different 
representation of information that might have originated as a CAP message.

--Martin

---

From: "DALY, BRIAN K" <[email-masked]>
Date: Fri, 16 Sep 2011 02:40:05 +0000

" Not sure to what extent mobile devices and other small screens have changed human psychology and sociology; evolution doesn't generally work all that fast"

Oh but I think it has ... especially with text and social networking. Everything from new "languages" to reliance on their social networks for "information" to the lack of social skills needed for verbal communication....

But that is a discussion for another time :-)

--------
Brian K. Daly

Rethink Possible

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Art Botterell
Sent: Thursday, September 15, 2011 7:33 PM
To: [email-masked]
Subject: Re: [atoca] Alert signing

- Art

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 16 Sep 2011 12:11:43 +0800

On 2011-09-16 at 09:56:47, Art Botterell wrote:
> Personally I like to think of CAP as a higher level of abstraction 
> rather than a lesser denominator... since the content of a CAP alert 
> is almost always richer than that of derived products... but that's 
> probably just pride of authorship speaking. ;-)

Well, if I didn't already know that names matter, I'd say that there's no difference.  But I suspect that both viewpoints are right to some extent.

> Once we down-convert from the general standard to some transport-specific
> representation it's rarely possible to recover all the original information [...]

This is an important point.  To say that CAP is a baseline misrepresents it, because it is usually something _more_ than what is ultimately delivered.  That is the key point that Mark made with his example.

I don't know if the decision has been explicit, but I get the impression that the general desire from the group is to try to deliver CAP as far as possible due to this effect.  The point not being to preclude the sorts of optimizations Mark was talking about, but just to avoid being responsible for any degradation.   That should mean better transport-specific downgrades.

--Martin

---

From: "Mark" <[email-masked]>
Date: Fri, 16 Sep 2011 09:59:54 +0100

Friends;

-
-MT- "The point not being to preclude the sorts of optimizations Mark was
talking about, but just to avoid being responsible for any degradation.
That should mean better transport-specific downgrades."
-

-MW- There is another 'legal liability' aspect to this that we need to bear
in mind. As techno-geeks we don't have the lawful authority to create or in
any way modify the *content* of the message. 

If the message turns out to be wrong, or only partially correct, then
liability for decisions about this must lie with the authorised originating
sender (e.g. the police chief), who does have the appropriate indemnity
under local law, and under the trust protocol which applies to this
relationship with this network. 

This is done because, quite rightly, the "participating network" should on
no account be held liable for the content of the message, otherwise they
would be crazy to participate in the first place. (If I was an AT&T lawyer I
would run a mile from any deal that did not fully indemnify my company from
liability for content).  

Clearly the 'trust protocol' lays out who is liable for what, and the AGWs
make sure that everyone's conditions for participating have been faithfully
followed [well, at least mine do].  

IMHO, As soon as we mess with the content in any way, we may make ourselves
liable to litigation. So it makes sense to transmit the whole original
message 'verbatim' until the last possible inch unless there is compelling
reason to alter it. 

- Mark -

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 16 Sep 2011 13:00:06 +0200

I suggest that in some descriptive part of some potential ATOCA document we capture some of this. 

Keith

> From: DALY, BRIAN K [mailto:[email-masked]]
> Sent: 16 September 2011 02:26
> To: DRAGE, Keith (Keith); Art Botterell; [email-masked]
> " Did the research come up with any input as to what was enough, before
> people ignored it. People are talking about fragmentation, which doesn't
> even become an issue until MTU size is exceeded in IP (1500 bytes). Cell
> broadcast survives on the order of a hundred bytes."
> 
> Actually the FCC's Commercial Mobile System Alert Advisory Committee spend
> considerable time looking at the issue of "how long should a message be"
> especially when rendered on a mobile device screen AND accounted for the
> needs of individuals with disabilities.
> 
> Bottom line - people don't want to have to scroll through multiple screens
> to read information - they want to be told "to the point" with a minimal
> amount of scrolling through pages of text.
> 
> The input obtained from that study is one of the drivers that limited a
> CMAS alert message to 90 characters (although there was technical
> consideration as well), PLUS there was research that stated to be most
> effective the alert message needs to contain the following information, in
> this order:
> 
> DRAGE, Keith (Keith)
> Did the research come up with any input as to what was enough, before
> people ignored it. People are talking about fragmentation, which doesn't
> even become an issue until MTU size is exceeded in IP (1500 bytes). Cell
> broadcast survives on the order of a hundred bytes.
>

---

From: "DALY, BRIAN K" <[email-masked]>
Date: Fri, 16 Sep 2011 11:50:36 +0000

Mark -

Excellent points! And you described the reason why the CMSAAC developed the concept of the Federal Alert Aggregator and Alert Gateway concept in CMAS.

There are upwards of 9000 agencies that have authority to initiate alerts, and the potential for 50,000+ alert originators. As a "broadcaster" of the alerts in commercial mobile networks, we cannot and must not be responsible to determine if an agency or particular alert originator has the authority to generate an alert and send it to the public. That is why the FEMA iPAWS architecture is critical as they have the responsibility for credentialing, authorizing of alert initiators, and ultimately take the responsibility off the "broadcaster" of the alert. The trusted interface to the Federal Alert Gateway (part of the iPAWS architecture) is the CMSPs guarantee that the liability rests with FEMA, as long as we broadcast the CMAS alert verbatim and do not change or interfere with the message.

This is the only model commercial mobile operators will follow to solve the issue you clearly highlight below.

--------
Brian K. Daly

Rethink Possible

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Sent: Friday, September 16, 2011 2:00 AM
To: [email-masked]
Subject: [atoca] Content Responsibility.

Friends;

-

- Mark -

---

From: John Tacken <[email-masked]>
Date: Fri, 16 Sep 2011 15:16:19 +0200

May I add some comments based on experience in The Netherlands with 
NL-ALert (CB based public warning system, to be launched very soon):

*Message size
*For NL-Alert we have a comparable message content structure as 
described in Brian's email below. Additionally, we have added a 
date/timestamp and a link to follow-up information on the crisis. We 
have done several crisiscomm workshops with PSAPs, police and fire 
department. It has proven to be very difficult during these workshops to 
squeeze the required information (i.e. the 5 points mentioned below) in 
90 characters. Try it yourself and you will be convinced. The First 
Responders have urged us to remove the (typical CB) limit of 93 
characters. For them, a 200 or 300 characters max would be more appropriate.

I agree that civilians should not be overloaded with text during a 
crisis. But we should look at the future of mobile phones and not to the 
past. Older phones may have a maximum capacity of 60 characters to 
display before there is a need for scrolling. Newer CMAS compatible 
smartphones that we have tested very neatly display the whole message 
also if it has 200 characters or more.

To understand how much information people can process during a crisis, 
The University of Delft is currently performing additional research on 
the message content via a webexperiment where people are asked to 
provide feedback on specific messages they receive. In Dutch: 
www.waarschuwingsberichten.nl

*Use case
*During the workshops we did with the police and fire department, we 
have noted that not all the required information for sending a complete 
alert message is available from the start. "What's happening" and "where 
is it happening" is information that is available from the start of a 
crisis. But it can take some time before you can advise civilians what 
action to take?. E.g. during a fire in a chemical plant, it takes time 
for the fire department to analyse the content of the chemicals and come 
up with an advise what to do. Crisisicommunication experts that I have 
spoken with prefer to send the available information immediately after 
it has become available and add additional information later. As a 
government, you are never quicker than Twitter, but you should not wait 
too long providing info to the public. So there is a clear need to be 
able to update existing alert messages.

John Tacken
projectmanager implementation NL-Alert

Op 16-9-2011 3:25, DALY, BRIAN K schreef:
> Director, Core Network&  Govn't/Regulatory Standards
> AT&T Services, Inc.
> +1.425.580.6873
> [email-masked]
>
> Rethink Possible
>
>
> -- 
> *___________________________________________*
>
> *John Tacken | Conict Consultants BV*
> Hengeveldstraat 42, 3572 KJ  Utrecht, The Netherlands
>
> *M**+31 6 28525280
> [email-masked] <mailto:[email-masked]>
> *W *www.conict.com*
> *

---

From: "DALY, BRIAN K" <[email-masked]>
Date: Fri, 16 Sep 2011 13:50:51 +0000

See below ...

--------
Brian K. Daly
Director, Core Network & Govn't/Regulatory Standards
AT&T Services, Inc.
+1.425.580.6873
[email-masked]<mailto:[email-masked]>

Rethink Possible

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Tacken
Sent: Friday, September 16, 2011 6:16 AM
To: [email-masked]
Subject: Re: [atoca] Alert signing

May I add some comments based on experience in The Netherlands with NL-ALert (CB based public warning system, to be launched very soon):

Message size
For NL-Alert we have a comparable message content structure as described in Brian's email below. Additionally, we have added a date/timestamp and a link to follow-up information on the crisis. We have done several crisiscomm workshops with PSAPs, police and fire department. It has proven to be very difficult during these workshops to squeeze the required information (i.e. the 5 points mentioned below) in 90 characters. Try it yourself and you will be convinced. The First Responders have urged us to remove the (typical CB) limit of 93 characters. For them, a 200 or 300 characters max would be more appropriate.

<bkd> Actually GSM/UMTS cell broadcast is not limited to 93 characters, but can handle upwards of 1000 characters. Other technologies have a limit, and thus the 90 character CMAS constraint. The problem is because of multiple technologies in the U.S. and the desire to send a consistent message to all users, the 90 characters were chosen. Do it limit? Certainly, but CMAS is a "bell ringer" only and not a full information service such as NOAA Weather Radio.

I agree that civilians should not be overloaded with text during a crisis. But we should look at the future of mobile phones and not to the past. Older phones may have a maximum capacity of 60 characters to display before there is a need for scrolling. Newer CMAS compatible smartphones that we have tested very neatly display the whole message also if it has 200 characters or more.

<bkd> However, not everyone will have a newer smartphone. There is - and always will be - a large number of basic feature phones out there that must be accommodated. Thus the lowest common denominator.

To understand how much information people can process during a crisis, The University of Delft is currently performing additional research on the message content via a webexperiment where people are asked to provide feedback on specific messages they receive. In Dutch: www.waarschuwingsberichten.nl<http://www.waarschuwingsberichten.nl>

Use case
During the workshops we did with the police and fire department, we have noted that not all the required information for sending a complete alert message is available from the start. "What's happening" and "where is it happening" is information that is available from the start of a crisis. But it can take some time before you can advise civilians what action to take?. E.g. during a fire in a chemical plant, it takes time for the fire department to analyse the content of the chemicals and come up with an advise what to do. Crisisicommunication experts that I have spoken with prefer to send the available information immediately after it has become available and add additional information later. As a government, you are never quicker than Twitter, but you should not wait too long providing info to the public. So there is a clear need to be able to update existing alert messages.

John Tacken

--------

Brian K. Daly

AT&T Services, Inc.

+1.425.580.6873

[email-masked]<mailto:[email-masked]>

Rethink Possible

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)

To: Art Botterell; [email-masked]<mailto:[email-masked]>

See below

-----Original Message-----

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of

Art Botterell

To: [email-masked]<mailto:[email-masked]>

Agreed.

Keith

- Art

atoca mailing list

[email-masked]<mailto:[email-masked]>

atoca mailing list

[email-masked]<mailto:[email-masked]>

atoca mailing list

[email-masked]<mailto:[email-masked]>

--
___________________________________________
John Tacken | Conict Consultants BV
Hengeveldstraat 42, 3572 KJ  Utrecht, The Netherlands
M  +31 6 28525280
E    [email-masked]<mailto:[email-masked]>
W  www.conict.com

---

From: Art Botterell <[email-masked]>
Date: Fri, 16 Sep 2011 09:17:53 -0700

I fear we may be drifting rather far afield here, from the original subject of this thread and perhaps from the expertise of this body.  But having actually operated a large-scale, multi-medium public warning system for some years, I do want to head off a couple of possible misconceptions.

On Sep 16, 2011, at 6:16 AM, John Tacken wrote:

> "What's happening" and "where is it happening" is information that is available from the start of a crisis.

Um... not necessarily.  Depending on the hazard type, there can be quite a lot of ambiguity as to the what and where.  An explosion, for example, could be anything from an industrial accident to a dirty bomb.  A gas pipeline rupture here in California last year was miscategorized as an airplane crash for, in some official corners, longer than an hour, because it caused a large fire and occurred near a major airport... and also because that's what responders had been expecting.  This is why a CAP message has a 'certainty' value, although admittedly it's often hard to get officials to admit to any uncertainty!

Anyway, the practical point is that an incident frequently results in a series of updates to an initial alert message as the situation clarifies and/or evolves.

> But it can take some time before you can advise civilians what action to take?. 

Not really, and issuing alerts without protective-action recommendations (the CAP 'instruction' field) is a Bad Idea for several reasons.

First off, it's always possible to provide some sort of instruction, even if its just "be aware and monitor for developments."  In most cases the default instruction is essentially shelter-in-place, since even if an evacuation is contemplated we want folks to gather materials and specific directions before they scatter pell-mell.

Issuing an alert without instructions generally fails in a combination of two ways.  The first, more obvious, problem is that some folks will adopt uncoordinated protective actions at random, thus creating the sort of chaos that we sometimes (pejoratively and inaccurately) call "panic."  

The less obvious, but actually more common, problem is that an alert without instructions is much less powerful in overcoming what the scientists call the "normalcy bias" and the rest of us call plain old denial.  There are various ways this can work inside people's heads.  Some may rationalize that if there isn't a protective action recommendation it must not be time to act yet.  Others may infer that the originating officials don't know what to do and therefore lack credibility. It's amazing how many ways folks can find to rationalize away an unexpected and inconvenient alert.  We don't really know all the mechanics, but the research is clear on the basic point: alerts without instructions are markedly ineffective compared to alerts that have them... even if, as noted above, they're general and preliminary.

- Art

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 16 Sep 2011 13:21:07 -0500

Brian

IP does NOT have an MTU of 1500.

I believe you are thinking of the IEEE 802.3 Ethernet MTU only here.

James

At 08:25 PM 9/15/2011, DALY, BRIAN K wrote:
>" Did the research come up with any input as to what was enough, 
>before people ignored it. People are talking about fragmentation, 
>which doesn't even become an issue until MTU size is exceeded in IP 
>(1500 bytes). Cell broadcast survives on the order of a hundred bytes."
>

<snip>

>Did the research come up with any input as to what was enough, 
>before people ignored it. People are talking about fragmentation, 
>which doesn't even become an issue until MTU size is exceeded in IP 
>(1500 bytes). Cell broadcast survives on the order of a hundred bytes.
>

---

From: "DALY, BRIAN K" <[email-masked]>
Date: Fri, 16 Sep 2011 18:22:33 +0000

Hard to keep track, but I think it might have been Keith that made that comment?

--------
Brian K. Daly

Rethink Possible

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, September 16, 2011 11:21 AM
To: DALY, BRIAN K; DRAGE, Keith (Keith); Art Botterell; [email-masked]
Subject: Re: [atoca] Alert signing

Brian

James

<snip>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 16 Sep 2011 13:34:06 -0500

<snip>

>Bottom line - people don't want to have to scroll through multiple 
>screens to read information - they want to be told "to the point" 
>with a minimal amount of scrolling through pages of text.

was that study performed before the evidence of the far greater 
penetration of smart devices than everyone expected?

>The input obtained from that study is one of the drivers that 
>limited a CMAS alert message to 90 characters (although there was 
>technical consideration as well), PLUS there was research that 
>stated to be most effective the alert message needs to contain the 
>following information, in this order:
>

(following up to the above question)

In other words, I have no problems sending or receiving the 5 bullets 
you have listed. What I have a problem with is only receiving that 
information. I know "thems fightin` words" with you, but the lowest 
common denominator theory or plan doesn't have to limit all of what's sent.

For example, depending on when this study was done (and almost 
regardless of when this study was done - unless in the last 6 
months), no one would have predicted that so many iPhones, Androids 
or Blackberry phones would be on the market and fully utilized for 
the rich media capabilities. In other words, having all 5 bullets on 
the first page of a multipage alert is great. The subsequent pages 
are thrown away by those devices that don't understand them - but 
they are tabbed windows to those that can. For example, I'd like to:

  - take your #3 and have it paint a map of where the shelters are.
  - take your #2 and show a video of the affected area.

These require URLs and some geolocation to be utilized, because "in 
your area" might be the city of NY, or Chicago or LA - each of which 
might not be completely affected by whatever is happening. No need to 
panic folks that don't need to be panicked, right?

Just some thoughts...

James

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 18 Sep 2011 23:09:30 +0300

Hi Carl, 

I just read this message and it relates to the message I sent today to the mailing list about scope of the work. 

GeoRSS is, if I understood it correctly, a mechanism for using alerts in RSS feeds. While this is a perfectly fine idea it falls into the category of what some people consider "out of scope for this group and has been specified, implemented and deployed already". So, there isn't a need to specify it again. Right? 

I have to look into GeoSMS to understand what it does but I guess from the name that it uses SMS as a way to carry information. In the IETF we focus on IP, as you know. 

On Sep 15, 2011, at 6:45 PM, Carl Reed wrote:

> Sorry, I just want to understand why CAP only. In the OGC community, current efforts have typically abstracted the alert service architecture such that the publish/subscribe function for alerts is independent of the alert format. In this way, CAP, SMS, GeoSMS, GeoRSS, or whatever format is required or desired can be accommodated.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 18 Sep 2011 23:10:34 +0300

How would this work for a broadcast message delivery (in comparison to a point-to-point message exchange where one could imagine things like Path MTU discovery etc.)?

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 18 Sep 2011 23:16:39 +0300

Hi Keith, 

I am looking forward to see this text input. 

I am curious how this text would look like and provides guidance on how to fit a CAP message in an UDP datagram. 

I also don't think that the charter of the group ever envisioned that the group would specify how the content of the alert can be restricted to a specific size. 

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 18 Sep 2011 23:27:50 +0300

Hi James, 

There are various reasons for the increased message size, namely 

* cryptographic protection (xml digital signature in case of CAP, the original discussion starter)
* encoding (XML encoding, JSON, ASN.1, etc.)
* information being sent overall (this is what many discussed here in this thread although it is not really up to us to decide anyway)
* multi-media content (we had spoken about this during the charter discussion)
* content in different languages 

With a point-to-point delivery the size of the message is not necessarily a problem (at least not from the transport protocol with respect to fragmentation) since one could easily make use of TCP, for example. An RSS feed does this and so does SIP/XMPP. 

The problem with these protocols is that they are not suitable for mass delivery in the sense we discussed it and how many had anticipated these things to work (namely as a broadcast/multicast UDP datagram sent to end hosts). 

Brian had provided us in the past already with information about the design decisions for CMAS and that's simply the decisions they had taken. The requirements to support devices available in the field and different technology puts constraints on their solution. I believe we should accept that. 

Ciao
Hannes

On Sep 16, 2011, at 9:34 PM, James M. Polk wrote:

> was that study performed before the evidence of the far greater penetration of smart devices than everyone expected?
> 
> 
> In other words, I have no problems sending or receiving the 5 bullets you have listed. What I have a problem with is only receiving that information. I know "thems fightin` words" with you, but the lowest common denominator theory or plan doesn't have to limit all of what's sent.
> 
> For example, depending on when this study was done (and almost regardless of when this study was done - unless in the last 6 months), no one would have predicted that so many iPhones, Androids or Blackberry phones would be on the market and fully utilized for the rich media capabilities. In other words, having all 5 bullets on the first page of a multipage alert is great. The subsequent pages are thrown away by those devices that don't understand them - but they are tabbed windows to those that can. For example, I'd like to:
> 
> These require URLs and some geolocation to be utilized, because "in your area" might be the city of NY, or Chicago or LA - each of which might not be completely affected by whatever is happening. No need to panic folks that don't need to be panicked, right?
> 
> Just some thoughts...
> 
> James
> 
> 
>> --------
>> Brian K. Daly

---

From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 18 Sep 2011 19:41:00 -0400

In the case where broadcast is being used, I would expect the alert server to have a pretty good idea of things like the MTU to endpoints.  

Even when that's not true, the server can make a pretty good guess as to the MTU.  E.g., if you look at some of the ideas for "stateless TCP" [1], the server just chops the message into 512-octet chunks and fires them off to the client.  (ISTM that 1024 would probably be small enough.)  Obviously, the more you fragment, the more risk there is that a lost datagram will render an endpoint unable to receive the alert.  But you can overcome that with retransmission (especially if you buffer received fragments -- though there's DOS risk there).  Or, if you want to get really fancy, with an erasure code [2].

To address one particular scenario where an alert server doesn't know the MTU: If a broadcast recipient relays an alert to further downstream recipients, it seems like it assumes responsibility for re-assembly of the alert and proper fragmentation for downstream endpoints.

--Richard

[1] <http://iepg.org/2009-11-ietf76/2009-11-08-stateless.pdf>
[2] <http://en.wikipedia.org/wiki/Erasure_code>