IETF ATOCA Working Group

Provisional Charter for IETF Authority to Citizen Alert (ATOCA) Working Group

Update August 20, 2010: The IESG formally announced ATOCA: "A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Working Group: Authority to Citizen Alert (ATOCA) See the Status Pages and List Archive.

[IESG Secretary Announcement for Proposed Working Group in the IETF Real-time Applications and Infrastructure Area: WG Review: Authority to Citizen Alert (ATOCA); Earlier updated Charter Proposal, July 15, 2010: ATOCA Proposed Charter]

Early ATOCA Working Group Drafts:

Requirements, Terminology and Framework for Exigent Communications [HTML]

Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP) [HTML]

LoST-based Discovery of Servers Distributing Alerts [HTML]

A Uniform Resource Name (URN) for Early Warning Emergency Services and Location-to-Service Translation (LoST) Protocol Usage [HTML]

Authority to Citizen Alert (ATOCA)

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

Goals and Milestones

Aug 2010 Submit "Terminology and Framework" document as initial WG item. A starting point for this work is "Requirements, Terminology and Framework for Exigent Communications" in draft-norreys-ecrit-authority2individuals-requirements.

Sep 2010 Submit "Conveying alerts in SIP" document as initial WG item. A starting point for this work is "Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP) in draft-rosen-sipping-cap.

Dec 2010 Submit "Conveying alerts through point-to-multipoint methods" document as initial WG item.

Oct 2010 Submit "Discovering alerting servers" document as initial WG item. A starting point for this work is "A Uniform Resource Name (URN) for Early Warning Emergency Services and Location-to-Service Translation (LoST) Protocol Usage" in draft-rosen-ecrit-lost-early-warning.

Dec 2010 Submit "Addressing security, performance and congestion issues for alert distribution" document as initial WG item.

Jan 2011 Submit "Interfacing existing alert distribution systems" document as initial WG item. Jan 2011 Submit "Terminology and Framework" to the IESG for consideration as an Informational RFC. Mar 2011 Submit "Conveying alerts in SIP" to the IESG for consideration as a Standards Track RFC.

May 2011 Submit "Conveying alerts through point-to-multipoint methods" to the IESG for consideration as an Informational RFC. Apr 2011 Submit "Discovering alerting servers" to the IESG for consideration as a Standards Track RFC. Jun 2011 Submit "Addressing security, performance and congestion issues for alert distribution" to the IESG for consideration as an Informational RFC. Aug 2011 Submit "Interfacing existing alert distribution systems" to the IESG for consideration as an Informational RFC.

Source

Posted:  http://www.ietf.org/mail-archive/web/earlywarning/current/msg00313.html
Date:         Wed, 02 Jun 2010 19:28:50 +0200
From:         "Hannes Tschofenig" Hannes.Tschofenig@gmx.net
Message-ID:   20100602172850.269380@gmx.net
Cc:           earlywarning@ietf.org
Subject:      ATOCA Charter Discussion Finished
List-Archive: http://www.ietf.org/mail-archive/web/earlywarning

Prepared by Robin Cover for The XML Cover Pages archive.

SEARCH Advanced Search ABOUT Site Map CP RSS Channel Contact Us Sponsoring CP About Our Sponsors NEWS Cover Stories Articles & Papers Press Releases CORE STANDARDS XML SGML Schemas XSL/XSLT/XPath XLink XML Query CSS SVG TECHNOLOGY REPORTS XML Applications General Apps Government Apps Academic Apps EVENTS LIBRARY Introductions FAQs Bibliography Technology and Society Semantics Tech Topics Software Related Standards Historic	IETF ATOCA Working Group Provisional Charter for IETF Authority to Citizen Alert (ATOCA) Working Group Update August 20, 2010: The IESG formally announced ATOCA: "A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Working Group: Authority to Citizen Alert (ATOCA) See the Status Pages and List Archive. [IESG Secretary Announcement for Proposed Working Group in the IETF Real-time Applications and Infrastructure Area: WG Review: Authority to Citizen Alert (ATOCA); Earlier updated Charter Proposal, July 15, 2010: ATOCA Proposed Charter] Early ATOCA Working Group Drafts: Requirements, Terminology and Framework for Exigent Communications [HTML] Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP) [HTML] LoST-based Discovery of Servers Distributing Alerts [HTML] A Uniform Resource Name (URN) for Early Warning Emergency Services and Location-to-Service Translation (LoST) Protocol Usage [HTML] Authority to Citizen Alert (ATOCA) 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) 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. To avoid manual configuration of servers distributing alerts a discovery mechanism will be specified. Goals and Milestones Aug 2010 Submit "Terminology and Framework" document as initial WG item. A starting point for this work is "Requirements, Terminology and Framework for Exigent Communications" in draft-norreys-ecrit-authority2individuals-requirements. Sep 2010 Submit "Conveying alerts in SIP" document as initial WG item. A starting point for this work is "Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP) in draft-rosen-sipping-cap. Dec 2010 Submit "Conveying alerts through point-to-multipoint methods" document as initial WG item. Oct 2010 Submit "Discovering alerting servers" document as initial WG item. A starting point for this work is "A Uniform Resource Name (URN) for Early Warning Emergency Services and Location-to-Service Translation (LoST) Protocol Usage" in draft-rosen-ecrit-lost-early-warning. Dec 2010 Submit "Addressing security, performance and congestion issues for alert distribution" document as initial WG item. Jan 2011 Submit "Interfacing existing alert distribution systems" document as initial WG item. Jan 2011 Submit "Terminology and Framework" to the IESG for consideration as an Informational RFC. Mar 2011 Submit "Conveying alerts in SIP" to the IESG for consideration as a Standards Track RFC. May 2011 Submit "Conveying alerts through point-to-multipoint methods" to the IESG for consideration as an Informational RFC. Apr 2011 Submit "Discovering alerting servers" to the IESG for consideration as a Standards Track RFC. Jun 2011 Submit "Addressing security, performance and congestion issues for alert distribution" to the IESG for consideration as an Informational RFC. Aug 2011 Submit "Interfacing existing alert distribution systems" to the IESG for consideration as an Informational RFC. Source Posted: http://www.ietf.org/mail-archive/web/earlywarning/current/msg00313.html Date: Wed, 02 Jun 2010 19:28:50 +0200 From: "Hannes Tschofenig" Hannes.Tschofenig@gmx.net Message-ID: 20100602172850.269380@gmx.net Cc: earlywarning@ietf.org Subject: ATOCA Charter Discussion Finished List-Archive: http://www.ietf.org/mail-archive/web/earlywarning Prepared by Robin Cover for The XML Cover Pages archive.