Subject: [earlywarning] Draft charter version

From: "Brian Rosen" <[email-masked]>
Date: Wed, 25 Mar 2009 11:50:03 -0400

Authorities need mechanisms to notify citizens and visitors of emergency
events.   Traditionally, they have done so with broadcast networks (radio
and television).  The Internet provides another way for citizen to authority
alerts to be sent, but it also presents new challenges.

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).  In situations of a
major emergency there could be scenarios where there are multiple alerts
generated that may require that a priority mechanism has to be implemented,
and this mechanism is  out of scope at his time.

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.

There are other efforts in other for a on alerts, which will be considered
in this effort.  For example, we expect to make use of the OASIS Common
Alerting Protocol.  ITU-T, ETSI and 3GPP also have alert efforts underway,
and consultation with these efforts will be undertaken to avoid unnecessary
duplication of effort.

The security implications of mechanisms that can send alerts to billions of
devices are profound, but the utility of the mechanism encourages us to face
the problems and solve them. 
 
Milestones
 
Requirements draft March 2010
 
Framework draft June 2010

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 19, 2009 11:53 AM
To: Rosen, Brian; [email-masked]
Subject: RE: Need a draft charter

Guys Please fell free to bash this about or even ignore
 
It is becoming increasingly clear that the ability to send an alerting
information to people when and emergency situation has arisen e.g. London
Bombing and Tsunami in South Asia. Where there has been a need identified to
send information to people affected by the emergency for example to direct
people to a designated area, either to a medical treatment centre or get to
higher ground. These alerts are intended to be generated by a special
alerting centre that may have been given the ability by the regional
authority, therefore who is able to receive this alert maybe constrained by
geographical locations. 
 
These alerts are sent and received using Internet technology however the
alert message should be independent of the actual technology being deployed
so the same alert should be sent to terminals/ UAs on a 3GPP/WiMAX networks
as to Ethernet private networks. It should also be noted that the alert
message should also be as independent as possible of the service
being deployed on the terminal so an alerting VoIP session should convey the
same message as a text message, within the limitations of each service. So
emoticons and flashing messages etc. cannot be expected to carry the same
level of urgency as a voice delivery. It should also be noted that the
actual message can only determined by the regional authority.
 
This group will show how the availability of location data and service
support information can be deployed by this service to send the alerting
communication. This information maybe required to setup the best route for
the particular service so it maybe useful to send all alerts by a single
route or to separate routes for data, voice and video alerts. This group
will also show how priority maybe deployed in this service so if an alert is
sent to a towns residents to prepare for a flood in two hours being 5 mins
late will not impact upon the situation, however being received 2 hours and
5 mins late will impact the situation. this group will show how it is
possible to receive alerts sent to a third party with the appropriate
registration to the service, this registration maybe of use in the language
translation of the alerts.
 
It is known that the ITU-T ESTI and 3GPP are also working in this general
area and this anticipates setting a close working relationship with them.
For any solution agreed must be useful and independent of any jurisdiction,
and it must be possible to use without a single central authority.
 
This working group cares about privacy and security concerns and will
address them within its documents.
 
regards
 
Steve

________________________________________
From: Rosen, Brian [mailto:[email-masked]] 
Sent: 18 March 2009 19:18
To: Norreys,SE,Steve,DMF R; Tschofenig, Hannes (NSN - FI/Espoo)
Subject: Need a draft charter
Who wants to create the first draft?  Need something to show at the BOF.

Brian

---

From: Art Botterell <[email-masked]>
Date: Wed, 25 Mar 2009 09:04:58 -0700

I'd also suggest that the idea of "authority" is moot unless the  
architecture provides for robust authentication.  So I'd suggest that  
an early task would be to develop an identity/authentication strategy,  
which in turn may reveal some additional requirements for consultation.

- Art

Art Botterell
Community Warning System Manager
Office of the Sheriff, Contra Costa County (CA) USA

On Mar 25, 2009, at 3/25/09 8:50 AM, Brian Rosen wrote:

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 25 Mar 2009 11:18:53 -0500

+1

At 11:04 AM 3/25/2009, Art Botterell wrote:
>>the Internet and private IP networks which humans may have "at hand"
>>to get
>>party.  An example of such a subscription would be "send me alerts
>>which are
>>sent too my daughter based on her location".
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 25 Mar 2009 12:20:29 -0400

Thanks Art.

The text:
> A critical element of the work are the mechanisms that assure that only
authorized agents can send  
> alerts.

Was intended to cover that.  Do you think it needs some more specificity?

BTW

I apologize for forwarding an email which has prior versions of the charter.
I only intended to send the latest.

Brian

-----Original Message-----
From: Art Botterell [mailto:[email-masked]] 
Sent: Wednesday, March 25, 2009 12:05 PM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [earlywarning] Draft charter version

- Art

Art Botterell

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 25 Mar 2009 11:54:16 -0500

I think that the existing BOF mike line exceeds the remaining duration of 
the BOF, so I didn't get up to say this, but I'm wondering if the charter 
should include any consideration of location-of-alert definitions for 
authority-to-citizen - I know that "location" in ECRIT makes sense for 
ECRIT, but I'm not as sure about "location" for ATOCA making sense (for 
sure), based on where we are today.

I think this is especially interesting if we have third-party alerts (to 
someone outside the affected area), and I'd like to accommodate that, if we 
could.

Thanks,

Spencer

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 25, 2009 10:50 AM
Subject: [earlywarning] Draft charter version

the Internet and private IP networks which humans may have "at hand" to get

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

Milestones

regards

Steve

Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 25 Mar 2009 12:07:11 -0500

Could we get a change bar-marked version of the next charter revision when 
it's available?

:-)

Thanks,

Spencer

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 25, 2009 10:50 AM
Subject: [earlywarning] Draft charter version

Milestones

regards

Steve

Brian

---

From: Art Botterell <[email-masked]>
Date: Wed, 25 Mar 2009 16:59:20 -0700

On Mar 25, 2009, at 3/25/09 9:20 AM, Brian Rosen wrote:
>> A critical element of the work are the mechanisms that assure that  
>> only authorized agents can send alerts.

Indeed, Brian, and I missed that.  But actually the problem has a bit  
more to it.

The term "authority" conflates three orthogonal considerations: power,  
knowledge and trust.  An actor can be designated an "authority" by  
dint of power or the endorsement of power; by way of particular  
knowledge (aka "expertise"), or by virtue of the trust of recipients  
(sometimes called "recognized authority.")  It's actually fairly rare  
for all three kinds of authority to exist equally in a single actor.

In single-operator networks it's power that matters.  But in peer-to- 
peer and federated systems things are more complicated, as each system  
operator and/or individual node may have his/her/its own ideas about  
whose authority, and what kind(s) of authority, will be recognized.   
(E.g., should a private individual be empowered to shout "fire!" in a  
burning theater?  Should a political boundary be a boundary to  
dissemination of information about a shared hazard? Etc.)

So the solution may or may not involve access control, depending on  
circumstances, but it will almost always involve, a) end-to-end  
authentication of messages, and b) discovery of the nature and roots  
of the sender's claims to authority.

- Art

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 26 Mar 2009 01:11:03 +0100

You seem to be taking this discussion in a direction it does not need to go.

All these early warning mechanisms that I have seen discussed so far all appear to be subject to national regulation. So surely it is the national regulator that defines who is an authority for early warnings posted in their region, not the IETF.

All IETF needs to ensure is that someone who has been designated as "the authority" has the appropriate protocol to ensure they can post, whereas those not so designated cannot.

Given the above, IETF does need to ensure that authority in country A cannot provide early warnings in country B, but I suspect that is implicit.

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Art Botterell
> Sent: Wednesday, March 25, 2009 11:59 PM
> To: [email-masked]
> Indeed, Brian, and I missed that.  But actually the problem 
> has a bit more to it.
> 
> The term "authority" conflates three orthogonal 
> considerations: power, knowledge and trust.  An actor can be 
> designated an "authority" by dint of power or the endorsement 
> of power; by way of particular knowledge (aka "expertise"), 
> or by virtue of the trust of recipients (sometimes called 
> "recognized authority.")  It's actually fairly rare for all 
> three kinds of authority to exist equally in a single actor.
> 
> In single-operator networks it's power that matters.  But in 
> peer-to- peer and federated systems things are more 
> complicated, as each system operator and/or individual node 
> may have his/her/its own ideas about  
> (E.g., should a private individual be empowered to shout 
> "fire!" in a burning theater?  Should a political boundary be 
> a boundary to dissemination of information about a shared 
> hazard? Etc.)
> 
> So the solution may or may not involve access control, 
> depending on circumstances, but it will almost always 
> involve, a) end-to-end authentication of messages, and b) 
> discovery of the nature and roots of the sender's claims to authority.
> 
> - Art
>

---

From: Art Botterell <[email-masked]>
Date: Wed, 25 Mar 2009 17:30:58 -0700

> You seem to be taking this discussion in a direction it does not  

Well, Keith, I work in the public warning field every day, and these  
are precisely the issues I deal with.  I understand that the realities  
of public warning practice aren't as simple as we might like, but I'd  
encourage you not to depart from the real world in search of a more  
convenient problem.

By no means are all warning systems under the control of some single  
national authority either in the US or elsewhere.  Many of them are  
operated by political subdivisions or by competing national agencies.   
Some are actually commercial.  And the tsunami threat, just to pick  
one, is inherent trans-national.  Hierarchy is a simplifying  
assumption that doesn't always hold; in fact, I think you'd be  
surprised how rarely things operate in a strictly hierarchical,  
authority-driven mode, even in government.

Again, sorry to be the one to point out that the Emperor has no  
credentials, but there it is.

- Art

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 25 Mar 2009 17:50:57 -0700

I agree with Art that we authority is not a good term. I believe that the
terminology I have introduced was much better. It focuses more on what we
want todo. 

I will update the requirements/terminology draft to reflect the terminology
I proposed in my architecture slide presentation. 

Ciao
Hannes 

>Sent: 25 March, 2009 16:59
>of power; by way of particular knowledge (aka "expertise"), or 
>by virtue of the trust of recipients (sometimes called 
>a boundary to dissemination of information about a shared hazard? Etc.)
>
>depending on circumstances, but it will almost always involve, 
>a) end-to-end authentication of messages, and b) discovery of 
>the nature and roots of the sender's claims to authority.
>
>- Art
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 26 Mar 2009 02:27:30 +0100

Before I start, I would note that I agree that "authority" may not be the best term to use, and we will need a definition in any case that goes with whatever term we decide to use.

Taking your substantive comments:

-	"Many of them are operated by political subdivisions or by competing national agencies."

Yes, not problem, but presumably it is up to the national government to control that, not the IETF.

-	"Some are actually commercial"

Not a problem for the IETF, it is up to the national government who they delegate to. I would prefer them not to delegate to the local pizza delivery chain because then it might get used for a problem I don't believe we should be solving in this charter.

-	"And the tsunami threat, just to pick one, is inherent trans-national."

Surely this is controlled by intergovernmental agreements outside the protocol, not by the IETF.

-	"Hierarchy is a simplifying assumption that doesn't always hold; in fact, I think you'd be surprised how rarely things operate in a strictly hierarchical, authority-driven mode, even in government."

Is there a need for hierarchy in the IETF work, or does that only apply to the governmental control?

regards

Keith

> Sent: Thursday, March 26, 2009 12:31 AM
> > You seem to be taking this discussion in a direction it 
> does not need 
> > to go.
> 
> Well, Keith, I work in the public warning field every day, 
> and these are precisely the issues I deal with.  I understand 
> that the realities of public warning practice aren't as 
> simple as we might like, but I'd encourage you not to depart 
> from the real world in search of a more convenient problem.
> 
> By no means are all warning systems under the control of some 
> single national authority either in the US or elsewhere.  
> Many of them are  
> Some are actually commercial.  And the tsunami threat, just 
> to pick one, is inherent trans-national.  Hierarchy is a 
> simplifying assumption that doesn't always hold; in fact, I 
> think you'd be surprised how rarely things operate in a 
> strictly hierarchical, authority-driven mode, even in government.
> 
> Again, sorry to be the one to point out that the Emperor has 
> no credentials, but there it is.
> 
> - Art
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Mar 2009 21:33:32 -0400

For the subscription model, filtering on the origin seems pretty easy,  
so the "authority" issue may not be as difficult. (I agree that the  
word "authority" is more confusing than helpful.)

On Mar 25, 2009, at 8:30 PM, Art Botterell wrote:

> are precisely the issues I deal with.  I understand that the  
> realities of public warning practice aren't as simple as we might  
> like, but I'd encourage you not to depart from the real world in  
> search of a more convenient problem.
>
> operated by political subdivisions or by competing national  
> agencies.  Some are actually commercial.  And the tsunami threat,  
> just to pick one, is inherent trans-national.  Hierarchy is a  
> simplifying assumption that doesn't always hold; in fact, I think  
> you'd be surprised how rarely things operate in a strictly  
> hierarchical, authority-driven mode, even in government.
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 25 Mar 2009 18:37:07 -0700

This discussion is about three layers too high up the stack. (+1 to the 
"'authority' is not helpful" group)

What are the technical properties of this "authority"?  What are the 
assumptions? Some candidates:
1. The authority can originate messages
2. The authority can define the destination of messages
3. The authority can dictate which endpoints MUST receive messages
4. The authority can control the network (e.g., routing paths)

IMHO, in the context of this discussion, an "authority" is a role, 
defined by the property that it is the entity that originates and 
targets messages (1 and 2 above).

--Richard

Art Botterell wrote:
> knowledge and trust.  An actor can be designated an "authority" by dint 
> of power or the endorsement of power; by way of particular knowledge 
> (aka "expertise"), or by virtue of the trust of recipients (sometimes 
> called "recognized authority.")  It's actually fairly rare for all three 
> kinds of authority to exist equally in a single actor.
> 
> peer-to-peer and federated systems things are more complicated, as each 
> system operator and/or individual node may have his/her/its own ideas 
> about whose authority, and what kind(s) of authority, will be 
> recognized.  (E.g., should a private individual be empowered to shout 
> "fire!" in a burning theater?  Should a political boundary be a boundary 
> to dissemination of information about a shared hazard? Etc.)
> 
> authentication of messages, and b) discovery of the nature and roots of 
> the sender's claims to authority.
> 
> - Art
>

---

From: Art Botterell <[email-masked]>
Date: Wed, 25 Mar 2009 19:26:52 -0700

On Mar 25, 2009, at 3/25/09 6:37 PM, Richard Barnes wrote:
> This discussion is about three layers too high up the stack. (+1 to  
> the "'authority' is not helpful" group)

Alas, without a grasp of the particular requirements at the  
application layer the problem down-stack pretty much reduces to "how  
do we move data around?" ;)

> targets messages (1 and 2 above).

But not even 1 and 2 necessarily reside in the same actor, e.g. in  
content-based routing or pub-sub syndication implementations.  It's  
one thing for an originator to assert its intent about where the  
message should go; where the message actually does go is frequently a  
very different matter, and that's frequently a Good Thing because  
originators aren't omniscient.

The key here, I'd suggest, will be to let go of any authoritarian  
preconceptions and get back in touch with our end-to-end heritage.   
Warning is no more a centralized activity than the Internet is a  
mainframe.

- Art

Art Botterell
Community Warning System Manager
Office of the Sheriff, Contra Costa County (CA) USA
(and architect of the Common Alerting Protocol)

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 26 Mar 2009 14:31:07 -0600

I would encourage the group to look at the extensive OGC member activity, 
including numerous deployed applications, in the EM alerting and warning 
domain. Some of the applications use CAP, others GeoRSS, and so forth. The 
following are some examples:

http://pirba.ristek.go.id/ictw/e-proceedings/PDF/3.%20DMS/DMS34DE%20haener_rainer.pdf
http://www.gitews.org/index.php?id=23&L=1
http://www.ncg.knaw.nl/Studiedagen/07SensorWeb/SWE_Haener.pdf (actually 
shows standards used etc)
http://slews.de/

Further, many other organizations such as NENA, PPW (Partnership for Public 
Warning), OASIS, and the W3C all have activities related to public warning. 
However, each organization is working a slightly different aspect of the 
problem. For example, the W3C incubator activity is dealing with semantics 
and ontologies related to emergency response and warning, OASIS has been 
focusing on payloads (such as CAP), and the OGC has been working both 
interfaces (such as Sensor Alert Service, Web Notification Service, and 
Event Notification Service) as well as encodings (GeoRSS GML).

Cheers

Carl

---

From: "Carl Reed" <[email-masked]>
Date: Thu, 26 Mar 2009 14:57:24 -0600

In terms of authentication/authorization, the OGC Members have approved a 
standard titled "GeoXACML. GeoXACML is a geospatial extension of the OASIS 
XACML standard. GeoXACML was done in collaboration with the chair of the 
XACML TC. GeoXACML is being implemented in a number of applications in 
Europe.

Cheers

Carl