Subject: [earlywarning] emergency alert implementations
From: "Stark, Barbara" <[email-masked]>
To: <[email-masked]>
Date: Fri, 15 May 2009 14:51:10 -0400
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <earlywarning.ietf.org>

Thought y'all might be interested in this news article. By the way, my
local school system now uses Twitter to provide alerts.
Barbara

http://blogs.wsj.com/digits/2009/05/11/new-york-citys-emergency-text-ale
rts-in-the-spotlight/ 

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Henning Schulzrinne <[email-masked]>, Brian Rosen <[email-masked]>
Date: Thu, 14 May 2009 19:06:41 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

Maybe we could address this a different way round.

In draft-norreys-ecrit-authority2individuals-requirements-02.txt we have various figures showing the entities involved. Between which entities do we see various security activities (authorisation, integrity protection, encryption) occurring. 

I rather get the impression that Brian is arguing for the closed federation figure and therefore no authorisation between "Warning Notification Provider" and "Warning Notification Aggregator".

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Henning 
> Schulzrinne
> Sent: Monday, May 04, 2009 3:43 PM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: [earlywarning] Depricate "Authority" - was : 
> global CAPcommunity
> 
> Why is authorization easier for government? A school, 
> university or company generally knows all of its students and 
> employees, and can thus easily, relatively speaking, provide 
> their public key to them ahead of time, so that an alert can 
> be trivially verified as to its authenticity. For that, it 
> doesn't matter whether the organization is run by a 
> government (say, the Port Authority of NY&NJ) or a private 
> entity (Columbia University). (I guess sending alerts to GM 
> and Citibank would still be ok...). I'm ignoring the problem 
> of university/ company visitors, as most existing alert 
> systems don't deal with them, and reasonably rely on the 
> "regulars" to tell them what's going on.
> 
> The case of alerting is much harder for entities who need to 
> reach everyone who happens to be in their territory, such as 
> a county. They have to distribute some cryptographic material 
> to everybody, including visitors, without knowing who they are.
> 
> Thus, the operative difference seem much more of a "closed" 
> vs. "open"  
> membership, rather than whether the entity operating the 
> alert has a seal and calls it itself county or state government.
> 
> Henning
> 
> On May 4, 2009, at 10:01 AM, Brian Rosen wrote:
> 
> > Finally, a meaty subject; terminology really doesn't get us 
> very far.  
> > This is important; really narrowing scope.
> >
> > Let's take a look at how far do we want to go:
> >
> > National Government with major warning - impending attack Regional 
> > Government with life threatening event - Tornado or flash 
> flood Local 
> > Government with life threatening event - hazmat spill Local 
> Government 
> > with important, but not threatening event - major traffic 
> tieup Local 
> > Government with useful event - public school closing State 
> Government 
> > College with life threatening event - school shooting 
> Private College 
> > with life threatening event - school shooting Private elementary 
> > school with useful event  - school closing Enterprise with life 
> > threatening event - hazmat spill Enterprise with useful event - 
> > building closing due to weather
> >
> > It's clear to me that all of these are very useful alerts.  The 
> > question becomes, which of these should be in scope for the first 
> > charter?
> >
> > It seems to me that the issue of authorization is the 
> biggie here, and 
> > if we started out limiting to government, even local government, it 
> > gets a lot easier. Once you allow a non-government entity to notify 
> > using the
> > mechanism, we make the authorization decision much more 
> difficult.   
> > I don't
> > see an in-between way to slice the above list other than 
> government/ 
> > non government unless you say that the government can 
> authorize other 
> > entities and you are relying on that authorization.
> >
> > I think the wishes of the networks that are transporting the alerts 
> > come into play; they would want a bright line on authorization.
> >
> > I suspect that once you have an authorized entity that can 
> create an 
> > alert, what it gets to use that authorization for is a less 
> > interesting (to the
> > IETF) issue.  If you can issue alerts, you can issue any kind of 
> > alert.
> >
> > Brian
> >
> >
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:[email-masked]]
> > Sent: Monday, May 04, 2009 9:20 AM
> > To: Brian Rosen
> > Cc: 'ken carlberg'; 'Art Botterell'; [email-masked]
> > Subject: Re: [earlywarning] Depricate "Authority" - was : global 
> > CAPcommunity
> >
> > This distinction is unlikely to work in the US, at least, 
> as there are 
> > many quasi-governmental entities. Classical example: some of the 
> > largest scale notification systems today are deployed by college 
> > campuses, particularly after the Virginia Tech shooting. 
> There is no 
> > technical reason why such function should be available to state 
> > colleges and universities, but not to private institutions 
> (which, in 
> > the US, are in no way governed by the Federal or state government).
> > Same is true for large school districts, which can be either run by 
> > the city/county or, say, the Catholic Church.
> >
> > Henning
> >
> > On May 4, 2009, at 8:42 AM, Brian Rosen wrote:
> >
> >> As with any IETF effort, limiting scope is useful to get 
> progress in 
> >> a reasonable time.  With this effort, we have tried to limit the 
> >> scope of "authority".  It would be okay with me if we did 
> limit it to 
> >> government initially, although eventually I suspect we will expand 
> >> it.
> >>
> >> I am very comfortable leaving the terminology as is: authority to 
> >> citizen.
> >> I think we can reasonably explain that authority is initially 
> >> government (national, state/province/region/, and local).  We can 
> >> reasonably explain that citizen includes residents and visitors.
> >>
> >> I'd like to keep the discussion more on the scope than on the 
> >> terminology.
> >>
> >> Brian
> >>
> >> -----Original Message-----
> >> From: [email-masked] 
> >> [mailto:[email-masked]
> >> ]
> >> On Behalf Of ken carlberg
> >> Sent: Sunday, May 03, 2009 9:14 AM
> >> To: Art Botterell
> >> Cc: [email-masked]
> >> Subject: Re: [earlywarning] Depricate "Authority" - was : global 
> >> CAPcommunity
> >>
> >> a good point.  What the previous poster failed to elaborate on is 
> >> that other SDO's like the ITU have made the association of 
> authority 
> >> == government, and given us terms and classification of 
> communication 
> >> models comprising:
> >>
> >> citizen-to-citizen, citizen-to-authority, 
> authority-to-authority, and 
> >> authority-to-citizen
> >>
> >> which is why we are seeing this terminology creep up on this list.
> >> one could take the approach that the IETF will go its own 
> way, but I 
> >> think it will be more constructive to acknowledge what's already 
> >> gained traction and explore other terms.  and in this 
> specific case, 
> >> something other than "authority" if we want to expand the target 
> >> model.
> >>
> >> -ken
> >>
> >>
> >>
> >> On May 2, 2009, at 3:47 PM, Art Botterell wrote:
> >>
> >>> If so, why not say "government"?
> >>>
> >>> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, 
> ATTLABS wrote:
> >>>
> >>>> Authority is government
> >>>>
> >>>> ----- Original Message -----
> >>>> From: [email-masked] 
> <[email-masked]>
> >>>> To: [email-masked] <[email-masked]>
> >>>> Sent: Sat May 02 11:51:10 2009
> >>>> Subject: Re: [earlywarning] Depricate "Authority" - was : global 
> >>>> CAPcommunity
> >>>>
> >>>> 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.
> >>>>>
> >>>>> You need a term that has wider comprehension.
> >>>>
> >>>> 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
> >>>> _______________________________________________
> >>>> earlywarning mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/earlywarning
> >>>
> >>> _______________________________________________
> >>> earlywarning mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/earlywarning
> >>
> >> _______________________________________________
> >> earlywarning mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/earlywarning
> >>
> >> _______________________________________________
> >> earlywarning mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/earlywarning
> >>
> >
> >
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 

From: Art Botterell <[email-masked]>
To: [email-masked]
Date: Mon, 11 May 2009 07:39:56 -0700
Subject: Re: [earlywarning] Some further scoping issues

On May 11, 2009, at 5/11/09 5:55 AM, Brian Rosen wrote:
> I think if you limit the notifiers, the security is more tractable.

Seems like the challenge here may be more attribution than  
authorization.  If folks can know with confidence who sent a message,  
they can decide for themselves who they trust.  If they can't, the  
door is open to spam.

Reliable identity is a prerequisite to access control anyway, but it  
might actually make "prior restraint" mechanisms unnecessary... thus  
allowing the technology to sidestep the complex political question of  
"authority."

- Art

From: "Brian Rosen" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>, <[email-masked]>
Date: Mon, 11 May 2009 08:55:27 -0400
Subject: Re: [earlywarning] Some further scoping issues

I don't think we can do this.

The biggest problem in this whole effort is the security.  This mechanism
could, in theory, send alerts to billions of devices.  That's a VERY
tempting target.  This means that security model is perhaps the single most
important aspect of the task.  I think if you limit the notifiers, the
security is more tractable.

I agree that the kind of alert doesn't really matter for our work.

I think the rendering issues are big, and will occupy a significant part of
our time.  The range of devices is large, but the size of the message is,
hopefully, small.  How we design the system so that it is feasible to render
on a wide variety of devices in a wide variety of locations (language issues
for example), is a hard problem.  In some prior efforts, this was deemed to
hard, and too much liability, and the solution was to require the notifier
(or an agent operated by a government agency) to cast the notification in a
single simple text string of limited length, thus not requiring the devices
or downstream networks to do any rendering.  While I would assume we would
not choose such a solution, it indicates that the problem is pretty big, and
needs some imagination on our part to make sure that what we send is simply
renderable on the devices.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:earlywarning-
> [email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Saturday, May 09, 2009 5:29 AM
> To: 'Hannes Tschofenig'; [email-masked]
> Subject: Re: [earlywarning] Some further scoping issues
> 
> Hi all,
> 
> I did not receive a lot of feedback on the important aspect of scoping
> the
> work in this upcoming group.
> 
> Please take a briefly look at it.
> 
> Based on the mailing list discussion in a different thread I would also
> like
> to add:
> 
> * Are we really interested in focusing on a particular security
> deployment
> model? I don't think so.
> For example, alerts that are sent from a particular entity, such as a
> government, only. Technically this does not make a lot of sense and is
> too
> far into the deployment choices of certain entities.
> 
> * We also do not make specific restrictions regarding the type of
> alerts
> (e.g., alerts about a tornado vs. early school closing) as the semantic
> largely comes from the content of the alert -- something we will not
> define
> anyway. There may be some technical requirements that some folks might
> want
> to discuss, such as delivery mechanisms to deal with potential
> congestion
> and so on. That's fine for me.
> 
> * Excluding discussions about the type of device and the available user
> interface also seems to make sense to me. This appears to be more
> issues
> with a specific architecture that, as stated below, would not be in our
> scope.
> 
> Ciao
> Hannes
> 
> PS: Another pragmatic way to scope the work is to focus on the things
> that
> have actually been proposed already rather than speculating about
> things.
> From what I can tell there isn't a huge amount of work being proposed
> in
> terms of documents. When new proposals come along then one can make a
> judgement again to determine whether this is something the group is
> interested in.
> 
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> >Sent: 02 May, 2009 12:50
> >To: [email-masked]
> >Subject: [earlywarning] Some further scoping issues
> >
> >For the future work in this group I furthermore suggest that
> >
> >* we do not focus our efforts on defining an architecture used
> >for distributing of alert messages (like we did it in ECRIT
> >with the PhoneBCP/Framework document). Instead, we develop
> >building blocks (like conveying CAP in SIP). I believe we will
> >run into lots of problems with the different usages, different
> >solutions that have been specified elsewhere already, etc.
> >
> >* we do not pick a single alert document format (as a
> >mandatory-to-implement), like CAP or GeoRSS, but instead give
> >those who deploy these mechanisms freedom.
> >
> >* we do not define our own alert document format (because
> >there are other formats available already).
> >
> >We can always decide later to document ways how people use our stuff.
> >
> >Ciao
> >Hannes
> >
> >_______________________________________________
> >earlywarning mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/earlywarning
> >
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: "Hannes Tschofenig" <[email-masked]>
To: "'James M. Polk'" <[email-masked]>, "'Brian Rosen'" <[email-masked]>, "'ken carlberg'" <[email-masked]>
Date: Sat, 9 May 2009 12:40:54 +0300
Cc: [email-masked]
Subject: [earlywarning] Additional Information in an Alert -- was RE: global CAP community

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
 
>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of James M. Polk
>Sent: 04 May, 2009 23:06
>To: Brian Rosen; 'ken carlberg'
>Cc: [email-masked]
>Subject: Re: [earlywarning] global CAP community
>
>At 02:41 PM 5/4/2009, Brian Rosen wrote:
>>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.
>
>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
>>
>>-----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,
>>
>>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:
>>
>> > 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
>> >
>> > At 07:45 AM 5/4/2009, Brian Rosen wrote:
>> >> 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
>> >>
>> >>
>> >> On May 1, 2009, at 5:19 PM, James M. Polk wrote:
>> >>
>> >> >> 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).
>> >>
>> >> 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
>> >>
>> >> _______________________________________________
>> >> earlywarning mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/earlywarning
>> >
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'Hannes Tschofenig'" <[email-masked]>, <[email-masked]>
Date: Sat, 9 May 2009 12:29:11 +0300
Subject: Re: [earlywarning] Some further scoping issues

Hi all, 

I did not receive a lot of feedback on the important aspect of scoping the
work in this upcoming group. 

Please take a briefly look at it. 

Based on the mailing list discussion in a different thread I would also like
to add: 

* Are we really interested in focusing on a particular security deployment
model? I don't think so. 
For example, alerts that are sent from a particular entity, such as a
government, only. Technically this does not make a lot of sense and is too
far into the deployment choices of certain entities.

* We also do not make specific restrictions regarding the type of alerts
(e.g., alerts about a tornado vs. early school closing) as the semantic
largely comes from the content of the alert -- something we will not define
anyway. There may be some technical requirements that some folks might want
to discuss, such as delivery mechanisms to deal with potential congestion
and so on. That's fine for me. 

* Excluding discussions about the type of device and the available user
interface also seems to make sense to me. This appears to be more issues
with a specific architecture that, as stated below, would not be in our
scope. 
 
Ciao
Hannes 

PS: Another pragmatic way to scope the work is to focus on the things that
have actually been proposed already rather than speculating about things.
>From what I can tell there isn't a huge amount of work being proposed in
terms of documents. When new proposals come along then one can make a
judgement again to determine whether this is something the group is
interested in. 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>Sent: 02 May, 2009 12:50
>To: [email-masked]
>Subject: [earlywarning] Some further scoping issues
>
>For the future work in this group I furthermore suggest that 
>
>* we do not focus our efforts on defining an architecture used 
>for distributing of alert messages (like we did it in ECRIT 
>with the PhoneBCP/Framework document). Instead, we develop 
>building blocks (like conveying CAP in SIP). I believe we will 
>run into lots of problems with the different usages, different 
>solutions that have been specified elsewhere already, etc. 
>
>* we do not pick a single alert document format (as a 
>mandatory-to-implement), like CAP or GeoRSS, but instead give 
>those who deploy these mechanisms freedom. 
>
>* we do not define our own alert document format (because 
>there are other formats available already). 
>
>We can always decide later to document ways how people use our stuff. 
>
>Ciao
>Hannes
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning
>

From: "Hannes Tschofenig" <[email-masked]>
To: "'James M. Polk'" <[email-masked]>, "'Thomson, Martin'" <[email-masked]>, <[email-masked]>, "'Art Botterell'" <[email-masked]>
Date: Sat, 9 May 2009 12:25:48 +0300
Cc: [email-masked]
Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity

Hi James, 

I took the terminology from the email architecture. 
I don't think we need to always add authorized in front of it as this would
hopefully be the secure communication is the normal case.

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of James M. Polk
>Sent: 04 May, 2009 22:25
>To: Thomson, Martin; [email-masked]; Art Botterell
>Cc: [email-masked]
>Subject: Re: [earlywarning] Deprecate "Authority" - was : 
>global CAPcommunity
>
>At 08:24 PM 5/3/2009, Thomson, Martin wrote:
>>I worry that this discussion has lost focus.  Are we talking about 
>>terms for use in relation to a protocol, or terms in relation to 
>>problem statement and naming (marketing)?  They can be separated.
>>
>>The terms that Hannes proposes (Author and Recipient) would be quite 
>>suitable for use in describing a protocol and architecture.
>
>Martin (and Hannes) - my concern about these two terms is they 
>normally do not appear together.
>
>Say, down the road, when we have "author" realized, do we 
>classify an "authorized author". Many will find that not 
>rolling off the tongue well.
>
>"Recipient" is fine with me, but it is more often partnered 
>with "sender" or "originator".
>
>Meaning, down the road, we can have "authorized senders" or 
>"authorized originators".
>
>these word pairs appear to me to be more clear.
>
>At the end of the day, having a terminology section to the 
>beginning requirements doc (or just a terminology doc) should 
>suffice wrt any confusion, I should think.
>
>James
>
>
>>Is this really the venue for deciding who applies this protocol 
>>solution?  Not that I'm suggesting we design in a vacuum, but we each 
>>have a fair idea of what the goals are; and I truly don't think that 
>>there are major differences of opinion.  The subjective definition of 
>>"authority" need not be a barrier to progress.
>>
>>I'm happy with marketing with vague terms like "authority-to-citizen" 
>>or "early warning" and having separate terms in protocol 
>land.  That's 
>>been successful in the past; the abstraction allows for a little 
>>flexibility in interpretation.  That flexibility is sometimes useful.
>>
>>I tend to agree with Art that we can spend a lot of time on the 
>>non-technical stuff.  Maybe abstraction offers us a way to 
>make process 
>>on the technical side while we "slosh around" on the fuzzy issues.
>>
>>--Martin
>>
>>
>>--------------------------------------------------------------
>---------
>>------------------------- This message is for the designated 
>recipient 
>>only and may contain privileged, proprietary, or otherwise private 
>>information.
>>If you have received it in error, please notify the sender 
>immediately 
>>and delete the original.  Any unauthorized use of this email is 
>>prohibited.
>>--------------------------------------------------------------
>---------
>>-------------------------
>>[mf2]
>>_______________________________________________
>>earlywarning mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/earlywarning
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning
>

Content-class: urn:content-classes:message
Date: Mon, 4 May 2009 17:51:11 -0500
From: "Thomson, Martin" <[email-masked]>
To: "James M. Polk" <[email-masked]>, <[email-masked]>, "Art Botterell" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity

From: Henning Schulzrinne <[email-masked]>
To: Brian Rosen <[email-masked]>
Date: Mon, 4 May 2009 17:35:55 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

On May 4, 2009, at 4:00 PM, Brian Rosen wrote:

> We haven't figured any of this out.  Henning proposed something that  
> sounded
> like preloaded keys.  I don't think that works.

I was talking about a specific scenario, namely where the notifier  
knows the destination. Students in a university and employees in a  
company are examples - they already routinely download keying material  
for various other reasons, such as browsing internal web pages. You  
don't even need to preload keying material. This isn't that much  
harder than signing S/MIME email, after all, as long as I have a pre- 
configured entry that says "messages signed by [email-masked] are  
genuine". It's not that hard for the signer to get a personal public/ 
private key pair from an existing CA.

This would not work for the "stepping off a plane" case, although a  
very similar mechanism might: get the legitimate alerter(s) via LoST.  
As long as the CA is known, i.e., is one of the ones built into the  
device, this is then again like S/MIME, except easier, since the  
number of parties that need to get public/private keypairs is probably  
a few thousand, not hundreds of millions. No new infrastructure is  
needed, either.

We shouldn't make this harder than it is.

Henning

From: "Brian Rosen" <[email-masked]>
To: "'Ted Hardie'" <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>, "'ken carlberg'" <[email-masked]>
Date: Mon, 4 May 2009 14:56:26 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] charter text

I don't care how we get there.

The notion of the system "tracking" my daughter doesn't bother me as long as
all we're getting out of that is the same alerts.  
We're not really tracking, we're replicating an alert that went to her.
"Send me alerts from this place" isn't really right, but it might be another
useful thing to have.  

Brian

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 1:59 PM
To: Brian Rosen; 'Henning Schulzrinne'; 'ken carlberg'
Cc: [email-masked]
Subject: charter text

At 10:48 AM -0700 5/4/09, Brian Rosen wrote:
>It would help to go back to the charter language.
<snip>

>Another class of recipients that are in scope of the work are explicit
>opt-in subscriptions which ask for alerts that are sent to an associated
>party.  An example of such a subscription would be "send me alerts which
are
>sent too my daughter based on her location". 

This seems to imply that the system must track whether or not
an alert was sent to your daughter (and hence her opt-in state),
rather than simply saying "send me alerts for the follow area,
in which I am not currently present".  It is then up to you to designate
the area.  This is simple.  The "track your daughter" system is hard,
and it has serious privacy consequences.

If you simply want your daughter's user agent to echo alerts to you,
I think that is also possible--but it would be separate from this system
entirely and its opt-in characteristics are clearly different..

		regards,
			Ted

From: "Spencer Dawkins" <[email-masked]>
To: "Brian Rosen" <[email-masked]>, "'ken carlberg'" <[email-masked]>, "James M. Polk" <[email-masked]>
Date: Mon, 4 May 2009 15:12:56 -0500
Subject: Re: [earlywarning] global CAP community

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). 

Date: Mon, 04 May 2009 15:08:51 -0500
To: "Spencer Dawkins" <[email-masked]>, "Brian Rosen" <[email-masked]>, "'ken carlberg'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

At 02:53 PM 5/4/2009, Spencer Dawkins wrote:
>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...

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).

>Thanks,
>
>Spencer
>
>
>>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,
>>
>>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:
>>
>>>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
>>>
>>>At 07:45 AM 5/4/2009, Brian Rosen wrote:
>>>>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
>>>>
>>>>
>>>>On May 1, 2009, at 5:19 PM, James M. Polk wrote:
>>>>
>>>> >> 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).
>>>>
>>>>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
>>>>
>>>>_______________________________________________
>>>>earlywarning mailing list
>>>>[email-masked]
>>>>https://www.ietf.org/mailman/listinfo/earlywarning
>>
>>_______________________________________________
>>earlywarning mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/earlywarning
>

Date: Mon, 04 May 2009 15:06:00 -0500
To: "Brian Rosen" <[email-masked]>, "'ken carlberg'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

At 02:41 PM 5/4/2009, Brian Rosen wrote:
>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.

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
>
>-----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,
>
>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:
>
> > 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
> >
> > At 07:45 AM 5/4/2009, Brian Rosen wrote:
> >> 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
> >>
> >>
> >> On May 1, 2009, at 5:19 PM, James M. Polk wrote:
> >>
> >> >> 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).
> >>
> >> 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
> >>
> >> _______________________________________________
> >> earlywarning mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/earlywarning
> >

From: "Brian Rosen" <[email-masked]>
To: "'Spencer Dawkins'" <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>, "'ken carlberg'" <[email-masked]>
Date: Mon, 4 May 2009 16:00:15 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

We haven't figured any of this out.  Henning proposed something that sounded
like preloaded keys.  I don't think that works.  I think you need some kind
of discovery process.  Just saying "government" doesn't really solve any of
this, buy it MIGHT simplify things.

Brian

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 3:51 PM
To: Brian Rosen; 'Henning Schulzrinne'; 'ken carlberg'
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

If the following isn't helpful, please ignore, but ...

> While I think having every notifier's public key is a nice solution to an
> authentication problem, it might be hard to arrange.  Among other things,
> you have to be able to get off a plane and get alerts from local
> authorities.  Right now, I don't want to discuss solutions, but charter
> language, and I'd rather have narrow scope.
>
> Brian

I am sympathetic to the notion of solving a limited problem set, but I'm 
having a difficult time trying to understand the security model here - when 
you get off a plane, and you don't have the local notifier's public key, and

you get an alert, how do you know you can believe it?

I may be misunderstanding, but part of this discussion sounds like we might 
rely on the fact that all notifiers are governments as a way of ensuring 
that you can trust the alerts you get, and I'm not sure what your mobile 
device is supposed to do when you turn it on - when you get an alert, how do

you know it comes from a government?

You guys may have all this well in hand, and Spencer just needs to catch up,

but I'm concerned that we're talking about deferring security considerations

in order to have a smaller scope for the work, and that might not be the 
right tradeoff to make...

Thanks,

Spencer 

Date: Mon, 04 May 2009 14:25:03 -0500
To: "Thomson, Martin" <[email-masked]>, <[email-masked]>,  "Art Botterell" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity

At 08:24 PM 5/3/2009, Thomson, Martin wrote:
>I worry that this discussion has lost focus.  Are we talking about 
>terms for use in relation to a protocol, or terms in relation to 
>problem statement and naming (marketing)?  They can be separated.
>
>The terms that Hannes proposes (Author and Recipient) would be quite 
>suitable for use in describing a protocol and architecture.

Martin (and Hannes) - my concern about these two terms is they 
normally do not appear together.

Say, down the road, when we have "author" realized, do we classify an 
"authorized author". Many will find that not rolling off the tongue well.

"Recipient" is fine with me, but it is more often partnered with 
"sender" or "originator".

Meaning, down the road, we can have "authorized senders" or 
"authorized originators".

these word pairs appear to me to be more clear.

At the end of the day, having a terminology section to the beginning 
requirements doc (or just a terminology doc) should suffice wrt any 
confusion, I should think.

James

>Is this really the venue for deciding who applies this protocol 
>solution?  Not that I'm suggesting we design in a vacuum, but we 
>each have a fair idea of what the goals are; and I truly don't think 
>that there are major differences of opinion.  The subjective 
>definition of "authority" need not be a barrier to progress.
>
>I'm happy with marketing with vague terms like 
>"authority-to-citizen" or "early warning" and having separate terms 
>in protocol land.  That's been successful in the past; the 
>abstraction allows for a little flexibility in interpretation.  That 
>flexibility is sometimes useful.
>
>I tend to agree with Art that we can spend a lot of time on the 
>non-technical stuff.  Maybe abstraction offers us a way to make 
>process on the technical side while we "slosh around" on the fuzzy issues.
>
>--Martin
>
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original.  Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

From: "Spencer Dawkins" <[email-masked]>
To: "Brian Rosen" <[email-masked]>, "'ken carlberg'" <[email-masked]>, "'James M. Polk'" <[email-masked]>
Date: Mon, 4 May 2009 14:53:27 -0500
Subject: Re: [earlywarning] global CAP community

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

>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,
>
> 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:
>
>> 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
>>
>> At 07:45 AM 5/4/2009, Brian Rosen wrote:
>>> 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
>>>
>>>
>>> On May 1, 2009, at 5:19 PM, James M. Polk wrote:
>>>
>>> >> 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).
>>>
>>> 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
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 

From: "Spencer Dawkins" <[email-masked]>
To: "Brian Rosen" <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>, "'ken carlberg'" <[email-masked]>
Date: Mon, 4 May 2009 14:50:55 -0500
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

If the following isn't helpful, please ignore, but ...

> While I think having every notifier's public key is a nice solution to an
> authentication problem, it might be hard to arrange.  Among other things,
> you have to be able to get off a plane and get alerts from local
> authorities.  Right now, I don't want to discuss solutions, but charter
> language, and I'd rather have narrow scope.
>
> Brian

I am sympathetic to the notion of solving a limited problem set, but I'm 
having a difficult time trying to understand the security model here - when 
you get off a plane, and you don't have the local notifier's public key, and 
you get an alert, how do you know you can believe it?

I may be misunderstanding, but part of this discussion sounds like we might 
rely on the fact that all notifiers are governments as a way of ensuring 
that you can trust the alerts you get, and I'm not sure what your mobile 
device is supposed to do when you turn it on - when you get an alert, how do 
you know it comes from a government?

You guys may have all this well in hand, and Spencer just needs to catch up, 
but I'm concerned that we're talking about deferring security considerations 
in order to have a smaller scope for the work, and that might not be the 
right tradeoff to make...

Thanks,

Spencer 

From: "Brian Rosen" <[email-masked]>
To: "'ken carlberg'" <[email-masked]>, "'James M. Polk'" <[email-masked]>
Date: Mon, 4 May 2009 15:41:17 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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,

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:

> 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
>
> At 07:45 AM 5/4/2009, Brian Rosen wrote:
>> 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
>>
>>
>> On May 1, 2009, at 5:19 PM, James M. Polk wrote:
>>
>> >> 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).
>>
>> 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
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>

From: ken carlberg <[email-masked]>
To: "James M. Polk" <[email-masked]>
Date: Mon, 4 May 2009 15:25:14 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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:

> 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
>
> At 07:45 AM 5/4/2009, Brian Rosen wrote:
>> 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
>>
>>
>> On May 1, 2009, at 5:19 PM, James M. Polk wrote:
>>
>> >> 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).
>>
>> 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
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>

 <0da801c9ccd5$a950 6b50$fbf141f0$@net>
 <CE237C46-2CD5-44EF-B920-2381 [email-masked]>
 <FF69847B-4F46-4E11-B62B-A74 [email-masked]>
 <0dc501c9cce0$896fb5b0 $9c4f2110$@net>
 <p06240801c624dcd093df@[10.227.68 .132]>
 <0ddb01c9ccea$08db67a0$1a9236e0$@net> |Date: Mon, 4 May 2009 12:20:38 -0700|To: B rian Rosen <[email-masked]>,
         "'Henning Schulzrinne'"
	<[email-masked] ia.edu>,
        "'ken carlberg'"  <[email-masked]>|From: Ted Hardie <hardie@q ualcomm.com>|Subject: RE: charter text|CC: "early [email-masked]" <[email-masked]>|Content-Type:  text/plain; charset="us-ascii"|X-IronPort-AV:  E=McAfee;i="5300,2777,5605"; a="17756253"; bh=ZE0WWQ06WQK4KDWxmlTq1OrX3NNvrEOBdBH1hcJmUQA=; b=bh4OGYteJabrYSesTjqiad16TggdPXNMz80P89enz0DJb048l5YqYBoL JkBSC328TOfGGOOgZfZPms+A3msd+ITWGCavrl7KdW7XP3eg5X4lwqWte 10VhT2AzHnxAtvTZ3tJ7vX83iFdwVdE9ikz7fqANyXc3vjvYqlRQV3DUk I=;
Date: Mon, 4 May 2009 12:20:38 -0700
To: Brian Rosen <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>, "'ken carlberg'" <[email-masked]>
From: Ted Hardie <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] charter text

At 11:56 AM -0700 5/4/09, Brian Rosen wrote:
>I don't care how we get there.
>
>The notion of the system "tracking" my daughter doesn't bother me as long as
>all we're getting out of that is the same alerts. 
>We're not really tracking, we're replicating an alert that went to her.

Let's say your daughter failed to opt-in to the Tsunami warning because
she was on the U.S. East Coast, and they are incredibly rare.  You, being the dad,
opt-in globally to all warnings.  You will get a warning of the Tsunami when
the Canary Island's volcano slides, even if your daughter did not opt-in. 
Why would you make a mandatory tie of your choices about what warnings to get
to the ones your daughter made?   [Why is this choice being put into the charter,
in other words?]

As for you not worrying about the system tracking your daughter, I'm
glad to hear it, but I don't think we can ignore the problem in the charter. 
If you tie the warnings to an individual, you have to transition
the warnings as the individual moves around, which gives you a way of
tracking the individual.  If you suddenly see Kansas Tornado watches,
when you are expecting your daughter to be Ohio, you are getting information
the daughter may not have wanted you to have.

>"Send me alerts from this place" isn't really right, but it might be another
>useful thing to have. 

I think it is the right choice, honestly.  If your daughter wants to share her
location with you, she can do that with standard presence mechanisms.  You
can subscribe and eliminate alert requests based on that without forcing the
back-end systems to track the individual and what alerts are being received.

			regards,
				Ted

>Brian
>
>-----Original Message-----
>From: Ted Hardie [mailto:[email-masked]]
>Sent: Monday, May 04, 2009 1:59 PM
>To: Brian Rosen; 'Henning Schulzrinne'; 'ken carlberg'
>Cc: [email-masked]
>Subject: charter text
>
>At 10:48 AM -0700 5/4/09, Brian Rosen wrote:
>>It would help to go back to the charter language.
><snip>
>
>
>>Another class of recipients that are in scope of the work are explicit
>>opt-in subscriptions which ask for alerts that are sent to an associated
>>party.  An example of such a subscription would be "send me alerts which
>are
>>sent too my daughter based on her location".
>
>This seems to imply that the system must track whether or not
>an alert was sent to your daughter (and hence her opt-in state),
>rather than simply saying "send me alerts for the follow area,
>in which I am not currently present".  It is then up to you to designate
>the area.  This is simple.  The "track your daughter" system is hard,
>and it has serious privacy consequences.
>
>If you simply want your daughter's user agent to echo alerts to you,
>I think that is also possible--but it would be separate from this system
>entirely and its opt-in characteristics are clearly different..
>
>		regards,
>			Ted

Date: Mon, 04 May 2009 13:49:12 -0500
To: "Brian Rosen" <[email-masked]>, "'ken carlberg'" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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

At 07:45 AM 5/4/2009, Brian Rosen wrote:
>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
>
>
>On May 1, 2009, at 5:19 PM, James M. Polk wrote:
>
> >> 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).
>
>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
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

Date: Mon, 04 May 2009 13:00:19 -0500
To: [email-masked], Hannes Tschofenig <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Some further scoping issues

At 07:08 AM 5/2/2009, Tony Rutkowski wrote:
>These seem like good admonitions.  The broader scope will provide
>greater value to work, rather than attempting to deal a specific kind
>of implementation that gets into an already well-established regulatory
>domain.
>
>For those of you unfamiliar with the new FCC Part 10 rules specifying
>Commercial Mobile Alert System (CMAS) implementations, they are available at
>http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?cìfr&rgn=div5&view=text&nodeG:1.0.1.1.10&idnoG
>For U.S. implementations, note that 47 CFR Sec. 10.410 requires that
>"Presidential
>Alerts preempt all other Alert Messages."

Again, Tony, can you explain to many of us (if not to all of us) why 
a *message* needs to preempt (i.e., delete) another *message*, and 
not merely delay the non-presidential *message* until the 
presidential message is sent (i.e., hold in memory until there is no 
message of higher priority)?

I'm thinking we're talking past each other.

James

>ciao,
>--tony
> > For the future work in this group I furthermore suggest that
> >
> > * we do not focus our efforts on defining an architecture used for
> > distributing of alert messages (like we did it in ECRIT with the
> > PhoneBCP/Framework document). Instead, we develop building blocks (like
> > conveying CAP in SIP). I believe we will run into lots of problems with the
> > different usages, different solutions that have been specified elsewhere
> > already, etc.
> >
> > * we do not pick a single alert document format (as a
> > mandatory-to-implement), like CAP or GeoRSS, but instead give those who
> > deploy these mechanisms freedom.
> >
> > * we do not define our own alert document format (because there are other
> > formats available already).
> >
> > We can always decide later to document ways how people use our stuff.
> >
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

 <0da801c9ccd5$a950 6b50$fbf141f0$@net>
 <CE237C46-2CD5-44EF-B920-2381 [email-masked]>
 <FF69847B-4F46-4E11-B62B-A74 [email-masked]>
 <0dc501c9cce0$896fb5b0 $9c4f2110$@net>|Date: Mon, 4 May 2009 10:59:25  -0700|To: Brian Rosen <[email-masked]>,
         "'Henning Schulzrinne'"
 	<[email-masked]>,
        "' ken carlberg'" <[email-masked]>|From: Ted Ha rdie <[email-masked]>|Subject: charter text |CC: "[email-masked]" <[email-masked]> |Content-Type: text/plain; charset="us-ascii" |X-IronPort-AV: E=McAfee;i="5300,2777,5605";  a="17752301"; bh=ozGyxgXL2FNdOrGp0WSE6qXlDw2xw1c/b9QMbGWYNaw=; b=QSYrqzsMdoQFgukJjm+OeSioa41mMeAWeaw7aq9AA3CParBLtipHG6V3 W36mWMnyEs5b/M1Ci6KUhxDPZTNXUmMlYkKDbiloplXrhvObKkab6SCmO MSVC0LhBKYuNsfKQV7NzgdlgGXPy6sFhzYXj6DFbPz5VpbTMMHSYIcG4u o=;
Date: Mon, 4 May 2009 10:59:25 -0700
To: Brian Rosen <[email-masked]>, "'Henning Schulzrinne'" <[email-masked]>, "'ken carlberg'" <[email-masked]>
From: Ted Hardie <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [earlywarning] charter text

At 10:48 AM -0700 5/4/09, Brian Rosen wrote:
>It would help to go back to the charter language.
<snip>

>Another class of recipients that are in scope of the work are explicit
>opt-in subscriptions which ask for alerts that are sent to an associated
>party.  An example of such a subscription would be "send me alerts which are
>sent too my daughter based on her location". 

This seems to imply that the system must track whether or not
an alert was sent to your daughter (and hence her opt-in state),
rather than simply saying "send me alerts for the follow area,
in which I am not currently present".  It is then up to you to designate
the area.  This is simple.  The "track your daughter" system is hard,
and it has serious privacy consequences.

If you simply want your daughter's user agent to echo alerts to you,
I think that is also possible--but it would be separate from this system
entirely and its opt-in characteristics are clearly different..

		regards,
			Ted

From: "Brian Rosen" <[email-masked]>
To: "'Henning Schulzrinne'" <[email-masked]>, "'ken carlberg'" <[email-masked]>
Date: Mon, 4 May 2009 13:48:26 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

It would help to go back to the charter language.

The current proposal is (in part):
The class of alerts that are of interest to this working group are those
sent by authorized agents, primarily government agents.  The mechanisms that
result from this work may be applicable to a wider group of authorized
agents, but our current work is focused on emergency alerts from
governments.  Nevertheless, we desire to design this mechanism so that it
can be used by national, regional or local authorities and cover alerts for
impending Tsunamis which might affect most of a county down to a road
closing due to an automobile accident.  A critical element of the work are
the mechanisms that assure that only authorized agents can send alerts.

The recipients of these alerts are the wide range of devices connected to
the Internet and private IP networks which humans may have "at hand" to get
such events, as well as automatons who may take action based on the alerts.
This implies that the content of the alert contains some information which
is intended to be consumed by humans, and some which is intended to be
consumed by automatons.  Ideally, the alerts would contain, or refer to
media other than text media (cf audio and/or video), but the present work is
restricted to human readable text, which may be mechanically rendered by the
device in other forms (text to speech for example).   

Which devices should get alerts is primarily driven by location.  The first
set of recipients that must be catered for are those within the area
affected by the alert.  In many jurisdictions, there are regulations the
define whether recipients within the affected area have opt-in or opt-out
capability, but the protocols we will define will include both opt in and
opt out mechanisms.  This work builds on existing IETF geopriv location
work.   

Another class of recipients that are in scope of the work are explicit
opt-in subscriptions which ask for alerts that are sent to an associated
party.  An example of such a subscription would be "send me alerts which are
sent too my daughter based on her location".  

Both of these classes of recipients must operate at Internet scale, which is
one of the major challenges to the work.  Many tools have been developed
within the IETF to scale messaging, which will be exploited by this effort.
Examples include multicast.  The work must function on the networks we have,
however, and as such must take into account what is actually deployed, or
could reasonably be deployed.

--- end of proposed charter language ---

The charter, like any charter, attempts to limit scope, without presenting
cast in concrete solutions.  I think if we tried to handle too wide a range
of alert generators, we would have problems, both in getting a charter
approved and in getting the work done.  I too would LIKE to handle a wider
range of alert generators.  However, I think limiting scope to primarily
government agents is a helpful thing for the first charter.

Similarly, we have to handle the "broadcast" situation, and I don't mean the
word to imply multicast, but rather the notion that everyone gets the alert
if they are in the affected area, with the possibility that opt-out is not
allowed.  The mechanism by which we get the alert to all devices in the
affected area is TBD.

While I think having every notifier's public key is a nice solution to an
authentication problem, it might be hard to arrange.  Among other things,
you have to be able to get off a plane and get alerts from local
authorities.  Right now, I don't want to discuss solutions, but charter
language, and I'd rather have narrow scope.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 1:16 PM
To: ken carlberg
Cc: Brian Rosen; 'Art Botterell'; [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

My general concern is that we seem to be making general statements  
like "need government" that are driven by assumptions of the technical  
realization that we haven't really discussed. That seems like a  
somewhat unusual way to deal with engineering requirements and  
charters. The danger is that such statements then get applied to  
situations where they make little sense. If I subscribe, via sips, to  
a SIP event notification and have the notifiers public key, none of  
these considerations apply, for example.

Henning

On May 4, 2009, at 12:58 PM, ken carlberg wrote:

>
> On May 4, 2009, at 12:30 PM, Brian Rosen wrote:
>
>> Although I hope we end up with an opt-in subscription option, the  
>> minimum
>> required here is a broadcast.
>
> could you be a little more precise?  Does this means that if some  
> transit network prefers an application layer solution (let's say in  
> the form of application layer multicast -- ie, unicast-only  
> dissemination via a collection of servers) and chooses not to  
> support a network layer broadcast (or multicast) solution, they are  
> out of the picture?
>
>> That requires some entity to direct the
>> broadcast, based on location.  That in turn means that we have the  
>> network
>> operators, probably BOTH the access network (who knows the  
>> location) and the
>> alert application service provider.  The latter could be some  
>> public entity,
>> but I think it's unlikely.  More likely is that it's some SP that  
>> already
>> provides a service like texting.  It may be that the access network  
>> also
>> provides such a service, don't know, but I do hope we keep the access
>> network operator separate from that SP in our work.  Then, they  
>> could be
>> operated by the same entity or different entities.  The latter  
>> probably does
>> run some kind of SIP server/XMPP server or whatever we use for  
>> transport and
>> routing.
>>
>> Whomever it is, it will need to authenticate and authorize alert  
>> senders
>> independent of end devices authentication and authorization.  I think
>> starting with governments makes authentication (and authorization)  
>> easier.
>
> I'm with Henning in still wondering what is it technically (or even  
> policy) that makes authentication/authorization "easier" for  
> governments than some other non-government enitity/organization.
>
> -ken
>
>

From: Henning Schulzrinne <[email-masked]>
To: ken carlberg <[email-masked]>
Date: Mon, 4 May 2009 13:16:06 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

My general concern is that we seem to be making general statements  
like "need government" that are driven by assumptions of the technical  
realization that we haven't really discussed. That seems like a  
somewhat unusual way to deal with engineering requirements and  
charters. The danger is that such statements then get applied to  
situations where they make little sense. If I subscribe, via sips, to  
a SIP event notification and have the notifiers public key, none of  
these considerations apply, for example.

Henning

On May 4, 2009, at 12:58 PM, ken carlberg wrote:

>
> On May 4, 2009, at 12:30 PM, Brian Rosen wrote:
>
>> Although I hope we end up with an opt-in subscription option, the  
>> minimum
>> required here is a broadcast.
>
> could you be a little more precise?  Does this means that if some  
> transit network prefers an application layer solution (let's say in  
> the form of application layer multicast -- ie, unicast-only  
> dissemination via a collection of servers) and chooses not to  
> support a network layer broadcast (or multicast) solution, they are  
> out of the picture?
>
>> That requires some entity to direct the
>> broadcast, based on location.  That in turn means that we have the  
>> network
>> operators, probably BOTH the access network (who knows the  
>> location) and the
>> alert application service provider.  The latter could be some  
>> public entity,
>> but I think it's unlikely.  More likely is that it's some SP that  
>> already
>> provides a service like texting.  It may be that the access network  
>> also
>> provides such a service, don't know, but I do hope we keep the access
>> network operator separate from that SP in our work.  Then, they  
>> could be
>> operated by the same entity or different entities.  The latter  
>> probably does
>> run some kind of SIP server/XMPP server or whatever we use for  
>> transport and
>> routing.
>>
>> Whomever it is, it will need to authenticate and authorize alert  
>> senders
>> independent of end devices authentication and authorization.  I think
>> starting with governments makes authentication (and authorization)  
>> easier.
>
> I'm with Henning in still wondering what is it technically (or even  
> policy) that makes authentication/authorization "easier" for  
> governments than some other non-government enitity/organization.
>
> -ken
>
>

From: ken carlberg <[email-masked]>
To: "Brian Rosen" <[email-masked]>
Date: Mon, 4 May 2009 12:58:05 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

On May 4, 2009, at 12:30 PM, Brian Rosen wrote:

> Although I hope we end up with an opt-in subscription option, the  
> minimum
> required here is a broadcast.

could you be a little more precise?  Does this means that if some  
transit network prefers an application layer solution (let's say in  
the form of application layer multicast -- ie, unicast-only  
dissemination via a collection of servers) and chooses not to support  
a network layer broadcast (or multicast) solution, they are out of the  
picture?

> That requires some entity to direct the
> broadcast, based on location.  That in turn means that we have the  
> network
> operators, probably BOTH the access network (who knows the location)  
> and the
> alert application service provider.  The latter could be some public  
> entity,
> but I think it's unlikely.  More likely is that it's some SP that  
> already
> provides a service like texting.  It may be that the access network  
> also
> provides such a service, don't know, but I do hope we keep the access
> network operator separate from that SP in our work.  Then, they  
> could be
> operated by the same entity or different entities.  The latter  
> probably does
> run some kind of SIP server/XMPP server or whatever we use for  
> transport and
> routing.
>
> Whomever it is, it will need to authenticate and authorize alert  
> senders
> independent of end devices authentication and authorization.  I think
> starting with governments makes authentication (and authorization)  
> easier.

I'm with Henning in still wondering what is it technically (or even  
policy) that makes authentication/authorization "easier" for  
governments than some other non-government enitity/organization.

-ken

From: "Brian Rosen" <[email-masked]>
To: "'Henning Schulzrinne'" <[email-masked]>
Date: Mon, 4 May 2009 12:30:34 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

Although I hope we end up with an opt-in subscription option, the minimum
required here is a broadcast.  That requires some entity to direct the
broadcast, based on location.  That in turn means that we have the network
operators, probably BOTH the access network (who knows the location) and the
alert application service provider.  The latter could be some public entity,
but I think it's unlikely.  More likely is that it's some SP that already
provides a service like texting.  It may be that the access network also
provides such a service, don't know, but I do hope we keep the access
network operator separate from that SP in our work.  Then, they could be
operated by the same entity or different entities.  The latter probably does
run some kind of SIP server/XMPP server or whatever we use for transport and
routing.

Whomever it is, it will need to authenticate and authorize alert senders
independent of end devices authentication and authorization.  I think
starting with governments makes authentication (and authorization) easier.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 12:02 PM
To: Brian Rosen
Cc: 'ken carlberg'; 'Art Botterell'; [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

On May 4, 2009, at 11:04 AM, Brian Rosen wrote:

> I think it's easier for the networks which have to allow these  
> alerts (and
> treat them in some way we need to define) to know who the government
> entities are.

I'm not sure I understand what you mean by "networks". I can see that  
this might be possible for SMS, but how would a SIP MESSAGE-delivering  
server know that (or care)?

>
>
> That does bring up the issue that multiple entities need to  
> authenticate the
> alert source.  You are focused on the recipients, I mentioned the  
> networks.
> We don't know yet who might be operating the message routing  
> infrastructure,

Are you talking SIP proxies (or XMPP servers, etc.) or some other  
entity?

>
> but it certainly is likely the network operators

Why? This seems much more like an application-layer function to me,  
and just like ECRIT made the wise decision to separate application and  
network layer operators, we should do the same.

> and, as in ecrit, there is
> the access network and the "calling" (VoIP/IM/...) network/service  
> provider.
>
> Brian

From: Henning Schulzrinne <[email-masked]>
To: Brian Rosen <[email-masked]>
Date: Mon, 4 May 2009 12:01:38 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

On May 4, 2009, at 11:04 AM, Brian Rosen wrote:

> I think it's easier for the networks which have to allow these  
> alerts (and
> treat them in some way we need to define) to know who the government
> entities are.

I'm not sure I understand what you mean by "networks". I can see that  
this might be possible for SMS, but how would a SIP MESSAGE-delivering  
server know that (or care)?

>
>
> That does bring up the issue that multiple entities need to  
> authenticate the
> alert source.  You are focused on the recipients, I mentioned the  
> networks.
> We don't know yet who might be operating the message routing  
> infrastructure,

Are you talking SIP proxies (or XMPP servers, etc.) or some other  
entity?

>
> but it certainly is likely the network operators

Why? This seems much more like an application-layer function to me,  
and just like ECRIT made the wise decision to separate application and  
network layer operators, we should do the same.

> and, as in ecrit, there is
> the access network and the "calling" (VoIP/IM/...) network/service  
> provider.
>
> Brian

From: "Brian Rosen" <[email-masked]>
To: "'Henning Schulzrinne'" <[email-masked]>
Date: Mon, 4 May 2009 11:04:44 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

I think it's easier for the networks which have to allow these alerts (and
treat them in some way we need to define) to know who the government
entities are.

That does bring up the issue that multiple entities need to authenticate the
alert source.  You are focused on the recipients, I mentioned the networks.
We don't know yet who might be operating the message routing infrastructure,
but it certainly is likely the network operators and, as in ecrit, there is
the access network and the "calling" (VoIP/IM/...) network/service provider.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 10:43 AM
To: Brian Rosen
Cc: 'ken carlberg'; 'Art Botterell'; [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

Why is authorization easier for government? A school, university or  
company generally knows all of its students and employees, and can  
thus easily, relatively speaking, provide their public key to them  
ahead of time, so that an alert can be trivially verified as to its  
authenticity. For that, it doesn't matter whether the organization is  
run by a government (say, the Port Authority of NY&NJ) or a private  
entity (Columbia University). (I guess sending alerts to GM and  
Citibank would still be ok...). I'm ignoring the problem of university/ 
company visitors, as most existing alert systems don't deal with them,  
and reasonably rely on the "regulars" to tell them what's going on.

The case of alerting is much harder for entities who need to reach  
everyone who happens to be in their territory, such as a county. They  
have to distribute some cryptographic material to everybody, including  
visitors, without knowing who they are.

Thus, the operative difference seem much more of a "closed" vs. "open"  
membership, rather than whether the entity operating the alert has a  
seal and calls it itself county or state government.

Henning

On May 4, 2009, at 10:01 AM, Brian Rosen wrote:

> Finally, a meaty subject; terminology really doesn't get us very  
> far.  This
> is important; really narrowing scope.
>
> Let's take a look at how far do we want to go:
>
> National Government with major warning - impending attack
> Regional Government with life threatening event - Tornado or flash  
> flood
> Local Government with life threatening event - hazmat spill
> Local Government with important, but not threatening event - major  
> traffic
> tieup
> Local Government with useful event - public school closing
> State Government College with life threatening event - school shooting
> Private College with life threatening event - school shooting
> Private elementary school with useful event  - school closing
> Enterprise with life threatening event - hazmat spill
> Enterprise with useful event - building closing due to weather
>
> It's clear to me that all of these are very useful alerts.  The  
> question
> becomes, which of these should be in scope for the first charter?
>
> It seems to me that the issue of authorization is the biggie here,  
> and if we
> started out limiting to government, even local government, it gets a  
> lot
> easier. Once you allow a non-government entity to notify using the
> mechanism, we make the authorization decision much more difficult.   
> I don't
> see an in-between way to slice the above list other than government/ 
> non
> government unless you say that the government can authorize other  
> entities
> and you are relying on that authorization.
>
> I think the wishes of the networks that are transporting the alerts  
> come
> into play; they would want a bright line on authorization.
>
> I suspect that once you have an authorized entity that can create an  
> alert,
> what it gets to use that authorization for is a less interesting (to  
> the
> IETF) issue.  If you can issue alerts, you can issue any kind of  
> alert.
>
> Brian
>
>
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, May 04, 2009 9:20 AM
> To: Brian Rosen
> Cc: 'ken carlberg'; 'Art Botterell'; [email-masked]
> Subject: Re: [earlywarning] Depricate "Authority" - was : global
> CAPcommunity
>
> This distinction is unlikely to work in the US, at least, as there are
> many quasi-governmental entities. Classical example: some of the
> largest scale notification systems today are deployed by college
> campuses, particularly after the Virginia Tech shooting. There is no
> technical reason why such function should be available to state
> colleges and universities, but not to private institutions (which, in
> the US, are in no way governed by the Federal or state government).
> Same is true for large school districts, which can be either run by
> the city/county or, say, the Catholic Church.
>
> Henning
>
> On May 4, 2009, at 8:42 AM, Brian Rosen wrote:
>
>> As with any IETF effort, limiting scope is useful to get progress  
>> in a
>> reasonable time.  With this effort, we have tried to limit the scope
>> of
>> "authority".  It would be okay with me if we did limit it to
>> government
>> initially, although eventually I suspect we will expand it.
>>
>> I am very comfortable leaving the terminology as is: authority to
>> citizen.
>> I think we can reasonably explain that authority is initially
>> government
>> (national, state/province/region/, and local).  We can reasonably
>> explain
>> that citizen includes residents and visitors.
>>
>> I'd like to keep the discussion more on the scope than on the
>> terminology.
>>
>> Brian
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]
>> ]
>> On Behalf Of ken carlberg
>> Sent: Sunday, May 03, 2009 9:14 AM
>> To: Art Botterell
>> Cc: [email-masked]
>> Subject: Re: [earlywarning] Depricate "Authority" - was : global
>> CAPcommunity
>>
>> a good point.  What the previous poster failed to elaborate on is  
>> that
>> other SDO's like the ITU have made the association of authority =
>> government, and given us terms and classification of communication
>> models comprising:
>>
>> citizen-to-citizen, citizen-to-authority,
>> authority-to-authority, and authority-to-citizen
>>
>> which is why we are seeing this terminology creep up on this list.
>> one could take the approach that the IETF will go its own way, but I
>> think it will be more constructive to acknowledge what's already
>> gained traction and explore other terms.  and in this specific case,
>> something other than "authority" if we want to expand the target
>> model.
>>
>> -ken
>>
>>
>>
>> On May 2, 2009, at 3:47 PM, Art Botterell wrote:
>>
>>> If so, why not say "government"?
>>>
>>> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote:
>>>
>>>> Authority is government
>>>>
>>>> ----- Original Message -----
>>>> From: [email-masked] <[email-masked]>
>>>> To: [email-masked] <[email-masked]>
>>>> Sent: Sat May 02 11:51:10 2009
>>>> Subject: Re: [earlywarning] Depricate "Authority" - was : global
>>>> CAPcommunity
>>>>
>>>> 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.
>>>>>
>>>>> You need a term that has wider comprehension.
>>>>
>>>> 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
>>>> _______________________________________________
>>>> earlywarning mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>
>

From: Henning Schulzrinne <[email-masked]>
To: Brian Rosen <[email-masked]>
Date: Mon, 4 May 2009 10:42:55 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

Why is authorization easier for government? A school, university or  
company generally knows all of its students and employees, and can  
thus easily, relatively speaking, provide their public key to them  
ahead of time, so that an alert can be trivially verified as to its  
authenticity. For that, it doesn't matter whether the organization is  
run by a government (say, the Port Authority of NY&NJ) or a private  
entity (Columbia University). (I guess sending alerts to GM and  
Citibank would still be ok...). I'm ignoring the problem of university/ 
company visitors, as most existing alert systems don't deal with them,  
and reasonably rely on the "regulars" to tell them what's going on.

The case of alerting is much harder for entities who need to reach  
everyone who happens to be in their territory, such as a county. They  
have to distribute some cryptographic material to everybody, including  
visitors, without knowing who they are.

Thus, the operative difference seem much more of a "closed" vs. "open"  
membership, rather than whether the entity operating the alert has a  
seal and calls it itself county or state government.

Henning

On May 4, 2009, at 10:01 AM, Brian Rosen wrote:

> Finally, a meaty subject; terminology really doesn't get us very  
> far.  This
> is important; really narrowing scope.
>
> Let's take a look at how far do we want to go:
>
> National Government with major warning - impending attack
> Regional Government with life threatening event - Tornado or flash  
> flood
> Local Government with life threatening event - hazmat spill
> Local Government with important, but not threatening event - major  
> traffic
> tieup
> Local Government with useful event - public school closing
> State Government College with life threatening event - school shooting
> Private College with life threatening event - school shooting
> Private elementary school with useful event  - school closing
> Enterprise with life threatening event - hazmat spill
> Enterprise with useful event - building closing due to weather
>
> It's clear to me that all of these are very useful alerts.  The  
> question
> becomes, which of these should be in scope for the first charter?
>
> It seems to me that the issue of authorization is the biggie here,  
> and if we
> started out limiting to government, even local government, it gets a  
> lot
> easier. Once you allow a non-government entity to notify using the
> mechanism, we make the authorization decision much more difficult.   
> I don't
> see an in-between way to slice the above list other than government/ 
> non
> government unless you say that the government can authorize other  
> entities
> and you are relying on that authorization.
>
> I think the wishes of the networks that are transporting the alerts  
> come
> into play; they would want a bright line on authorization.
>
> I suspect that once you have an authorized entity that can create an  
> alert,
> what it gets to use that authorization for is a less interesting (to  
> the
> IETF) issue.  If you can issue alerts, you can issue any kind of  
> alert.
>
> Brian
>
>
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, May 04, 2009 9:20 AM
> To: Brian Rosen
> Cc: 'ken carlberg'; 'Art Botterell'; [email-masked]
> Subject: Re: [earlywarning] Depricate "Authority" - was : global
> CAPcommunity
>
> This distinction is unlikely to work in the US, at least, as there are
> many quasi-governmental entities. Classical example: some of the
> largest scale notification systems today are deployed by college
> campuses, particularly after the Virginia Tech shooting. There is no
> technical reason why such function should be available to state
> colleges and universities, but not to private institutions (which, in
> the US, are in no way governed by the Federal or state government).
> Same is true for large school districts, which can be either run by
> the city/county or, say, the Catholic Church.
>
> Henning
>
> On May 4, 2009, at 8:42 AM, Brian Rosen wrote:
>
>> As with any IETF effort, limiting scope is useful to get progress  
>> in a
>> reasonable time.  With this effort, we have tried to limit the scope
>> of
>> "authority".  It would be okay with me if we did limit it to
>> government
>> initially, although eventually I suspect we will expand it.
>>
>> I am very comfortable leaving the terminology as is: authority to
>> citizen.
>> I think we can reasonably explain that authority is initially
>> government
>> (national, state/province/region/, and local).  We can reasonably
>> explain
>> that citizen includes residents and visitors.
>>
>> I'd like to keep the discussion more on the scope than on the
>> terminology.
>>
>> Brian
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]
>> ]
>> On Behalf Of ken carlberg
>> Sent: Sunday, May 03, 2009 9:14 AM
>> To: Art Botterell
>> Cc: [email-masked]
>> Subject: Re: [earlywarning] Depricate "Authority" - was : global
>> CAPcommunity
>>
>> a good point.  What the previous poster failed to elaborate on is  
>> that
>> other SDO's like the ITU have made the association of authority =
>> government, and given us terms and classification of communication
>> models comprising:
>>
>> citizen-to-citizen, citizen-to-authority,
>> authority-to-authority, and authority-to-citizen
>>
>> which is why we are seeing this terminology creep up on this list.
>> one could take the approach that the IETF will go its own way, but I
>> think it will be more constructive to acknowledge what's already
>> gained traction and explore other terms.  and in this specific case,
>> something other than "authority" if we want to expand the target
>> model.
>>
>> -ken
>>
>>
>>
>> On May 2, 2009, at 3:47 PM, Art Botterell wrote:
>>
>>> If so, why not say "government"?
>>>
>>> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote:
>>>
>>>> Authority is government
>>>>
>>>> ----- Original Message -----
>>>> From: [email-masked] <[email-masked]>
>>>> To: [email-masked] <[email-masked]>
>>>> Sent: Sat May 02 11:51:10 2009
>>>> Subject: Re: [earlywarning] Depricate "Authority" - was : global
>>>> CAPcommunity
>>>>
>>>> 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.
>>>>>
>>>>> You need a term that has wider comprehension.
>>>>
>>>> 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
>>>> _______________________________________________
>>>> earlywarning mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>
>

From: "Carl Reed" <[email-masked]>
To: "Thomson, Martin" <[email-masked]>, <[email-masked]>,  "Art Botterell" <[email-masked]>
Date: Mon, 4 May 2009 08:36:54 -0600
Organization: OGC
Cc: [email-masked]
Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity

Martin -

Thanks for this perspective.

I also was beginning to worry about mixing "apples and oranges" in this 
discussion. The rules of use and distribution of an alert and the alert 
payload itself are two different (but related) animals. As an example, 
GeoRSS is used in numerous consumer, unrestricted alerting applications. No 
thought to security, authentication, quality, etc. At the other extreme, 
GeoRSS is now also used in a secure Intelnet application. Obviously very 
different use cases with very, very different requirements for 
authentication and security. And different vocabularies/semantics. But the 
identical payload info model, schemas and so forth.  Same with CAP. Whether 
a Presidential alert has priority or not is not relevant to the CAP info 
model and structure. What is important in terms of where the authentication 
is performed, the priority setting, and so forth is the actual alerting 
architecture and infrastructure.

Carl

----- Original Message ----- 
From: "Thomson, Martin" <[email-masked]>
To: <[email-masked]>; "Art Botterell" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, May 03, 2009 7:24 PM
Subject: Re: [earlywarning] Deprecate "Authority" - was : global 
CAPcommunity

>I worry that this discussion has lost focus.  Are we talking about terms 
>for use in relation to a protocol, or terms in relation to problem 
>statement and naming (marketing)?  They can be separated.
>
> The terms that Hannes proposes (Author and Recipient) would be quite 
> suitable for use in describing a protocol and architecture.
>
> Is this really the venue for deciding who applies this protocol solution? 
> Not that I'm suggesting we design in a vacuum, but we each have a fair 
> idea of what the goals are; and I truly don't think that there are major 
> differences of opinion.  The subjective definition of "authority" need not 
> be a barrier to progress.
>
> I'm happy with marketing with vague terms like "authority-to-citizen" or 
> "early warning" and having separate terms in protocol land.  That's been 
> successful in the past; the abstraction allows for a little flexibility in 
> interpretation.  That flexibility is sometimes useful.
>
> I tend to agree with Art that we can spend a lot of time on the 
> non-technical stuff.  Maybe abstraction offers us a way to make process on 
> the technical side while we "slosh around" on the fuzzy issues.
>
> --Martin
>
>
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning 

From: "Brian Rosen" <[email-masked]>
To: "'Henning Schulzrinne'" <[email-masked]>
Date: Mon, 4 May 2009 10:01:55 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

Finally, a meaty subject; terminology really doesn't get us very far.  This
is important; really narrowing scope.

Let's take a look at how far do we want to go:

National Government with major warning - impending attack
Regional Government with life threatening event - Tornado or flash flood
Local Government with life threatening event - hazmat spill
Local Government with important, but not threatening event - major traffic
tieup
Local Government with useful event - public school closing
State Government College with life threatening event - school shooting
Private College with life threatening event - school shooting
Private elementary school with useful event  - school closing
Enterprise with life threatening event - hazmat spill
Enterprise with useful event - building closing due to weather

It's clear to me that all of these are very useful alerts.  The question
becomes, which of these should be in scope for the first charter?

It seems to me that the issue of authorization is the biggie here, and if we
started out limiting to government, even local government, it gets a lot
easier. Once you allow a non-government entity to notify using the
mechanism, we make the authorization decision much more difficult.  I don't
see an in-between way to slice the above list other than government/non
government unless you say that the government can authorize other entities
and you are relying on that authorization.  

I think the wishes of the networks that are transporting the alerts come
into play; they would want a bright line on authorization.

I suspect that once you have an authorized entity that can create an alert,
what it gets to use that authorization for is a less interesting (to the
IETF) issue.  If you can issue alerts, you can issue any kind of alert.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Monday, May 04, 2009 9:20 AM
To: Brian Rosen
Cc: 'ken carlberg'; 'Art Botterell'; [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

This distinction is unlikely to work in the US, at least, as there are  
many quasi-governmental entities. Classical example: some of the  
largest scale notification systems today are deployed by college  
campuses, particularly after the Virginia Tech shooting. There is no  
technical reason why such function should be available to state  
colleges and universities, but not to private institutions (which, in  
the US, are in no way governed by the Federal or state government).  
Same is true for large school districts, which can be either run by  
the city/county or, say, the Catholic Church.

Henning

On May 4, 2009, at 8:42 AM, Brian Rosen wrote:

> As with any IETF effort, limiting scope is useful to get progress in a
> reasonable time.  With this effort, we have tried to limit the scope  
> of
> "authority".  It would be okay with me if we did limit it to  
> government
> initially, although eventually I suspect we will expand it.
>
> I am very comfortable leaving the terminology as is: authority to  
> citizen.
> I think we can reasonably explain that authority is initially  
> government
> (national, state/province/region/, and local).  We can reasonably  
> explain
> that citizen includes residents and visitors.
>
> I'd like to keep the discussion more on the scope than on the  
> terminology.
>
> Brian
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked] 
> ]
> On Behalf Of ken carlberg
> Sent: Sunday, May 03, 2009 9:14 AM
> To: Art Botterell
> Cc: [email-masked]
> Subject: Re: [earlywarning] Depricate "Authority" - was : global
> CAPcommunity
>
> a good point.  What the previous poster failed to elaborate on is that
> other SDO's like the ITU have made the association of authority =
> government, and given us terms and classification of communication
> models comprising:
>
> citizen-to-citizen, citizen-to-authority,
> authority-to-authority, and authority-to-citizen
>
> which is why we are seeing this terminology creep up on this list.
> one could take the approach that the IETF will go its own way, but I
> think it will be more constructive to acknowledge what's already
> gained traction and explore other terms.  and in this specific case,
> something other than "authority" if we want to expand the target  
> model.
>
> -ken
>
>
>
> On May 2, 2009, at 3:47 PM, Art Botterell wrote:
>
>> If so, why not say "government"?
>>
>> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote:
>>
>>> Authority is government
>>>
>>> ----- Original Message -----
>>> From: [email-masked] <[email-masked]>
>>> To: [email-masked] <[email-masked]>
>>> Sent: Sat May 02 11:51:10 2009
>>> Subject: Re: [earlywarning] Depricate "Authority" - was : global
>>> CAPcommunity
>>>
>>> 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.
>>>>
>>>> You need a term that has wider comprehension.
>>>
>>> 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
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>

From: "Brian Rosen" <[email-masked]>
To: "'Art Botterell'" <[email-masked]>, <[email-masked]>
Date: Mon, 4 May 2009 09:35:33 -0400
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

It's probably not quite that simple, but generally, yes, I think we're
mostly concerned with how a message in a defined format (CAP) gets from the
authority to the citizen.  I don't think anyone is arguing we aren't
leveraging the CAP work.

There are undoubtedly issues with doing content the IETF way, as we usually
deal up front with issues like a wide range of devices with different
capabilities that need to render the alert, as well as language issues, etc.
So, it's not JUST transport.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Art Botterell
Sent: Sunday, May 03, 2009 12:33 PM
To: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

We can justify the term "authority" by appeal to authority (ITU, etc.)  
but I'm not sure that brings us any closer to an implementable spec.   
The problem arises when we try to build from inherently fuzzy terms  
like "authority" and "warning" to specific technical requirements.

It sounds like what we're really talking about is transport of  
infrequent one-to-many communications of particular importance and  
urgency.

- Art

On May 3, 2009, at 5/3/09 6:13 AM, ken carlberg wrote:

> a good point.  What the previous poster failed to elaborate on is  
> that other SDO's like the ITU have made the association of authority  
> = government, and given us terms and classification of  
> communication models comprising:
>
> citizen-to-citizen, citizen-to-authority,
> authority-to-authority, and authority-to-citizen
>
> which is why we are seeing this terminology creep up on this list.   
> one could take the approach that the IETF will go its own way, but I  
> think it will be more constructive to acknowledge what's already  
> gained traction and explore other terms.  and in this specific case,  
> something other than "authority" if we want to expand the target  
> model.
>
> -ken
>
>
>
> On May 2, 2009, at 3:47 PM, Art Botterell wrote:
>
>> If so, why not say "government"?
>>
>> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote:
>>
>>> Authority is government
>>>
>>>

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

From: Henning Schulzrinne <[email-masked]>
To: Brian Rosen <[email-masked]>
Date: Mon, 4 May 2009 09:20:01 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

This distinction is unlikely to work in the US, at least, as there are  
many quasi-governmental entities. Classical example: some of the  
largest scale notification systems today are deployed by college  
campuses, particularly after the Virginia Tech shooting. There is no  
technical reason why such function should be available to state  
colleges and universities, but not to private institutions (which, in  
the US, are in no way governed by the Federal or state government).  
Same is true for large school districts, which can be either run by  
the city/county or, say, the Catholic Church.

Henning

On May 4, 2009, at 8:42 AM, Brian Rosen wrote:

> As with any IETF effort, limiting scope is useful to get progress in a
> reasonable time.  With this effort, we have tried to limit the scope  
> of
> "authority".  It would be okay with me if we did limit it to  
> government
> initially, although eventually I suspect we will expand it.
>
> I am very comfortable leaving the terminology as is: authority to  
> citizen.
> I think we can reasonably explain that authority is initially  
> government
> (national, state/province/region/, and local).  We can reasonably  
> explain
> that citizen includes residents and visitors.
>
> I'd like to keep the discussion more on the scope than on the  
> terminology.
>
> Brian
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked] 
> ]
> On Behalf Of ken carlberg
> Sent: Sunday, May 03, 2009 9:14 AM
> To: Art Botterell
> Cc: [email-masked]
> Subject: Re: [earlywarning] Depricate "Authority" - was : global
> CAPcommunity
>
> a good point.  What the previous poster failed to elaborate on is that
> other SDO's like the ITU have made the association of authority =
> government, and given us terms and classification of communication
> models comprising:
>
> citizen-to-citizen, citizen-to-authority,
> authority-to-authority, and authority-to-citizen
>
> which is why we are seeing this terminology creep up on this list.
> one could take the approach that the IETF will go its own way, but I
> think it will be more constructive to acknowledge what's already
> gained traction and explore other terms.  and in this specific case,
> something other than "authority" if we want to expand the target  
> model.
>
> -ken
>
>
>
> On May 2, 2009, at 3:47 PM, Art Botterell wrote:
>
>> If so, why not say "government"?
>>
>> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote:
>>
>>> Authority is government
>>>
>>> ----- Original Message -----
>>> From: [email-masked] <[email-masked]>
>>> To: [email-masked] <[email-masked]>
>>> Sent: Sat May 02 11:51:10 2009
>>> Subject: Re: [earlywarning] Depricate "Authority" - was : global
>>> CAPcommunity
>>>
>>> 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.
>>>>
>>>> You need a term that has wider comprehension.
>>>
>>> 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
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>

From: "Brian Rosen" <[email-masked]>
To: "'ken carlberg'" <[email-masked]>, "'James M. Polk'" <[email-masked]>
Date: Mon, 4 May 2009 08:45:05 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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

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

>> 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).

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

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

From: "Brian Rosen" <[email-masked]>
To: "'ken carlberg'" <[email-masked]>, "'Art Botterell'" <[email-masked]>
Date: Mon, 4 May 2009 08:42:52 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

As with any IETF effort, limiting scope is useful to get progress in a
reasonable time.  With this effort, we have tried to limit the scope of
"authority".  It would be okay with me if we did limit it to government
initially, although eventually I suspect we will expand it.

I am very comfortable leaving the terminology as is: authority to citizen.
I think we can reasonably explain that authority is initially government
(national, state/province/region/, and local).  We can reasonably explain
that citizen includes residents and visitors.

I'd like to keep the discussion more on the scope than on the terminology.  

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of ken carlberg
Sent: Sunday, May 03, 2009 9:14 AM
To: Art Botterell
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global
CAPcommunity

a good point.  What the previous poster failed to elaborate on is that  
other SDO's like the ITU have made the association of authority =  
government, and given us terms and classification of communication  
models comprising:

citizen-to-citizen, citizen-to-authority,
authority-to-authority, and authority-to-citizen

which is why we are seeing this terminology creep up on this list.   
one could take the approach that the IETF will go its own way, but I  
think it will be more constructive to acknowledge what's already  
gained traction and explore other terms.  and in this specific case,  
something other than "authority" if we want to expand the target model.

-ken

On May 2, 2009, at 3:47 PM, Art Botterell wrote:

> If so, why not say "government"?
>
> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote:
>
>> Authority is government
>>
>> ----- Original Message -----
>> From: [email-masked] <[email-masked]>
>> To: [email-masked] <[email-masked]>
>> Sent: Sat May 02 11:51:10 2009
>> Subject: Re: [earlywarning] Depricate "Authority" - was : global  
>> CAPcommunity
>>
>> 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.
>>>
>>> You need a term that has wider comprehension.
>>
>> 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
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

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

Date: Mon, 04 May 2009 10:06:33 +0200
From: Richard Barnes <[email-masked]>
To: "Thomson, Martin" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity

+1

Also, under the "marketing" header, it will probably be useful to put 
together some mapping between the more general terms we'll use for 
protocol development and the specific terms used, e.g., by ITU-T.

--Richard

Thomson, Martin wrote:
> I worry that this discussion has lost focus.  Are we talking about terms for use in relation to a protocol, or terms in relation to problem statement and naming (marketing)?  They can be separated.
> 
> The terms that Hannes proposes (Author and Recipient) would be quite suitable for use in describing a protocol and architecture.
> 
> Is this really the venue for deciding who applies this protocol solution?  Not that I'm suggesting we design in a vacuum, but we each have a fair idea of what the goals are; and I truly don't think that there are major differences of opinion.  The subjective definition of "authority" need not be a barrier to progress.
> 
> I'm happy with marketing with vague terms like "authority-to-citizen" or "early warning" and having separate terms in protocol land.  That's been successful in the past; the abstraction allows for a little flexibility in interpretation.  That flexibility is sometimes useful.
> 
> I tend to agree with Art that we can spend a lot of time on the non-technical stuff.  Maybe abstraction offers us a way to make process on the technical side while we "slosh around" on the fuzzy issues.
> 
> --Martin
> 
> 
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.  
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Content-class: urn:content-classes:message
Date: Sun, 3 May 2009 20:24:19 -0500
From: "Thomson, Martin" <[email-masked]>
To: <[email-masked]>, "Art Botterell" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity

Date: Sun, 03 May 2009 13:24:37 -0400
From: Tony Rutkowski <[email-masked]>
Organization: Netmagic Associates
To: Art Botterell <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity
Reply-To: [email-masked]

> Not sure I follow you... how would developing technical requirements
> be a national matter?  Or more to the point, if it is, then what are
> we doing here? 
Hi Art,

My reference was with the idea that the ITU would somehow be
defining who "authorities" were for the purposes of specific national
implementations where "authority" needed to be designated.
Provisions such as the FCC's Part 10 rules specify specify this.

The better approach is the more generic one that you advocate.

--tony

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

From: Art Botterell <[email-masked]>
To: [email-masked]
Date: Sun, 3 May 2009 10:12:15 -0700
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

Tony -

Not sure I follow you... how would developing technical requirements  
be a national matter?  Or more to the point, if it is, then what are  
we doing here?

As for X.1303/CAP... that's a content standard.  Seems like the issue  
here is transport, about which the CAP spec is aggressively agnostic.

But again, seems like we're all over the map on our assumptions.  Are  
we, in fact, talking transport, or what?

- Art

On May 3, 2009, at 5/3/09 10:05 AM, Tony Rutkowski wrote:

> Hi Art,
>> We can justify the term "authority" by appeal to authority (ITU,  
>> etc.)
>> but I'm not sure that brings us any closer to an implementable spec.
>> The problem arises when we try to build from inherently fuzzy terms
>> like "authority" and "warning" to specific technical requirements.
> The quick ITU-T answer is likely to be that this is a national matter.
>
> Rec. X.1303 encompasses a broad array of potential implementations.
>> constructive to acknowledge what's already gained traction and  
>> explore
>> other terms.  and in this specific case, something other than
>> "authority" if we want to expand the target model.
> This is the way to go.
>
> --tony
>
> -- 
> Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1  
> 703.999.8270
>

Date: Sun, 03 May 2009 13:05:14 -0400
From: Tony Rutkowski <[email-masked]>
Organization: Netmagic Associates
To: Art Botterell <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity
Reply-To: [email-masked]

Hi Art,
> We can justify the term "authority" by appeal to authority (ITU, etc.)
> but I'm not sure that brings us any closer to an implementable spec. 
> The problem arises when we try to build from inherently fuzzy terms
> like "authority" and "warning" to specific technical requirements.
The quick ITU-T answer is likely to be that this is a national matter. 

Rec. X.1303 encompasses a broad array of potential implementations. 
> constructive to acknowledge what's already gained traction and explore
> other terms.  and in this specific case, something other than
> "authority" if we want to expand the target model.
This is the way to go.

--tony

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

From: Art Botterell <[email-masked]>
To: [email-masked]
Date: Sun, 3 May 2009 09:32:54 -0700
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

We can justify the term "authority" by appeal to authority (ITU, etc.)  
but I'm not sure that brings us any closer to an implementable spec.   
The problem arises when we try to build from inherently fuzzy terms  
like "authority" and "warning" to specific technical requirements.

It sounds like what we're really talking about is transport of  
infrequent one-to-many communications of particular importance and  
urgency.

- Art

On May 3, 2009, at 5/3/09 6:13 AM, ken carlberg wrote:

> a good point.  What the previous poster failed to elaborate on is  
> that other SDO's like the ITU have made the association of authority  
> = government, and given us terms and classification of  
> communication models comprising:
>
> citizen-to-citizen, citizen-to-authority,
> authority-to-authority, and authority-to-citizen
>
> which is why we are seeing this terminology creep up on this list.   
> one could take the approach that the IETF will go its own way, but I  
> think it will be more constructive to acknowledge what's already  
> gained traction and explore other terms.  and in this specific case,  
> something other than "authority" if we want to expand the target  
> model.
>
> -ken
>
>
>
> On May 2, 2009, at 3:47 PM, Art Botterell wrote:
>
>> If so, why not say "government"?
>>
>> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote:
>>
>>> Authority is government
>>>
>>>

From: ken carlberg <[email-masked]>
To: James M. Polk <[email-masked]>
Date: Sun, 3 May 2009 09:48:21 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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

>> 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).

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: ken carlberg <[email-masked]>
To: Art Botterell <[email-masked]>
Date: Sun, 3 May 2009 09:13:34 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

a good point.  What the previous poster failed to elaborate on is that  
other SDO's like the ITU have made the association of authority =  
government, and given us terms and classification of communication  
models comprising:

citizen-to-citizen, citizen-to-authority,
authority-to-authority, and authority-to-citizen

which is why we are seeing this terminology creep up on this list.   
one could take the approach that the IETF will go its own way, but I  
think it will be more constructive to acknowledge what's already  
gained traction and explore other terms.  and in this specific case,  
something other than "authority" if we want to expand the target model.

-ken

On May 2, 2009, at 3:47 PM, Art Botterell wrote:

> If so, why not say "government"?
>
> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote:
>
>> Authority is government
>>
>> ----- Original Message -----
>> From: [email-masked] <[email-masked]>
>> To: [email-masked] <[email-masked]>
>> Sent: Sat May 02 11:51:10 2009
>> Subject: Re: [earlywarning] Depricate "Authority" - was : global  
>> CAPcommunity
>>
>> 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.
>>>
>>> You need a term that has wider comprehension.
>>
>> 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
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Art Botterell <[email-masked]>
To: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sat, 2 May 2009 12:47:10 -0700
Cc: [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

If so, why not say "government"?

On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote:

> Authority is government
>
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: [email-masked] <[email-masked]>
> Sent: Sat May 02 11:51:10 2009
> Subject: Re: [earlywarning] Depricate "Authority" - was : global  
> CAPcommunity
>
> 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.
>>
>> You need a term that has wider comprehension.
>
> 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
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Content-class: urn:content-classes:message
Date: Sat, 2 May 2009 15:38:30 -0400
From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity

From: Art Botterell <[email-masked]>
To: [email-masked]
Date: Sat, 2 May 2009 08:51:10 -0700
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAP community

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.
>
> You need a term that has wider comprehension.

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

Date: Sat, 02 May 2009 08:08:39 -0400
From: Tony Rutkowski <[email-masked]>
Organization: Netmagic Associates
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Some further scoping issues
Reply-To: [email-masked]

These seem like good admonitions.  The broader scope will provide
greater value to work, rather than attempting to deal a specific kind
of implementation that gets into an already well-established regulatory
domain.

For those of you unfamiliar with the new FCC Part 10 rules specifying
Commercial Mobile Alert System (CMAS) implementations, they are available at
http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?cìfr&rgn=div5&view=text&nodeG:1.0.1.1.10&idnoG
For U.S. implementations, note that 47 CFR Sec. 10.410 requires that
"Presidential
Alerts preempt all other Alert Messages."

ciao,
--tony
> For the future work in this group I furthermore suggest that 
>
> * we do not focus our efforts on defining an architecture used for
> distributing of alert messages (like we did it in ECRIT with the
> PhoneBCP/Framework document). Instead, we develop building blocks (like
> conveying CAP in SIP). I believe we will run into lots of problems with the
> different usages, different solutions that have been specified elsewhere
> already, etc. 
>
> * we do not pick a single alert document format (as a
> mandatory-to-implement), like CAP or GeoRSS, but instead give those who
> deploy these mechanisms freedom. 
>
> * we do not define our own alert document format (because there are other
> formats available already). 
>
> We can always decide later to document ways how people use our stuff. 
>   

To: "Hannes Tschofenig" <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Sat, 2 May 2009 06:26:13 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] Depricate "Authority" - was : global CAP community

This is a multipart message in MIME format.
--=_alternative 003954D3852575AA_Content-Type: text/plain; charset="US-ASCII"

[email-masked] wrote on 05/02/2009 05:14:59 AM:

> I suggest to generalize the subject a bit and propose the following
> modifications:
> 
> * 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
--=_alternative 003954D3852575AA_Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif"><br>
</font>
<br>
<br><font size=2><tt>[email-masked] wrote on 05/02/2009
05:14:59 AM:<br>
<br>
<br>
&gt; I suggest to generalize the subject a bit and propose the following<br>
&gt; modifications:<br>
&gt; &nbsp;<br>
&gt; * replace &quot;early warning&quot; with &quot;Exigent Communications&quot;<br>
</tt></font>
<br><font size=2><tt>I think that is a bad idea.</tt></font>
<br>
<br><font size=2><tt>How many people here know PRECISELY what &quot;exigent&quot;
means without looking it up.</tt></font>
<br>
<br><font size=2><tt>You need a term that has wider comprehension.</tt></font>
<br>
<br><font size=2><tt>Janet</tt></font>
--=_alternative 003954D3852575AA_=--

From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>
Date: Sat, 2 May 2009 12:49:54 +0300
Subject: [earlywarning] Some further scoping issues

For the future work in this group I furthermore suggest that 

* we do not focus our efforts on defining an architecture used for
distributing of alert messages (like we did it in ECRIT with the
PhoneBCP/Framework document). Instead, we develop building blocks (like
conveying CAP in SIP). I believe we will run into lots of problems with the
different usages, different solutions that have been specified elsewhere
already, etc. 

* we do not pick a single alert document format (as a
mandatory-to-implement), like CAP or GeoRSS, but instead give those who
deploy these mechanisms freedom. 

* we do not define our own alert document format (because there are other
formats available already). 

We can always decide later to document ways how people use our stuff. 

Ciao
Hannes

From: "Hannes Tschofenig" <[email-masked]>
To: "'Richard Barnes'" <[email-masked]>, "'Brian Rosen'" <[email-masked]>
Date: Sat, 2 May 2009 12:14:59 +0300
Cc: [email-masked]
Subject: [earlywarning] Depricate "Authority" - was : global CAP community

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

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Richard Barnes
>Sent: 01 May, 2009 19:02
>To: Brian Rosen
>Cc: [email-masked]
>Subject: Re: [earlywarning] global CAP community
>
>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
>
>
>
>Brian Rosen wrote:
>> 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
>> 
>> 
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> 
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning
>

To: "James M. Polk" <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Fri, 1 May 2009 21:53:18 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] global CAP community

This is a multipart message in MIME format.
--=_alternative 000A5F7C852575AA_Content-Type: text/plain; charset="US-ASCII"

"James M. Polk" <[email-masked]> wrote on 05/01/2009 06:52:05 PM:

> At 04:36 PM 5/1/2009, Tony Rutkowski 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).
> >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.
> 
> hmmmm.... NS/EP means preemption....?
> 
> 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
> 
> 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
> 
> 
> >--tony
> 

--=_alternative 000A5F7C852575AA_Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif"><br>
</font>
<br><font size=2><tt>&quot;James M. Polk&quot; &lt;[email-masked]&gt;
wrote on 05/01/2009 06:52:05 PM:<br>
<br>
&gt; At 04:36 PM 5/1/2009, Tony Rutkowski wrote:<br>
&gt; &gt; &gt; I was wondering the same thing, as priority seems natural
(wrt server<br>
&gt; &gt; &gt; resources, and indication of the type of message), but this
is never<br>
&gt; &gt; &gt; going to be a stream, so I don't think we'll likely have
1 message<br>
&gt; &gt; &gt; preempt another (but we may delay one message relative to
another).<br>
&gt; &gt;In many cases, this will be dictated by national regulatory<br>
&gt; &gt;authorities or legislative requirements. In the U.S., for<br>
&gt; &gt;example, under the WARN Act, presidential messages<br>
&gt; &gt;preempt all others. In addition, when the FCC or other<br>
&gt; &gt;authorities specify certain NS/EP conditions, preemption<br>
&gt; &gt;actually occurs.<br>
&gt; <br>
&gt; hmmmm.... NS/EP means preemption....?<br>
&gt; <br>
&gt; I'll let Janet comment on that - since she works for NCS (who run
GETS).</tt></font>
<br>
<br><font size=2><tt>IFF the war powers act were invoked, then preemption
would be permitted.</tt></font>
<br>
<br><font size=2><tt>But, in situations not triggering the war powers act-
which is the &quot;real world&quot; situation we actually deal with- the
Service Providers will not permit preemption of voice communication. &nbsp;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.</tt></font>
<br>
<br><font size=2><tt>None of the deployed NS/EP programs I am aware of
(including the ones I am not supposed to talk about) use preemption. &nbsp;Queueing,
alternate routing, exemption from network controls, exemption from load
shedding- they are all part of the NS/EP programs. &nbsp;But not preemption.</tt></font>
<br>
<br><font size=2><tt>But that is beside the point.</tt></font>
<br>
<br><font size=2><tt>In &quot;earlywarning&quot; we are talking about &quot;messages&quot;,
not &quot;calls&quot; or even &quot;sessions&quot;. What is it that you
are going to &quot;preempt&quot;? &nbsp;Sure, if it is a voice message
you are sending, you could interrupt the message to send some other message.
&nbsp;But then you would just resend the original message later. &nbsp;Delayed,
but not preempted.</tt></font>
<br><font size=2><tt>&nbsp;Janet<br>
&gt; <br>
&gt; I'm curious about this line too<br>
&gt; <br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&quot;In the U.S., for example,
under the WARN Act,<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;presidential messages preempt all
others.&quot;<br>
&gt; <br>
&gt; The WARN act isn't about real-time communications, so why is there
<br>
&gt; any need for preemption? Why not just store-and-forward (i.e., delay)
<br>
&gt; the messages of lower priority than the president's?<br>
&gt; <br>
&gt; James<br>
&gt; <br>
&gt; <br>
&gt; &gt;--tony<br>
&gt; <br>
</tt></font>
--=_alternative 000A5F7C852575AA_=--

Date: Fri, 01 May 2009 17:52:05 -0500
To: [email-masked]
From: "James M. Polk" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] global CAP community

At 04:36 PM 5/1/2009, Tony Rutkowski 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).
>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.

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

>--tony

Date: Fri, 01 May 2009 17:36:54 -0400
From: Tony Rutkowski <[email-masked]>
Organization: Netmagic Associates
To: "James M. Polk" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] global CAP community
Reply-To: [email-masked]

> 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). 
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

Date: Fri, 01 May 2009 16:19:31 -0500
To: Janet P Gunn <[email-masked]>, Richard Barnes <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] global CAP community

At 03:23 PM 5/1/2009, Janet P Gunn wrote:

>[email-masked] wrote on 05/01/2009 03:07:01 PM:
>
> > 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 (?)
>
>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).

>Janet
>
> > -- Scalability (e.g., using multicast)
> >
> > --Richard
> >
> >
> >

To: Richard Barnes <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Fri, 1 May 2009 16:23:14 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] global CAP community

This is a multipart message in MIME format.
--=_alternative 006FFD5F852575A9_Content-Type: text/plain; charset="US-ASCII"

[email-masked] wrote on 05/01/2009 03:07:01 PM:

> 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 (?)

What are you planning to preempt?

Janet

> -- Scalability (e.g., using multicast)
> 
> --Richard
> 
> 
>
--=_alternative 006FFD5F852575A9_Content-Type: text/html; charset="US-ASCII"

<br>
<br><font size=2><tt>[email-masked] wrote on 05/01/2009
03:07:01 PM:<br>
<br>
&gt; James,<br>
&gt; <br>
&gt; Protocols don't know about citizenship. &nbsp;At the protocol level,
alert <br>
&gt; consumers are just message consumers with special requirements <br>
&gt; (immediacy, geographic targeting, etc).<br>
&gt; <br>
&gt; Point-to-point messaging is indeed our starting point: The point of
this <br>
&gt; working group is to take existing IETF messaging protocols (e.g.,
SIP) <br>
&gt; and extend them to meet the requirements for delivering emergency
messages:<br>
&gt; -- Strong, E2E authentication and authorization of alert originators<br>
&gt; -- E2E authentication and integrity-protection for alerts<br>
&gt; -- Delivery based on geolocation (and other constraints)<br>
&gt; -- Priority and preemption (?)</tt></font>
<br>
<br><font size=2><tt>What are you planning to preempt?</tt></font>
<br>
<br><font size=2><tt>Janet</tt></font>
<br><font size=2><tt><br>
&gt; -- Scalability (e.g., using multicast)<br>
&gt; <br>
&gt; --Richard<br>
&gt; <br>
&gt; <br>
&gt;</tt></font>
--=_alternative 006FFD5F852575A9_=--

To: Richard Barnes <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Fri, 1 May 2009 16:21:06 -0400
Cc: [email-masked], [email-masked]
Subject: Re: [earlywarning] global CAP community

This is a multipart message in MIME format.
--=_alternative 006FCB70852575A9_Content-Type: text/plain; charset="US-ASCII"

[email-masked] wrote on 05/01/2009 03:07:01 PM:

> James,
> 
> Protocols don't know about citizenship.  At the protocol level, alert 
> consumers are just message consumers with special requirements 
> (immediacy, geographic targeting, etc).
> 
Perhaps "resident". My "citizenship" and my "residence" are thousands of 
miles apart.

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

--=_alternative 006FCB70852575A9_Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif"><br>
</font>
<br>
<br><font size=2><tt>[email-masked] wrote on 05/01/2009
03:07:01 PM:<br>
<br>
&gt; James,<br>
&gt; <br>
&gt; Protocols don't know about citizenship. &nbsp;At the protocol level,
alert <br>
&gt; consumers are just message consumers with special requirements <br>
&gt; (immediacy, geographic targeting, etc).<br>
&gt; </tt></font>
<br><font size=2><tt>Perhaps &quot;resident&quot;. My &quot;citizenship&quot;
and my &quot;residence&quot; are thousands of miles apart.</tt></font>
<br>
<br><font size=2><tt>Janet<br>
&gt; _______________________________________________<br>
&gt; earlywarning mailing list<br>
&gt; [email-masked]<br>
&gt; https://www.ietf.org/mailman/listinfo/earlywarning<br>
</tt></font>
--=_alternative 006FCB70852575A9_=--

Date: Fri, 01 May 2009 15:00:53 -0500
To: Richard Barnes <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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 
>(immediacy, geographic targeting, etc).

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:
>-- Strong, E2E authentication and authorization of alert originators

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

Is anything on Twitter verifyable?

>-- 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:
>>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
>>
>>>--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]>
>>>>To: "Brian Rosen" <[email-masked]>
>>>>Cc: <[email-masked]>
>>>>Sent: Friday, May 01, 2009 10:02 AM
>>>>Subject: Re: [earlywarning] global CAP community
>>>>
>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>Brian Rosen wrote:
>>>>>>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
>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>earlywarning mailing list
>>>>>>[email-masked]
>>>>>>https://www.ietf.org/mailman/listinfo/earlywarning
>>>>>_______________________________________________
>>>>>earlywarning mailing list
>>>>>[email-masked]
>>>>>https://www.ietf.org/mailman/listinfo/earlywarning
>>>_______________________________________________
>>>earlywarning mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/earlywarning

Date: Fri, 01 May 2009 14:55:39 -0500
To: "Carl Reed" <[email-masked]>, "Richard Barnes" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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 
>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
>
>
>>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
>>
>>
>>>--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]>
>>>>To: "Brian Rosen" <[email-masked]>
>>>>Cc: <[email-masked]>
>>>>Sent: Friday, May 01, 2009 10:02 AM
>>>>Subject: Re: [earlywarning] global CAP community
>>>>
>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>Brian Rosen wrote:
>>>>>>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
>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>earlywarning mailing list
>>>>>>[email-masked]
>>>>>>https://www.ietf.org/mailman/listinfo/earlywarning
>>>>>_______________________________________________
>>>>>earlywarning mailing list
>>>>>[email-masked]
>>>>>https://www.ietf.org/mailman/listinfo/earlywarning
>>>_______________________________________________
>>>earlywarning mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/earlywarning

Date: Fri, 01 May 2009 15:38:24 -0400
From: Tony Rutkowski <[email-masked]>
Organization: Netmagic Associates LLC
To: ken carlberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community
Reply-To: [email-masked]

> 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.
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

Date: Fri, 01 May 2009 15:07:01 -0400
From: Richard Barnes <[email-masked]>
To: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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:
> 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
> 
> 
>> --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]>
>>> To: "Brian Rosen" <[email-masked]>
>>> Cc: <[email-masked]>
>>> Sent: Friday, May 01, 2009 10:02 AM
>>> Subject: Re: [earlywarning] global CAP community
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>> Brian Rosen wrote:
>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> earlywarning mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>> _______________________________________________
>>>> earlywarning mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
> 
> 

From: "Carl Reed" <[email-masked]>
To: "Richard Barnes" <[email-masked]>, "James M. Polk" <[email-masked]>
Date: Fri, 1 May 2009 13:04:03 -0600
Organization: OGC
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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

> 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
>
>
>>--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]>
>>>To: "Brian Rosen" <[email-masked]>
>>>Cc: <[email-masked]>
>>>Sent: Friday, May 01, 2009 10:02 AM
>>>Subject: Re: [earlywarning] global CAP community
>>>
>>>>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
>>>>
>>>>
>>>>
>>>>Brian Rosen wrote:
>>>>>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
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>earlywarning mailing list
>>>>>[email-masked]
>>>>>https://www.ietf.org/mailman/listinfo/earlywarning
>>>>_______________________________________________
>>>>earlywarning mailing list
>>>>[email-masked]
>>>>https://www.ietf.org/mailman/listinfo/earlywarning
>>_______________________________________________
>>earlywarning mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/earlywarning
> 

From: ken carlberg <[email-masked]>
To: "James M. Polk" <[email-masked]>
Date: Fri, 1 May 2009 15:01:13 -0400
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

On May 1, 2009, at 2:45 PM, James M. Polk wrote:

> "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 

Date: Fri, 01 May 2009 13:45:49 -0500
To: Richard Barnes <[email-masked]>, Carl Reed <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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

>--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]>
>>To: "Brian Rosen" <[email-masked]>
>>Cc: <[email-masked]>
>>Sent: Friday, May 01, 2009 10:02 AM
>>Subject: Re: [earlywarning] global CAP community
>>
>>>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
>>>
>>>
>>>
>>>Brian Rosen wrote:
>>>>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
>>>>
>>>>
>>>>_______________________________________________
>>>>earlywarning mailing list
>>>>[email-masked]
>>>>https://www.ietf.org/mailman/listinfo/earlywarning
>>>_______________________________________________
>>>earlywarning mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/earlywarning
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

Date: Fri, 01 May 2009 13:40:10 -0500
To: "Carl Reed" <[email-masked]>, "Richard Barnes" <[email-masked]>, "Brian Rosen" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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. 
>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.

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.

>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
>
>
>>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
>>
>>
>>
>>Brian Rosen wrote:
>>>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
>>>
>>>
>>>_______________________________________________
>>>earlywarning mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/earlywarning
>>_______________________________________________
>>earlywarning mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/earlywarning
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

Date: Fri, 01 May 2009 13:34:56 -0500
To: Richard Barnes <[email-masked]>, Brian Rosen <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

At 11:02 AM 5/1/2009, Richard Barnes wrote:
>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,

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?

>--Richard
>
>
>
>Brian Rosen wrote:
>>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
>>
>>_______________________________________________
>>earlywarning mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/earlywarning
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

Date: Fri, 01 May 2009 14:26:30 -0400
From: Richard Barnes <[email-masked]>
To: Carl Reed <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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]>
> To: "Brian Rosen" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, May 01, 2009 10:02 AM
> Subject: Re: [earlywarning] global CAP community
> 
> 
>> 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
>>
>>
>>
>> Brian Rosen wrote:
>>> 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
>>>
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning 
> 
> 

From: "Carl Reed" <[email-masked]>
To: "Richard Barnes" <[email-masked]>, "Brian Rosen" <[email-masked]>
Date: Fri, 1 May 2009 10:28:06 -0600
Organization: OGC
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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

>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
>
>
>
> Brian Rosen wrote:
>> 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
>>
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning 

Date: Fri, 01 May 2009 12:02:03 -0400
From: Richard Barnes <[email-masked]>
To: Brian Rosen <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] global CAP community

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

Brian Rosen wrote:
> 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
> 
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> 

From: "Carl Reed" <[email-masked]>
To: "Brian Rosen" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Fri, 1 May 2009 09:59:31 -0600
Organization: OGC
Subject: Re: [earlywarning] global CAP community

This is a multi-part message in MIME format.

------=_NextPart_000_0206_01C9CA43.85B0DCF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

> 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
> 
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
------=_NextPart_000_0206_01C9CA43.85B0DCF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16830" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV>Tony -</DIV>
<DIV>&nbsp;</DIV>
<DIV>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. </DIV>
<DIV>&nbsp;</DIV>
<DIV>As to&nbsp;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. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards</DIV>
<DIV>&nbsp;</DIV>
<DIV>Carl Reed</DIV>
<DIV>CTO</DIV>
<DIV>OGC</DIV>
<DIV>&nbsp;</DIV>
<DIV>----- Original Message ----- 
<DIV>From: "Brian Rosen" &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt;</DIV>
<DIV>To: &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt;; &lt;<A 
href="mailto:[email-masked]">[email-masked]</A>&gt;</DIV>
<DIV>Sent: Friday, May 01, 2009 8:13 AM</DIV>
<DIV>Subject: Re: [earlywarning] global CAP community</DIV></DIV>
<DIV><BR></DIV>&gt; Thanks for the reference to X.1303.<BR>&gt; <BR>&gt; I think 
we need to confine our discussions on this list to "authority to<BR>&gt; 
citizen" (although that wording is changing), and our use of CAP will be<BR>&gt; 
limited to that context.<BR>&gt; <BR>&gt; Brian<BR>&gt; <BR>&gt; -----Original 
Message-----<BR>&gt; From: <A 
href="mailto:[email-masked]">[email-masked]</A> 
[mailto:[email-masked]]<BR>&gt; On Behalf Of Tony 
Rutkowski<BR>&gt; Sent: Thursday, April 30, 2009 5:54 PM<BR>&gt; To: <A 
href="mailto:[email-masked]">[email-masked]</A><BR>&gt; Subject: 
[earlywarning] global CAP community<BR>&gt; <BR>&gt; Hi all,<BR>&gt; <BR>&gt; 
Glad to see this working group get under way.&nbsp; There is a large and 
diverse<BR>&gt; global CAP community.<BR>&gt; <BR>&gt; Because the "authority" 
is often (but not always as Art notes) government in<BR>&gt; nature, or 
implemented pursuant to government requirements, the<BR>&gt; intergovernmental - 
industry organizations like ITU-T have been<BR>&gt; significantly 
involved.&nbsp; At the domestic level, legislation like the US WARN<BR>&gt; Act 
also affect these implementations.<BR>&gt; <BR>&gt; I have attached the ITU-T 
X-series version of CAP 1.1.&nbsp; It's a copy of the<BR>&gt; OASIS version, 
plus a translation into ASN.1 (for those who love that syntax<BR>&gt; or find it 
useful for compact applications).&nbsp; It's also what most<BR>&gt; governmental 
authorities will reference in most jurisdictions.<BR>&gt; <BR>&gt; As the 
rapporteur of working group Q.4/17 in ITU-T, I'll try and stay<BR>&gt; involved 
in this IETF WG and keep you apprised of things happening there and<BR>&gt; 
contribute to your work.<BR>&gt; <BR>&gt; Because CAP is flexible, extensible, 
and ubiquitous, it's worth considering<BR>&gt; its application in diverse 
contexts.&nbsp; For example, what would others think<BR>&gt; of using CAP in 
conjunction with dispersing cybersecurity forensics (think<BR>&gt; IODEF or 
CAPEX) or vulnerability<BR>&gt; information?&nbsp;&nbsp; If so, what is there 
some larger ontology that needs<BR>&gt; to be developed?<BR>&gt; <BR>&gt; 
cheers,<BR>&gt; tony<BR>&gt; <BR>&gt; --<BR>&gt; Tony Rutkowski | Netmagic 
Associates LLC | Ashburn VA | mob: +1 703.999.8270<BR>&gt; <BR>&gt; <BR>&gt; 
_______________________________________________<BR>&gt; earlywarning mailing 
list<BR>&gt; <A 
href="mailto:[email-masked]">[email-masked]</A><BR>&gt; <A 
href="https://www.ietf.org/mailman/listinfo/earlywarning">https://www.ietf.org/mailman/listinfo/earlywarning</A></BODY></HTML>

------=_NextPart_000_0206_01C9CA43.85B0DCF0--

From: "Brian Rosen" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Fri, 1 May 2009 10:13:37 -0400
Subject: Re: [earlywarning] global CAP community

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