Subject: Re: [earlywarning] global CAP community

From: "Brian Rosen" <[email-masked]>
Date: Fri, 1 May 2009 10:13:37 -0400

Thanks for the reference to X.1303.

I think we need to confine our discussions on this list to "authority to
citizen" (although that wording is changing), and our use of CAP will be
limited to that context.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tony Rutkowski
Sent: Thursday, April 30, 2009 5:54 PM
To: [email-masked]
Subject: [earlywarning] global CAP community

Hi all,

Glad to see this working group get under way.  There is a large and diverse
global CAP community.

Because the "authority" is often (but not always as Art notes) government in
nature, or implemented pursuant to government requirements, the
intergovernmental - industry organizations like ITU-T have been
significantly involved.  At the domestic level, legislation like the US WARN
Act also affect these implementations.

I have attached the ITU-T X-series version of CAP 1.1.  It's a copy of the
OASIS version, plus a translation into ASN.1 (for those who love that syntax
or find it useful for compact applications).  It's also what most
governmental authorities will reference in most jurisdictions.

As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay
involved in this IETF WG and keep you apprised of things happening there and
contribute to your work.

Because CAP is flexible, extensible, and ubiquitous, it's worth considering
its application in diverse contexts.  For example, what would others think
of using CAP in conjunction with dispersing cybersecurity forensics (think
IODEF or CAPEX) or vulnerability
information?   If so, what is there some larger ontology that needs
to be developed?

cheers,
tony

--
Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270

---

From: "Carl Reed" <[email-masked]>
Date: Fri, 1 May 2009 09:59:31 -0600

Tony -

I worked CAP 1.0 and 1.1 standardization. My sense is that the CAP community wishes to adhere to the "The design should not place undue burdens of complexity on technical implementers." Whenever I tried to have additional functionality added, such as the ability to express a coordinate reference system other than WGS 84 2d, there was considerable pushback. So, my guidance on this topic would be to consider how to enhance CAP for use in other domains, I would suggest you look to what is currently being done in OASIS in terms of defining CAP profiles. 

As to extensibility of CAP, that is another issue. This is one of the topics being considered as part of the CAP 2.0 discussions. We are hoping, for example, to enhance the geo information model and schema elements of CAP to be consistent with GeoRSS and PIDF-LO geodetic. 

Regards

Carl Reed
CTO
OGC

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, May 01, 2009 8:13 AM
Subject: Re: [earlywarning] global CAP community

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 01 May 2009 12:02:03 -0400

I wonder if it might ultimately be a good idea to deprecate the word 
"authority" for the purposes of these technical discussions, in favor of 
a more neutral term.  "Alert originator" or something like that.  The 
only characteristics of the authority/originator that this group needs 
to care about are

(1) That it's the source of alerts that the system distributes

(2) That it will need to be able to authenticate to the distribution 
system (in order to support the application of authorization policies)

Whether the entity that fulfills those criteria is a government, a 
corporation, or my Twitter feed really isn't important, as long as the 
appropriate credentials and policies have been set up.

--Richard

---

From: "Carl Reed" <[email-masked]>
Date: Fri, 1 May 2009 10:28:06 -0600

For what it is worth, what Richard is suggesting is the approach that many 
in OGC implementation community use for providing alerts. Typically, the 
alerting infrastructure, such as being developed for numerous applications 
in Europe and Asia, supports multiple alert payload encoding. The user (gov, 
citizen, whatever) subscribes to alerts in the desired/required payload 
encoding . Authentication is a key aspect of this process: Anyone 
subscribing to receive alerts is authenticated in terms of what content can 
actually distributed to them.

As to the alert originator, we have the same issue: more and more alerts are 
originating from sensor networks. The sensor networks are integrated into 
some larger information processing network (earthquake, tsunami, wildfire, 
etc). These "originator" systems may be government, private, NGO, research/ 
University or some partnership.

Cheers

Carl

----- Original Message ----- 
From: "Richard Barnes" <[email-masked]>
To: "Brian Rosen" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 01, 2009 10:02 AM
Subject: Re: [earlywarning] global CAP community

>"authority" for the purposes of these technical discussions, in favor of a 
>more neutral term.  "Alert originator" or something like that.  The only 
>characteristics of the authority/originator that this group needs to care 
>about are
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 01 May 2009 14:26:30 -0400

Carl,

Is there a common term in the OGC for this entity, one that this group 
could re-use?  Did I actually guess right with "alert orginator"??

--Richard

Carl Reed wrote:
> For what it is worth, what Richard is suggesting is the approach that 
> many in OGC implementation community use for providing alerts. 
> Typically, the alerting infrastructure, such as being developed for 
> numerous applications in Europe and Asia, supports multiple alert 
> payload encoding. The user (gov, citizen, whatever) subscribes to alerts 
> in the desired/required payload encoding . Authentication is a key 
> aspect of this process: Anyone subscribing to receive alerts is 
> authenticated in terms of what content can actually distributed to them.
> 
> As to the alert originator, we have the same issue: more and more alerts 
> are originating from sensor networks. The sensor networks are integrated 
> into some larger information processing network (earthquake, tsunami, 
> wildfire, etc). These "originator" systems may be government, private, 
> NGO, research/ University or some partnership.
> 
> Cheers
> 
> Carl
> 
> 
> ----- Original Message ----- From: "Richard Barnes" <[email-masked]>
>> "authority" for the purposes of these technical discussions, in favor 
>> of a more neutral term.  "Alert originator" or something like that.  
>> The only characteristics of the authority/originator that this group 
>> needs to care about are
>>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 May 2009 13:34:56 -0500

At 11:02 AM 5/1/2009, Richard Barnes wrote:
>"authority" for the purposes of these technical discussions, in 
>favor of a more neutral term.  "Alert originator" or something like 
>that.  The only characteristics of the authority/originator that 
>this group needs to care about are
>
>corporation, or my Twitter feed really isn't important,

I reeeeally disagree with this statement. You, Richard (and I'm only 
picking on you because you brought it up) might not care, but many 
will care the differences here.

I only want to get a Presidential alert (one of CAP's alert levels) 
from an authorized source. I don't want to get it from my company, 
your company or anyone's twitter. I want it coming from an 
"authorized" source.  Anything less than that is person to person for 
all I care, and I dont' have a good means of validating that source, 
if it's opened up to be "from anybody" using twitter.

>as long as the appropriate credentials and policies have been set up.

how exactly is twitter going to provide these credentials?

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 May 2009 13:40:10 -0500

At 11:28 AM 5/1/2009, Carl Reed wrote:
>For what it is worth, what Richard is suggesting is the approach 
>that many in OGC implementation community use for providing alerts. 
>payload encoding. The user (gov, citizen, whatever) subscribes to 
>alerts in the desired/required payload encoding . Authentication is 
>a key aspect of this process: Anyone subscribing to receive alerts 
>is authenticated in terms of what content can actually distributed to them.
>
>As to the alert originator, we have the same issue: more and more 
>alerts are originating from sensor networks. The sensor networks are 
>integrated into some larger information processing network 
>(earthquake, tsunami, wildfire, etc). These "originator" systems may 
>be government, private, NGO, research/ University or some partnership.

Carl -- then they need to be classified as such, do they not?

How exactly does one trust the originator of a message?

Any alerts from earthquake, tsunami, wildfire, etc... can be 
architected up to an "authority", then that authority can distribute 
the information to anyone they allow to subscribe to the service (or 
just freely give it out).

I believe this is begging for someone who wants to pull a prank in, 
say a London tunnel, of alerting a large number of people about a false event.

That would be almost as damaging as an actual event, given the panic 
that would ensue.

>>I wonder if it might ultimately be a good idea to deprecate the 
>>word "authority" for the purposes of these technical discussions, 
>>in favor of a more neutral term.  "Alert originator" or something 
>>like that.  The only characteristics of the authority/originator 
>>that this group needs to care about are
>>
>>(2) That it will need to be able to authenticate to the 
>>distribution system (in order to support the application of 
>>authorization policies)
>>
>>corporation, or my Twitter feed really isn't important, as long as 
>>the appropriate credentials and policies have been set up.
>>
>>--Richard
>>
>>
>>
>>Brian Rosen wrote:

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 May 2009 13:45:49 -0500

At 01:26 PM 5/1/2009, Richard Barnes wrote:
>Carl,
>
>Is there a common term in the OGC for this entity, one that this 
>group could re-use?  Did I actually guess right with "alert orginator"??

"alert-originator-to-who"?

We just lost the latter half of this too, because "citizen" just went 
out the window given Carl's description of

         "The sensor networks are integrated into some larger information
         processing network (earthquake, tsunami, wildfire, etc)."

Because the sensor information likely won't be consumer very often by 
"citizens", but by government agencies, and research labs.

We're moving closer towards "point-to-point-alerts", and losing the 
concept of "authority" without the ability to verify who is the 
source of the information, which I consider really dangerous - 
because it will be misused.

James

>>alerts are originating from sensor networks. The sensor networks 
>>are integrated into some larger information processing network 
>>(earthquake, tsunami, wildfire, etc). These "originator" systems 
>>may be government, private, NGO, research/ University or some partnership.
>>Cheers
>>Carl
>>
>>>in favor of a more neutral term.  "Alert originator" or something like that.
>>>The only characteristics of the authority/originator that this 
>>>group needs to care about are
>>>

---

From: ken carlberg <[email-masked]>
Date: Fri, 1 May 2009 15:01:13 -0400

> "alert-originator-to-who"?

Might I suggest "Authorized-originator to subscriber".  I agree with  
the notion (if not the exact wording) brought up by Richard that it  
would be constructive to move away from the term "authority" since  
that term gravitates most folks to a 1-to-1 association with  
government, and that's not always the case with systems out there  
today.  And while I thought it was implied in Richard's posting, the  
originator needs to have some measure of authority in originating a  
message to the alerting system as James is stating in his posting.

The subscriber can be the direct consumer (you or me) or a proxy such  
as when my local cable company in the U.S. receives feeds from the  
Emergency Alert System and forwards it one additional downstream level  
to its subscribers.

-ken

---

From: "Carl Reed" <[email-masked]>
Date: Fri, 1 May 2009 13:04:03 -0600

James -

I do not think I said that the citizen is out of the loop. The end user of 
these systems is often the citizen and not another government agency. For 
example, in the Indonesian Tsunami early warning system, ocean sensors 
provide measurements into a processing environment that uses the sensor 
measurements along with other data to model tsunami propagation for a given 
event. This information is then used to generate the appropriate alerts to 
the appropriate entities in the appropriate geographic region(s) including 
citizens. My point is that sensors themselves may not generate an alert but 
instead feed a workflow that does generate alerts.

Also, the measurements generated many sensor networks are now directly 
accessible to citizens - such as traffic alert data.

Sorry for any confusion.

Carl

----- Original Message ----- 
From: "James M. Polk" <[email-masked]>
To: "Richard Barnes" <[email-masked]>; "Carl Reed" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, May 01, 2009 12:45 PM
Subject: Re: [earlywarning] global CAP community

> We just lost the latter half of this too, because "citizen" just went out 
> the window given Carl's description of
>
> concept of "authority" without the ability to verify who is the source of 
> the information, which I consider really dangerous - because it will be 
> misused.
>
> James
>
>
>>--Richard
>>
>>
>>
>>Carl Reed wrote:
>>>many in OGC implementation community use for providing alerts. Typically, 
>>>the alerting infrastructure, such as being developed for numerous 
>>>applications in Europe and Asia, supports multiple alert payload 
>>>encoding. The user (gov, citizen, whatever) subscribes to alerts in the 
>>>desired/required payload encoding . Authentication is a key aspect of 
>>>this process: Anyone subscribing to receive alerts is authenticated in 
>>>terms of what content can actually distributed to them.
>>>>a more neutral term.  "Alert originator" or something like that.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 01 May 2009 15:07:01 -0400

James,

Protocols don't know about citizenship.  At the protocol level, alert 
consumers are just message consumers with special requirements 
(immediacy, geographic targeting, etc).

Point-to-point messaging is indeed our starting point: The point of this 
working group is to take existing IETF messaging protocols (e.g., SIP) 
and extend them to meet the requirements for delivering emergency messages:
-- Strong, E2E authentication and authorization of alert originators
-- E2E authentication and integrity-protection for alerts
-- Delivery based on geolocation (and other constraints)
-- Priority and preemption (?)
-- Scalability (e.g., using multicast)

--Richard

James M. Polk wrote:
> concept of "authority" without the ability to verify who is the source 
> of the information, which I consider really dangerous - because it will 
> be misused.
> 
> James
> 
> 
>> --Richard
>>
>>
>>
>> Carl Reed wrote:
>>> alerts in the desired/required payload encoding . Authentication is a 
>>> key aspect of this process: Anyone subscribing to receive alerts is 
>>>> that.

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 01 May 2009 15:38:24 -0400

> message to the alerting system as James is stating in his posting.
This seems like a good direction.  The term "authority-to-citizen" is
somewhat ETSI EMTEL centric and implies implementations that
are generally obligatory under regulatory provisions in Europe.  Your
focus seems definitely much broader.

--toont

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 May 2009 14:55:39 -0500

Carl

The sensors, as you've described them (which is nearly how I would 
have too BTW) feed into a system that then informs citizens, it is 
not the citizens that inform other citizens about alerts within the 
Indonesian Tsunami early warning system, is it?

I get that the sensors feed their information into a collector (i.e., 
server) that then informs the masses. This isn't citizen to citizen 
ala Twitter. Nothing here prevents communications ala Twitter, but it 
isn't how we're going to define ATOCA's operational model, is it?

I see the model you say last below as how I describe it, sensors to a 
server, which has some level of authority (even if that authority is 
the local university - at least there are supposed to be experts 
running that system). Citizens then access what the server puts out 
(i.e., they subscribe to it, to get the info. If they don't 
subscribe, they don't get the info).

James

At 02:04 PM 5/1/2009, Carl Reed wrote:
>James -
>
>I do not think I said that the citizen is out of the loop. The end 
>user of these systems is often the citizen and not another 
>government agency. For example, in the Indonesian Tsunami early 
>warning system, ocean sensors provide measurements into a processing 
>environment that uses the sensor measurements along with other data 
>to model tsunami propagation for a given event. This information is 
>then used to generate the appropriate alerts to the appropriate 
>entities in the appropriate geographic region(s) including citizens. 
>My point is that sensors themselves may not generate an alert but 
>Also, the measurements generated many sensor networks are now 
>directly accessible to citizens - such as traffic alert data.
>
>Sorry for any confusion.
>
>Carl
>
>----- Original Message ----- From: "James M. Polk" <[email-masked]>
>To: "Richard Barnes" <[email-masked]>; "Carl Reed" <[email-masked]>
>>We just lost the latter half of this too, because "citizen" just 
>>went out the window given Carl's description of
>>
>>Because the sensor information likely won't be consumer very often 
>>by "citizens", but by government agencies, and research labs.
>>
>>>>that many in OGC implementation community use for providing 
>>>>alerts. Typically, the alerting infrastructure, such as being 
>>>>developed for numerous applications in Europe and Asia, supports 
>>>>multiple alert payload encoding. The user (gov, citizen, 
>>>>whatever) subscribes to alerts in the desired/required payload 
>>>>subscribing to receive alerts is authenticated in terms of what 
>>>>content can actually distributed to them.
>>>>>word "authority" for the purposes of these technical 
>>>>>discussions, in favor of a more neutral term.  "Alert 
>>>>>originator" or something like that.
>>>>>Whether the entity that fulfills those criteria is a government, 
>>>>>a corporation, or my Twitter feed really isn't important, as 
>>>>>long as the appropriate credentials and policies have been set up.
>>>>>
>>>>>--Richard
>>>>>
>>>>>
>>>>>
>>>>>Brian Rosen wrote:

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 May 2009 15:00:53 -0500

At 02:07 PM 5/1/2009, Richard Barnes wrote:
>James,
>
>Protocols don't know about citizenship.  At the protocol level, 
>alert consumers are just message consumers with special requirements 

Richard

there is also the concept of accessibility (citizens might not have 
access, which is built into the protocol as "access can be limited to few").

There is also the concept of "this comes from an authoritative 
source" - though that's not strictly in the protocol, it can be 
explicit or implicit in who can distribute the info.

Allowing this to run in the wild will only cause great harm, and send 
all governments into a frenzy with having to deal with our wildness 
in lack of scope.

>Point-to-point messaging is indeed our starting point: The point of 
>this working group is to take existing IETF messaging protocols 
>(e.g., SIP) and extend them to meet the requirements for delivering 
>emergency messages:

this makes me wonder how ordinary citizens will meet your scoping 
point #1 above?

Is anything on Twitter verifyable?

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 1 May 2009 16:21:06 -0400

> (immediacy, geographic targeting, etc).
Perhaps "resident". My "citizenship" and my "residence" are thousands of 
miles apart.

Janet

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 1 May 2009 16:23:14 -0400

> -- Priority and preemption (?)

What are you planning to preempt?

Janet

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 May 2009 16:19:31 -0500

>What are you planning to preempt?

I was wondering the same thing, as priority seems natural (wrt server 
resources, and indication of the type of message), but this is never 
going to be a stream, so I don't think we'll likely have 1 message 
preempt another (but we may delay one message relative to another).

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 01 May 2009 17:36:54 -0400

> preempt another (but we may delay one message relative to another). 
In many cases, this will be dictated by national regulatory
authorities or legislative requirements. In the U.S., for
example, under the WARN Act, presidential messages
preempt all others. In addition, when the FCC or other
authorities specify certain NS/EP conditions, preemption
actually occurs.

--tony

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 May 2009 17:52:05 -0500

>authorities specify certain NS/EP conditions, preemption

hmmmm.... NS/EP means preemption....?

I'll let Janet comment on that - since she works for NCS (who run GETS).

I'm curious about this line too

         "In the U.S., for example, under the WARN Act,
         presidential messages preempt all others."

The WARN act isn't about real-time communications, so why is there 
any need for preemption? Why not just store-and-forward (i.e., delay) 
the messages of lower priority than the president's?

James

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 1 May 2009 21:53:18 -0400

> I'll let Janet comment on that - since she works for NCS (who run GETS).

IFF the war powers act were invoked, then preemption would be permitted.

But, in situations not triggering the war powers act- which is the "real 
world" situation we actually deal with- the Service Providers will not 
permit preemption of voice communication.  This is not because there is an 
actual stated ban on preemption, but because of the concern that a person 
whose (life or death) call was preempted could sue under the terms of the 
Telecommunications Act, and they would have no defense.

None of the deployed NS/EP programs I am aware of (including the ones I am 
not supposed to talk about) use preemption.  Queueing, alternate routing, 
exemption from network controls, exemption from load shedding- they are 
all part of the NS/EP programs.  But not preemption.

But that is beside the point.

In "earlywarning" we are talking about "messages", not "calls" or even 
"sessions". What is it that you are going to "preempt"?  Sure, if it is a 
voice message you are sending, you could interrupt the message to send 
some other message.  But then you would just resend the original message 
later.  Delayed, but not preempted.
 Janet

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 2 May 2009 12:14:59 +0300

I agree with Richard. 

In my presentation during the BOF I have already used different terminology
based on off-line conversations with Carl and Art about this topic. 

Please find our presentation here: 
http://www.tschofenig.priv.at/atoca/architecture.ppt

I suggest to generalize the subject a bit and propose the following
modifications:
 
* replace "early warning" with "Exigent Communications"
* use terminology from draft-crocker-email-arch and modify it slightly, see
Slide 5 in our slide set

I would like to make these changes to
draft-norreys-ecrit-authority2individuals-requirements ASAP. 

Ciao
Hannes

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Richard Barnes
>Sent: 01 May, 2009 19:02
>To: Brian Rosen
>Cc: [email-masked]
>I wonder if it might ultimately be a good idea to deprecate 
>the word "authority" for the purposes of these technical 
>originator" or something like that.  The only characteristics 
>of the authority/originator that this group needs to care about are
>
>Whether the entity that fulfills those criteria is a 
>government, a corporation, or my Twitter feed really isn't 
>important, as long as the appropriate credentials and policies 
>have been set up.
>
>--Richard
>
>
>
>Brian Rosen wrote:
>> I think we need to confine our discussions on this list to 
>"authority 
>> to citizen" (although that wording is changing), and our use of CAP 
>> will be limited to that context.
>> 
>> Brian
>> 
>> Glad to see this working group get under way.  There is a large and 
>> diverse global CAP community.
>> 
>> Because the "authority" is often (but not always as Art notes) 
>> government in nature, or implemented pursuant to government 
>> requirements, the intergovernmental - industry organizations like 
>> ITU-T have been significantly involved.  At the domestic level, 
>> legislation like the US WARN Act also affect these implementations.
>> 
>> I have attached the ITU-T X-series version of CAP 1.1.  It's 
>a copy of 
>> the OASIS version, plus a translation into ASN.1 (for those who love 
>> that syntax or find it useful for compact applications).  It's also 
>> what most governmental authorities will reference in most 
>jurisdictions.
>> 
>> involved in this IETF WG and keep you apprised of things happening 
>> there and contribute to your work.
>> 
>> Because CAP is flexible, extensible, and ubiquitous, it's worth 
>> considering its application in diverse contexts.  For example, what 
>> would others think of using CAP in conjunction with dispersing 
>> cybersecurity forensics (think IODEF or CAPEX) or vulnerability

---

From: Janet P Gunn <[email-masked]>
Date: Sat, 2 May 2009 06:26:13 -0400

> * replace "early warning" with "Exigent Communications"

I think that is a bad idea.

How many people here know PRECISELY what "exigent" means without looking 
it up.

You need a term that has wider comprehension.

Janet

---

From: Art Botterell <[email-masked]>
Date: Sat, 2 May 2009 08:51:10 -0700

On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote:

> How many people here know PRECISELY what "exigent" means without  
> looking it up.
>

Unfortunately, not many folks know precisely what "early warning"  
means either, although many assume they do until you press them for  
specifics.

It seems like the current terms of reference are heavily loaded with  
emotional and cultural baggage.  That's the problem with the word  
"authority"... it has several different senses and ultimately involves  
a subjective, or at least individual, interpretation of who and what  
constitutes authority (Government? Church? Academe? Culture?)

"Warning" is likewise a fairly subtle notion when you really start to  
unpack it.  In my particular public warning system we define it  
narrowly as "information about imminent threats to human life or  
health"... but other practitioners frame it differently.  The word  
also spans the distinct domains of attention-management and  
information-sharing (is it a warning if folks are already aware of the  
subject matter?)

So I'm wondering... might it be more productive to specify the  
particular observable characteristics we're concerned about (latency,  
reliability, verifiability, etc.) we're hoping to achieve rather than  
sloshing around in non-technical semantics?

I get the sense that at least some of us are primarily concerned with  
the use of SIP, and although I have no personal investment in that  
particular approach, at least it sounds like the frame for a tractable  
technical problem.

- Art

---

From: ken carlberg <[email-masked]>
Date: Sun, 3 May 2009 09:48:21 -0400

On May 1, 2009, at 5:19 PM, James M. Polk wrote:

> I was wondering the same thing, as priority seems natural (wrt  
> server resources, and indication of the type of message), but this  
> is never going to be a stream, so I don't think we'll likely have 1  
> message preempt another (but we may delay one message relative to  
> another).

I would agree on the general case, but some constrained environments  
would require preemption, with possible subsequent transmission of the  
preempted session.  as an example, any alerting system that includes  
meteor scatter communication links definitely needs preemption, and  
one could probably extend this to a number of LMR systems as well.

the key thing to keep in mind is that some alerting systems may be  
disjoint in the variation of communication mechanisms being deployed,  
and in turn, that radioactive word of preemption may not be  
ubiquitously applied.

-ken

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 08:45:05 -0400

Right now, I'd prefer that we assume that messages are short enough that the
complexity of preemption is worse that the delay of transmission.  I
wouldn't mind priority if there was a queue of alerts to be sent, but the
notion that we preempt is, I think, not worth it.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of ken carlberg
Sent: Sunday, May 03, 2009 9:48 AM
To: James M. Polk
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

-ken

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 04 May 2009 13:49:12 -0500

Brian (all)

I'm really confused

wrt the messages and preemption -- what are we talking about here?

Is this real-time streaming or not?

If not, the lower priority messages get delayed until the higher 
priority messages clear the queue, right?

Imagine a network where there are only early warning messages 
(putting aside the discussion about "early warning" perhaps not being 
the best phrase at the moment - that's a separate discussion), if 
each messages is marked with a DSCP, and the appropriate DSCP for the 
type of message (i.e., presidential gets the highest, whatever's next 
- gets the next highest DSCP, and so on) -- how *can't* this work?

Each message is exactly one messages long -- unless we're talking 
about something like MSRP -- which no one has brought up yet -- and 
I'd like to hear the justification for IM in this case, and not a 
subscription based approach.

Given that each message is only 1 (ONE) message long, and knowing the 
physics of only being able to transmit one message at a time from any 
one interface, how can't a scheduler and a queue solve this (as long 
as what gets put into the queue is put into the right queue to begin with)?

In IM (i.e., MESSAGEs), as well as NOTIFYs - everything behind the 
one message being transmitted is delayed until it comes up in the 
queue.  There is never a reason for a deletion of a message (unless 
there is a timer associated within a message - in which case, this 
timer getting to ZERO isn't a preemption event, it's a starvation event).

James

---

From: ken carlberg <[email-masked]>
Date: Mon, 4 May 2009 15:25:14 -0400

James,

My working assumption was that this effort was not constrained to real- 
time streaming, but I'll support Brian's theme of adding a more narrow  
scope if folks choose to just deal with only that type.  As for  
preemption, ages ago I worked on a system, for one arm of the  
government, that *required* preemption as an option because parts of  
the system could include bandwidth constrained environments.  And the  
problem was accentuated by  notifications that could extend for  
minutes at a time, which was considered an unacceptable period of time  
to wait.  So that raises another question, which part of the  
government (or which government with its individual rules/regulations)  
are we talking about?

As for modern times, picture crawlers in use today that send out long  
messages (eg, the list of school and event snow related closings in  
large cities) that run for several minutes.  I'd imagine that it would  
be desirable to preempt that "session"  by another authenticated  
source that had a more important message to distribute than in waiting  
for the first message to drain out.

I'm also quite sympathetic to Brian's desire to limit the scope.  On  
the other hand, I'm concerned that we'll be continually bogged down  
with comments/positions relating to specific laws and regulations from  
governments if that remains the sole target of the source of alerts.   
In a sense, we have already experienced that in the past few days.

-ken

On May 4, 2009, at 2:49 PM, James M. Polk wrote:

> (putting aside the discussion about "early warning" perhaps not  
> being the best phrase at the moment - that's a separate discussion),  
> if each messages is marked with a DSCP, and the appropriate DSCP for  
> the type of message (i.e., presidential gets the highest, whatever's  
> next - gets the next highest DSCP, and so on) -- how *can't* this  
> work?
>
> Given that each message is only 1 (ONE) message long, and knowing  
> the physics of only being able to transmit one message at a time  
> from any one interface, how can't a scheduler and a queue solve this  
> (as long as what gets put into the queue is put into the right queue  
> to begin with)?
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 15:41:17 -0400

I think we're sending an alert, not a media stream.  The alert can have a
URI in it that may point to a media stream, but it's not in the alert
itself.

I'm hoping the size of the alert is small enough that preemption is not
worthwhile.  We'll see.

Brian

-----Original Message-----
From: ken carlberg [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 3:25 PM
To: James M. Polk
Cc: Brian Rosen; [email-masked]
Subject: Re: [earlywarning] global CAP community

James,

-ken

On May 4, 2009, at 2:49 PM, James M. Polk wrote:

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

>> ]

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 4 May 2009 14:53:27 -0500

This suggestion seems very reasonable to me.

I'm also assuming that you can send out a multi-minute crawl line without 
taking multiple minutes to do that, but that doesn't matter if the alert 
doesn't carry much data itself...

Thanks,

Spencer

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 04 May 2009 15:06:00 -0500

>I'm hoping the size of the alert is small enough that preemption is not

then we are in agreement here, as I too believe the CAP message will 
have a URI to any scrolling message on the UI (i.e. TV - to Ken's point)

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 04 May 2009 15:08:51 -0500

At 02:53 PM 5/4/2009, Spencer Dawkins wrote:
>I'm also assuming that you can send out a multi-minute crawl line 
>without taking multiple minutes to do that, but that doesn't matter 
>if the alert doesn't carry much data itself...

taking this out some more, I believe it is perfectly reasonable to 
have any scrolling message interrupted for a higher priority message, 
but that's not the CAP message getting preempted.  I further believe 
that once this more important message is done, the scrolling message 
that was there will resume (or at least have the option of resuming).

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 4 May 2009 15:12:56 -0500

Hi, James,

Yes, and thank you for saying this explictly... I had assumed what you said 
but didn't include that in my note.

Spencer

> taking this out some more, I believe it is perfectly reasonable to have 
> any scrolling message interrupted for a higher priority message, but 
> that's not the CAP message getting preempted.  I further believe that once 
> this more important message is done, the scrolling message that was there 
> will resume (or at least have the option of resuming).

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 9 May 2009 12:40:54 +0300

Hi all, 

alerts can contain all sorts of content (see CAP and GeoRSS) that points to
more information in different formats (audio, video, text, html, etc.). This
is something we do not really have to worry about since this work is done
already elsewhere. 

An example?
See http://www.geowebguru.com/articles/108-technical-overview-georss 

Ciao
Hannes
 
>[mailto:[email-masked]] On Behalf Of James M. Polk
>Sent: 04 May, 2009 23:06
>To: Brian Rosen; 'ken carlberg'
>>I think we're sending an alert, not a media stream.  The 
>alert can have 
>>a URI in it that may point to a media stream, but it's not in 
>the alert 
>>itself.
>>
>then we are in agreement here, as I too believe the CAP 
>message will have a URI to any scrolling message on the UI 
>(i.e. TV - to Ken's point)
>
>
>>Brian
>>
>> >> Right now, I'd prefer that we assume that messages are 
>short enough
>> >> that the