Subject: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)

From: IESG Secretary <[email-masked]>
Date: Tue, 20 Jul 2010 10:00:01 -0700 (PDT)

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area.  The IESG has not made any determination as yet.
The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG mailing
list ([email-masked]) by Tuesday, July 27, 2010.                          

Authority to Citizen Alert (ATOCA)
----------------------------------
Current Status: Proposed Working Group

Last Modified: 2010-07-15

Chairs(s)
TBD

Real-time Applications and Infrastructure Area Directors:
   Gonzalo Camarillo <[email-masked]>
   Robert Sparks <[email-masked]>

Real-time Applications and Infrastructure Area Advisor:
   Robert Sparks <[email-masked]>

Mailing Lists:
  General Discussion: [email-masked]
  To Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>
  Archive: <http://www.ietf.org/mail-archive/web/earlywarning>

Real-time Applications and Infrastructure Area Advisor:
   Robert Sparks <[email-masked]>

Description of Working Group:

There are a variety of mechanisms that authorities have available to
notify citizens and visitors during 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 various stages of deployment.  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
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
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.).

The ATOCA effort is differentiated from and is not intended to
replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the
recipients of ATOCA alerts are the wide range of devices connected to
the Internet and various 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). 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). Future work in
the group may investigate rich media.

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 emergency event.  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 ATOCA 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 networks. Of course,
existing protocols for delivering messages (e.g., SIP, XMPP, or SMTP) 
will be the basis for the message delivery system of this working group.
Any service discovery mechanisms defined by the group are expected
to reuse existing discovery frameworks.

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. To avoid
manual configuration of servers distributing alerts a discovery
mechanism will be specified.

NOTE FOR CHARTER REVIEW (this section to be removed before charter
approval): Some early drafts related to this proposed work are
* draft-norreys-ecrit-authority2individuals-requirements
* draft-rosen-ecrit-lost-early-warning
* draft-rosen-atoca-server-discovery
* draft-rosen-atoca-cap
* draft-schulzrinne-atoca-requirements

Goals and Milestones
		  
Jan 2011  Submit "Terminology and Framework" to the IESG for 
         publication as Informational 
		  
Apr 2011  Submit "Addressing security, performance and
         congestion issues for alert distribution" to the 
         IESG for publication as Informational 

Apr 2011 Submit conveying point-to-point Authority to Citizen Alerts
        to the IESG for publication as Proposed Standard

May 2011  Submit "Discovering alerting servers" to the IESG for 
         publication as Proposed Standard
		  
Jun 2011 Submit conveying point-to-multipoint Authority to Citizen 
        Alerts to the IESG for publication as Proposed Standard
		  
Aug 2011 Submit "Considerations for interworking with currently 
        deployed alert distribution systems" to the IESG for 
        publication as Informational

---

From: ken carlberg <[email-masked]>
Date: Tue, 20 Jul 2010 17:56:57 -0400

Hi,

> list ([email-masked]) by Tuesday, July 27, 2010.                

given the wording of the above, the proposed working group was at least discussed internally within the IESG.  Would it be possible to get a summary of the issues/concerns expressed by the IESG?  It would be helpful to have a perspective to focus comments from the masses, and avoid the generic and uninformative "I support this effort becoming a working group" statement

kindest regards,

-ken

---

From: Marc Linsner <[email-masked]>
Date: Tue, 20 Jul 2010 18:16:00 -0400

Ken,

Did you see Robert's email:

http://www.ietf.org/mail-archive/web/earlywarning/current/msg00323.html

-Marc-

On 7/20/10 5:56 PM, "ken carlberg" <[email-masked]> wrote:

> given the wording of the above, the proposed working group was at least
> discussed internally within the IESG.  Would it be possible to get a summary
> of the issues/concerns expressed by the IESG?  It would be helpful to have a
> perspective to focus comments from the masses, and avoid the generic and
> uninformative "I support this effort becoming a working group" statement
> 
> kindest regards,
> 
> -ken
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

---

From: ken carlberg <[email-masked]>
Date: Tue, 20 Jul 2010 18:25:09 -0400

Hmmmm,  I thought that there were more concerns than that stated by Robert given the comment in the announcement stating "The IESG has not made any determination as yet", which seemed to run contrary to Robert's statement that "the ATOCA charter was approved".  

If I mis-read things, then I'll subscribe to those famous words of Rosana Rosana Dana....."never mind" :-)

cheers,

-ken

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 20 Jul 2010 16:29:53 -0600

The process is:

1. Internal IESG review

2. Send it out for external review

3. Final determination (based on external review)

We're at Step 2. :)

On 7/20/10 4:25 PM, ken carlberg wrote:
> Hmmmm,  I thought that there were more concerns than that stated by
> Robert given the comment in the announcement stating "The IESG has
> not made any determination as yet", which seemed to run contrary to
> Robert's statement that "the ATOCA charter was approved".
> 
-Marc-
>>>> A new IETF working group has been proposed in the Real-time
>>>> Applications and Infrastructure Area.  The IESG has not made
>>>> any determination as yet. The following draft charter was
>>>> submitted, and is provided for informational purposes only.
>>>> Please send your comments to the IESG mailing list
>>>> ([email-masked]) by Tuesday, July 27, 2010.
>>> 
>>> given the wording of the above, the proposed working group was at
>>> least discussed internally within the IESG.  Would it be possible
>>> to get a summary of the issues/concerns expressed by the IESG?
>>> It would be helpful to have a perspective to focus comments from
>>> the masses, and avoid the generic and uninformative "I support
>>> this effort becoming a working group" statement
>>> 
>>> kindest regards,
>>> 
>>> -ken
>>> 
>>> _______________________________________________ earlywarning
>>> mailing list [email-masked]

---

From: Robert Sparks <[email-masked]>
Date: Tue, 20 Jul 2010 17:35:52 -0500

Hi Ken -

Sorry if I introduced confusion - I indicated that the charter was approved for external review - the IETF as a whole
and any other bodies watching the new-work mailing list are asked to review and comment. The actual formation
of the group is still under consideration.

RjS

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 21 Jul 2010 10:38:52 +0200

Hi,

yes, the process is not clear for many people. There is a thread about
this in the RAI list:

http://www.ietf.org/mail-archive/web/rai/current/msg00889.html

Cheers,

Gonzalo

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 26 Jul 2010 08:23:02 +0200

I notice it says SIP is one of the candidates for this.

Surely if SIP is to be used, I assume that criteria for selection of a mechanims applies as has already been detailed for instant messaging.

Has someone already evaluated the criteria for warnings, and therefore verfied that they are appropriate for transport in SIP messages, as opposed to using MRCP.

I know the ETWS / CMA alerts all fit into 170 odd characters by definition, because that is the maximum length of the transport, but even the alert identity information I have seen discussed elsewhere, and proposed for use in this protocol, seems to be an OID and could be many 10s of characters in its own right. 

So all I am asking is whether the messaging criteria have already been evaluated and been found suitable for SIP transport, as opposed to a separate media stream using MRCP.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of IESG Secretary
> Sent: Tuesday, July 20, 2010 6:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [earlywarning] WG Review: Authority to Citizen Alert (ATOCA)
> 
> any determination as yet.
> The following draft charter was submitted, and is provided 
> for informational purposes only. Please send your comments to 
> the IESG mailing
> There are a variety of mechanisms that authorities have 
> available to notify citizens and visitors during 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 
> standardized and are in various stages of deployment.  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 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 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.).
> 
> The ATOCA effort is differentiated from and is not intended 
> to replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), 
> as the recipients of ATOCA alerts are the wide range of 
> devices connected to the Internet and various 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). 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). Future work in the group may investigate 
> rich media.
> 
> 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.
> 
> 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 emergency event.  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 ATOCA 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.
> 
> 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).
> 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 networks. Of course, existing protocols for delivering 
> messages (e.g., SIP, XMPP, or SMTP) will be the basis for the 
> message delivery system of this working group.
> Any service discovery mechanisms defined by the group are 
> expected to reuse existing discovery frameworks.
> 
> 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. To avoid manual configuration of 
> servers distributing alerts a discovery mechanism will be specified.
>