Subject: [earlywarning] New Charter Text Proposal

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 05 May 2010 08:52:19 -0700

Hi all, 

as you all have seen it is a bit difficult to come up with a text that makes everyone happy. Please find an updated proposal below based on the recent discussions on the list. 

Ciao
Hannes

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

There are a variety of mechanisms that authorities have available to
notify citizens and visitors of emergency events. Traditionally, they
have done so with broadcast networks (radio and television). For commercial mobile devices, broadcasting services such as the Public Warning System (PWS), the Earthquake and Tsunami Warning System (ETWS), and the Commercial Mobile Alert System (CMAS) are standardized and are in the process of being deployed.  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 without impacting the layer
2 networks (e.g. causing congestion or denial of service). The goal of
this group is not to specify how originators of alerts obtain
authorization, but rather how an ATOCA system can verify that
authorization and deliver messages to the intended recipients. A
critical element of the work are the mechanisms that assure that only
those pre-authorized agents can send alerts via ATOCA, through an
interface to authorized alert distribution networks (e.g., iPAWS/DM-Open
in the U.S.).

This work is differentiated from and is not intended to replace other
alerting mechanisms (e.g., PWS, CMAS, ETWS), as the recipients of these
ATOCA 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 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 (defined by alert originator policy) has to be used.
The work on a resource priority mechanism is out of scope of the initial
charter, but may be revisited at a later date.

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 identified by the alert originator to be affected by the alert.  In
many jurisdictions, there are regulations that define whether
recipients/devices 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 and/or device
behavior. 

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

There are efforts in other fora on early warning, 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.  OGC,
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 and also to avoid unintentional negative impacts
on the layer 2 networks. 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. In addition, the potential
performance and congestion impacts to networks resulting from sending
alert information to billions of devices must be considered and solved
if such a service is implementable.

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. 
         A starting point for this work is draft-rosen-sipping-cap
TBD	  Initial document for conveying alerts through point to
multipoint methods.
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.
TBD	  Initial document addressing security, performance and congestion issues for alert distribution.
TBD	  Initial document for interfacing existing alert
distribution systems.

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 May 2010 12:40:59 -0700

Please provide your feedback at latest by 28th May 2010.
Thanks.

Ciao
Hannes

Hannes Tschofenig wrote:
> Hi all,
> as you all have seen it is a bit difficult to come up with a text that 
> makes everyone happy. Please find an updated proposal below based on 
> the recent discussions on the list.
> Ciao
> Hannes
>
>
> have done so with broadcast networks (radio and television). For 
> commercial mobile devices, broadcasting services such as the Public 
> Warning System (PWS), the Earthquake and Tsunami Warning System 
> (ETWS), and the Commercial Mobile Alert System (CMAS) are standardized 
> and are in the process of being deployed.  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
> TBD      Initial document for conveying alerts in SIP.         A 
> starting point for this work is draft-rosen-sipping-cap
> geographic region.         A starting point for this work is
> TBD      Initial document addressing security, performance and 
> congestion issues for alert distribution.
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

---

From: Richard Barnes <[email-masked]>
Date: Mon, 10 May 2010 20:49:23 -0400

I think this version of the charter is fine.
--Richard

On May 10, 2010, at 3:40 PM, Hannes Tschofenig wrote:

>> as you all have seen it is a bit difficult to come up with a text  
>> that makes everyone happy. Please find an updated proposal below  
>> based on the recent discussions on the list.
>> Ciao
>> Hannes
>>
>>
>> (ETWS), and the Commercial Mobile Alert System (CMAS) are  
>> standardized and are in the process of being deployed.  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
>> TBD      Initial document for "Terminology and Framework"  
>> document.         A starting point for this work is

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 11 May 2010 11:35:35 +0800

Looks fine.  One minor comment and a few suggestions on paragraph breaks (WallOfText is difficult to read ;).

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:earlywarning-
> [email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Thursday, 6 May 2010 1:52 AM
> To: [email-masked]
> Subject: [earlywarning] New Charter Text Proposal
> 
> Hi all,
> 
> Warning System (PWS), the Earthquake and Tsunami Warning System (ETWS),
> and the Commercial Mobile Alert System (CMAS) are standardized and are
> in the process of being deployed.  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
> governmental agencies) to a large population without impacting the
> layer 2 networks 

Why restrict this to layer 2?  It seems evident that there are implications at other layers that are equally worthy of consideration.

Suggest: without adverse effect on networks

> (e.g. causing congestion or denial of service).

Break paragraph here.

> The goal of
> interface to authorized alert distribution networks (e.g., iPAWS/DM-
> Open in the U.S.).
> 
> consumed by automatons.  

Break here too.

> Ideally, the alerts would contain, or refer to
> example).

And here.

> In situations of a major emergency there could be scenarios
> area identified by the alert originator to be affected by the alert.
> In many jurisdictions, there are regulations that define whether
> opt-in and opt-out at the level of communication protocols and/or
> device behavior.
> 
> determined as the location of interest). This work may build on
> existing IETF geopriv location work.

s/geopriv/GEOPRIV/

> on the layer 2 networks.

As above, suggest: s/layer 2//

> Of course, existing protocols for delivering

---

From: Marc Linsner <[email-masked]>
Date: Tue, 11 May 2010 06:49:27 -0400

Works for me.

-Marc-

---

From: ken carlberg <[email-masked]>
Date: Tue, 11 May 2010 09:06:44 -0400

works for me as well.

-ken

On May 10, 2010, at 8:49 PM, Richard Barnes wrote:

>>> TBD      Initial document for "Terminology and Framework" document.         A starting point for this work is
>>> TBD      Initial document for conveying alerts in SIP.         A starting point for this work is draft-rosen-sipping-cap

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 May 2010 09:12:16 -0400

Okay with me

On 5/5/10 11:52 AM, "Hannes Tschofenig" <[email-masked]> wrote:

> Hi all, 
> 
> as you all have seen it is a bit difficult to come up with a text that makes
> everyone happy. Please find an updated proposal below based on the recent
> discussions on the list.
> 
> Ciao
> Hannes
> 
> 
> have done so with broadcast networks (radio and television). For commercial
> mobile devices, broadcasting services such as the Public Warning System (PWS),
> the Earthquake and Tsunami Warning System (ETWS), and the Commercial Mobile
> Alert System (CMAS) are standardized and are in the process of being deployed.
> 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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 11 May 2010 16:42:40 -0500

Hannes

a few comments, edits and suggestions...

At 10:35 PM 5/10/2010, Thomson, Martin wrote:
>Looks fine.  One minor comment and a few suggestions on paragraph 
>breaks (WallOfText is difficult to read ;).
>
>--Martin
>
> > notify citizens and visitors of

s/of/during

>emergency events. Traditionally, they
> > in the process of being deployed

s/the process of being deployed/various stages of deployment

>.  The Internet provides another way
> > for authority to citizen

shouldn't this be "authority-to-citizen" (without the quotes, but 
still hyphenated)?

>alerts to be sent, but it also presents new
> > mechanisms for delivering alerts

"," (comma)

>  the work in this group focuses on

I think this reads better -- but I'm not that rabid about this change
s/IP endpoints only/IP only endpoints

>Why restrict this to layer 2?  It seems evident that there are 
>implications at other layers that are equally worthy of consideration.

to this question -- I think this is to address AT&T's CMAS concern.

I'm ok with this scope limitation on the impact of L2 networks.

> > (e.g. causing congestion or denial of service).

I agree with this break

> > critical element of the work are the mechanisms that assure that

suggest removing the second "that" here

>only
> > This work

s/This work/The ATOCA effort

>is differentiated from and is not intended to replace other

remove above "these" at the end of this sentence

> > ATOCA alerts are the wide range of devices connected to the Internet

add "of" or "various" to this sentence here

> > intended to be consumed by humans, and some which is intended to be

agreed

> > work in the group is focused on small messages,

I'm not sure I agree with this limitation -- given that everyone here 
has read about CAP for a number of years and is well aware that it 
readily allows URIs to audio and video alerts that can easily be 
displayed within a device's browser.

>which may be

May I suggest this replacement paragraph instead of what's 
immediately above (between Martin's two paragraph breaks):

"Ideally, the alerts would contain, or refer to media other than text 
media (e.g., audio and/or video). The initial work in the group is 
focused on small messages, which may be mechanically rendered by the 
device in other forms (text to speech for example), and may include 
rich media if the additional complexity involved can be kept to a minimum."

> > area identified by the alert originator to be affected by the alert.

s/alert/emergency event

> > capability, but the protocols we

s/we/ATOCA

>will define will include both opt-in

What about how the alerts are distributed to the distribution servers 
(kinda like LoST-sync specified)?  Is this in or out of scope? There 
is a milestone already, but no charter text that I remember reading.

James