Subject: [earlywarning] Updated Charter Text for ATOCA

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Mar 2010 17:36:49 -0400

.... a minor update

Authority to Citizen Alert (ATOCA)
==================================

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 authority to 
citizen
alerts to be sent, but it also presents new challenges. While there are
some existing layer 2 mechanisms for delivering alerts the work in this 
group
focuses on delivering alerts to IP endpoints only.

The general message pattern that this group is intended to address is the
sending of alerts from a set of pre-authorized agents (e.g., governmental
agencies) to a large population. The goal of this group is not to specify
how originators of alerts obtain authorization, but rather how a messaging
system can verify authorization and deliver message to the intended 
recipients.
A critical element of the work arethe 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 (e.g., audio and/or video), but the initial
work in the group is focused on small messages, which may be mechanically
rendered by thedevice 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 that
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. The group will explore how to support both opt-in and
opt-out at the level of communication protocols.

Another class of recipients that are in scope of the work are explicit
opt-in subscriptions which ask for alerts for a specified location.
An example of such a subscription would be 'send me alerts for
location x' (previously determined as the location of interest).
This work builds on existing IETF geopriv location work.

There are other efforts in other fora on alerts, which will be considered
in this effort.  For example, we expect to make use of the OASIS Common
Alerting Protocol (CAP) for the encoding of alerts.  ATIS, TIA, ITU-T, ETSI
and 3GPP also have alert efforts underway, and consultation with these
efforts will be undertaken to avoid unnecessary duplication of effort.
Of course, existing protocols for delivering messages (e.g., SIP)
will be the basis for the message delivery system of this working group.

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
 
TBD      Initial document for "Terminology and Framework" document.
         A starting point for this work is
         draft-norreys-ecrit-authority2individuals-requirements.
TBD      Initial document for conveying alerts in SIP
TBD      Initial document for subscribing to alerts using SIP
         A starting point for this work is draft-rosen-sipping-cap
TBD      Initial document for locating the alerting server for a geographic
         region. A starting point for this work is
         draft-rosen-ecrit-lost-early-warning.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 25 Mar 2010 03:13:24 +0100

What I am not seeing here is any separation of the problem from the one that cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami warning and Public Warning, exists and is not going to substantially change. The major limitation here is is length of message, and what does get transmitted will be very much dependent on that restriction.

Moreover I have heard from a number of governmental bodies that they are happy with that situation and are not envisaging further standardisation in that area outside of 3GPP.

So my view at the moment is that there is no point in IETF trying to address the scope of what is already specified in cell broadcast (from base station to end mobile).

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, March 24, 2010 9:37 PM
> To: [email-masked]
> Subject: [earlywarning] Updated Charter Text for ATOCA
> 
> .... a minor update
> 
> and television).  The Internet provides another way for 
> authority to citizen alerts to be sent, but it also presents 
> new challenges. While there are some existing layer 2 
> mechanisms for delivering alerts the work in this group 
> The general message pattern that this group is intended to 
> address is the sending of alerts from a set of pre-authorized 
> agents (e.g., governmental
> agencies) to a large population. The goal of this group is 
> not to specify how originators of alerts obtain 
> authorization, but rather how a messaging system can verify 
> authorization and deliver message to the intended recipients.
> A critical element of the work arethe 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 (e.g., audio and/or video), but the initial 
> work in the group is focused on small messages, which may be 
> mechanically rendered by thedevice 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 that 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. The group will explore 
> how to support both opt-in and opt-out at the level of 
> communication protocols.
> 
> Another class of recipients that are in scope of the work are 
> explicit opt-in subscriptions which ask for alerts for a 
> specified location.
> An example of such a subscription would be 'send me alerts 
> for location x' (previously determined as the location of interest).
> There are other efforts in other fora on alerts, which will 
> be considered in this effort.  For example, we expect to make 
> use of the OASIS Common Alerting Protocol (CAP) for the 
> encoding of alerts.  ATIS, TIA, ITU-T, ETSI and 3GPP also 
> have alert efforts underway, and consultation with these 
> Of course, existing protocols for delivering messages (e.g., 
> SIP) will be the basis for the message delivery system of 
> this working group.
> 
> 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
>  
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 24 Mar 2010 19:15:55 -0700

So Keith, do you think that emergency notifications should not be  
available on any other network?

Even if you use cell broadcast, there's a need for a distribution  
architecture, as the US CMAS demonstrates.

--Richard

On Mar 24, 2010, at 7:13 PM, DRAGE, Keith (Keith) wrote:

> What I am not seeing here is any separation of the problem from the  
> one that cell broadcast attempts to solve. Fundamentally, cell  
> broadcast, as exists on all GSM, UTRAN and E-UTRAN based cell phones  
> and is being used for Tsunami warning and Public Warning, exists and  
> is not going to substantially change. The major limitation here is  
> is length of message, and what does get transmitted will be very  
> much dependent on that restriction.
>
> Moreover I have heard from a number of governmental bodies that they  
> are happy with that situation and are not envisaging further  
> standardisation in that area outside of 3GPP.
>
> So my view at the moment is that there is no point in IETF trying to  
> address the scope of what is already specified in cell broadcast  
> (from base station to end mobile).
>
> regards
>
> Keith
>
>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Mar 2010 22:23:01 -0400

Hey Keith,

from the discussions in the past I understood that this is the SIP / 
XMPP delivery mechanism similar to the HTTP mechanism being in use today.
Example: http://www.weather.gov/alerts/

I hope that makes sense.

Ciao
Hannes

---

From: Marc Linsner <[email-masked]>
Date: Wed, 24 Mar 2010 23:29:20 -0700

Keith,

In-line....

On 3/24/10 7:13 PM, "DRAGE, Keith (Keith)" <[email-masked]>
wrote:

> What I am not seeing here is any separation of the problem from the one that
> cell broadcast attempts to solve. Fundamentally, cell broadcast, as exists on
> all GSM, UTRAN and E-UTRAN based cell phones and is being used for Tsunami
> warning and Public Warning, exists and is not going to substantially change.
> The major limitation here is is length of message, and what does get
> transmitted will be very much dependent on that restriction.

I thought the US CMAS required new handsets? (cell broadcast is not enabled
in the handset)

> 
> Moreover I have heard from a number of governmental bodies that they are happy
> with that situation and are not envisaging further standardisation in that
> area outside of 3GPP.
> 
> So my view at the moment is that there is no point in IETF trying to address
> the scope of what is already specified in cell broadcast (from base station to
> end mobile).

That's one way to get rid of WiMAX.  Don't warn WiMAX users when the next
Tsunami is coming.   :^)

-Marc-

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Mar 2010 10:38:35 -0400

Another thing to add is that the properties of the envisioned mechanism 
are different. Example: I want to receive warnings of a indicated location.

Furthermore, we also said that the link layer aspects are outside the 
scope and will not be considered. We focused on communication with 
IP-based endpoints and there is no talk about cell broadcast, etc.

Ciao
Hannes

Richard Barnes wrote:
>> is not going to substantially change. The major limitation here is is 
>> length of message, and what does get transmitted will be very much 
>> dependent on that restriction.
>>

---

From: [email-masked]
Date: Thu, 25 Mar 2010 11:28:41 -0400 (EDT)

Is this global best practice??

Carl

> What I am not seeing here is any separation of the problem from the one
> that cell broadcast attempts to solve. Fundamentally, cell broadcast, as
> exists on all GSM, UTRAN and E-UTRAN based cell phones and is being used
> for Tsunami warning and Public Warning, exists and is not going to
> substantially change. The major limitation here is is length of message,
> and what does get transmitted will be very much dependent on that
> restriction.
>
> Moreover I have heard from a number of governmental bodies that they are
> happy with that situation and are not envisaging further standardisation
> in that area outside of 3GPP.
>
> address the scope of what is already specified in cell broadcast (from
> base station to end mobile).
>
> regards
>
> Keith
>
>
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 26 Mar 2010 01:40:59 +0100

No I have not said that.

I am saying that it is not the solution for cellphone users using 3GPP technology.

Keith 

> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 2:16 AM
> To: DRAGE, Keith (Keith)
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [earlywarning] Updated Charter Text for ATOCA
> 
> So Keith, do you think that emergency notifications should 
> not be available on any other network?
> 
> Even if you use cell broadcast, there's a need for a 
> distribution architecture, as the US CMAS demonstrates.
> 
> --Richard
> 
> 
> 
> authority to 
> >> citizen alerts to be sent, but it also presents new 
> challenges. While 
> >> there are some existing layer 2 mechanisms for delivering 
> alerts the 
> >> work in this group focuses on delivering alerts to IP 
> endpoints only.
> >>
> address is 
> >> the sending of alerts from a set of pre-authorized agents (e.g., 
> >> governmental
> >> agencies) to a large population. The goal of this group is not to 
> >> specify how originators of alerts obtain authorization, but rather 
> >> how a messaging system can verify authorization and 
> deliver message 
> >> to the intended recipients.
> >> A critical element of the work arethe mechanisms that assure that 
> >> only authorized agents can send alerts.
> >>
> >> 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.
> information 
> >> which is intended to be consumed by humans, and some which is 
> >> intended to be consumed by automatons.
> than text 
> >> media (e.g., audio and/or video), but the initial work in 
> the group 
> >> is focused on small messages, which may be mechanically 
> rendered by 
> >> thedevice 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.
> >>
> 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 that 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. The group will 
> >> explore how to support both opt-in and opt-out at the level of 
> >> communication protocols.
> >>
> >> explicit opt-in subscriptions which ask for alerts for a specified 
> >> location.
> >> There are other efforts in other fora on alerts, which will be 
> >> considered in this effort.  For example, we expect to make 
> use of the 
> >> OASIS Common Alerting Protocol (CAP) for the encoding of alerts.  
> >> ATIS, TIA, ITU-T, ETSI and 3GPP also have alert efforts 
> underway, and 
> >> consultation with these efforts will be undertaken to avoid 
> >> unnecessary duplication of effort.
> >> SIP) will be the basis for the message delivery system of this 
> >> working group.
> >>
> >> 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
> >>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 26 Mar 2010 01:56:24 +0100

It is not such a simple answer as that. Cell broadcast has been available in phones from pretty much the stone age (GSM phase 2, i.e. the 1995 release). Particular values as now assigned are defined as settable by the network if appropriate, i.e. they can be turned on by the network. For unassigned values they can generally be settable by the user, up to the range of values supported on that phone. So if I have a phone where the MMI can handle message IDs above a 1000, the users themselves can be turned on for CMAS cell broadcasts. Some existing phones are able to do this, others are not.

Moreover phones conforming to release 8 and release 9 will generally tend to have much more flexibility in this area, as while message identifiers are still being assigned, the general knowledge that such message identifiers will exist and have to be handled will be well known by the phone manufacturers.

regards

Keith

> From: Marc Linsner [mailto:[email-masked]] 
> Sent: Thursday, March 25, 2010 6:29 AM
> To: DRAGE, Keith (Keith); [email-masked]
> > and is being used for Tsunami warning and Public Warning, 
> exists and is not going to substantially change.
> I thought the US CMAS required new handsets? (cell broadcast 
> is not enabled in the handset)
> 
> >