<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY RFC2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY RFC4474 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml'>
    <!ENTITY RFC4244 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4244.xml'>
    <!ENTITY RFC5598 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5598.xml'>
    <!ENTITY RFC5582 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5582.xml'>
    <!ENTITY I-D.rosen-ecrit-lost-early-warning PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosen-ecrit-lost-early-warning.xml'>
    ]>
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>
  <?rfc compact="yes" ?>
  <?rfc subcompact="yes" ?>
  
<rfc category="info" docName="draft-ietf-atoca-requirements-03.txt"
  ipr="trust200902">

  <front>
    <title abbrev="Exigent Communications">Requirements, Terminology and Framework for Exigent
      Communications</title>

    <author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
      <organization>Columbia University</organization>
      <address>
        <postal>
          <street>Department of Computer Science</street>
          <street>450 Computer Science Building</street>
          <city>New York</city>
          <region>NY</region>
          <code>10027</code>
          <country>US</country>
        </postal>
        <phone>+1 212 939 7004</phone>
        <email>hgs+ecrit@cs.columbia.edu</email>
        <uri>http://www.cs.columbia.edu</uri>
      </address>
      </author>
	  <author fullname="Steve Norreys" initials="S." surname="Norreys">
      <organization>BT Group</organization>
      <address>
      <postal>
        <street>1 London Road</street>
        <city>Brentwood</city>
        <region>Essex</region>
        <code>CM14 4QP</code>
        <country>UK</country>
      </postal>
      <phone>+44 1277 32 32 20</phone>
      <email>steve.norreys@bt.com</email>
    </address>
    </author>
        <author initials="B." surname="Rosen" fullname="Brian Rosen">
      <organization>NeuStar, Inc. </organization>
      <address>
        <postal>
          <street>470 Conrad Dr</street>
          <city>Mars</city>
          <region> PA </region>
          <code>16046 </code>
          <country>US </country>
        </postal>
        <phone> </phone>
        <email>br@brianrosen.net
        </email>
      </address>
    </author>
	    <author initials="H." surname="Tschofenig" fullname="Hannes Tschhofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
    <date year="2012"/>
    <area>RAI</area>
    <workgroup>ATOCA</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>Emergency</keyword>
    <keyword>Early Warning</keyword>
    <keyword>Exigent Communications</keyword>
    <abstract>
      <t>Before, during and after emergency situations various agencies need to provide information to a group of persons or to
        the public within a geographical area. While many aspects of such
        systems are specific to national or local jurisdictions, emergencies span such boundaries
        and notifications need to reach visitors from other jurisdictions.</t>
        
        <t>This document provides
          terminology, requirements and an architectural description for protocols exchanging alerts between IP-based end points.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction" anchor="introduction" toc="default">

      <section title="Classical Early Warning Situations">
        <t>During large-scale emergencies, public safety authorities need to reliably communicate
          with citizens in the affected areas, to provide warnings, indicate whether citizens should
          evacuate and how, and to dispel misinformation. Accurate information can reduce the impact
          of such emergencies. </t>
        <t>Traditionally, emergency alerting has used church bells, sirens, loudspeakers, radio and
          television to warn citizens and to provide information. However, techniques, such as
          sirens and bells, provide limited information content; loud speakers cover only very small
          areas and are often hard to understand, even for those not hearing impaired or fluent in
          the local language. Radio and television offer larger information volume, but are hard to
          target geographically and do not work well to address the “walking wounded” or other
          pedestrians. Both are not suitable for warnings, as many of those needing the information
          will not be listening or watching at any given time, particularly during work/school and
          sleep hours. </t>
        <t>This problem has been illustrated by the London underground bombing on July 7, 2006, as
          described in a government report <xref target="July2005"/>. The UK authorities could only
          use broadcast media and could not, for example, easily announce to the "walking wounded"
          where to assemble. </t>
      </section>

      <section title="Exigent Communications">

        <t>With the usage of the term 'Exigent Communications' this document aims to generalize the
          concept of conveying alerts to IP-based systems and at the same time to describe the
          actors that participate in the messaging communication. More precisely, exigent
          communications is defined as: </t>
        <t>
          <list style="empty">
            <t> Communication that requirs immediate action or remedy. Information about the reason
              for action and details about the steps that have to be taken are provided in the alert
                message.<vspace blankLines="1"/>
            </t>
            <t>An alert message (or warning message) is a cautionary advice about something imminent
              (especially imminent danger or other unpleasantness). In the context of exigent
              communication such an alert message refers to a future, ongoing or past event as the
              signaling exchange itself may relate to different stages of the lifecycle of the
              event. The alert message itself, and not the signaling protocol that convey it, provides sufficient
              context about the specific state of the lifecycle the alert message refers to.</t>
          </list>
        </t>

        <t>On a high level the communication occurs in two phases with the subscription phase sometimes being implicit:</t>
        <t>
          <list style="hanging">
            <t hangText="Subscription:"><vspace blankLines="1"/>In this step Recipients express their 
            interest in receiving certain types of alerts. This step happens prior to the actual delivery of the 
            alert. This expression of interest may be in form of an explicit communication step by having 
            the Receiver send a subscribe message (potentially with an indication of the type of 
            alerts they are interested in, the duration of the subscription and a number of other 
            indicators). For example, parents may want to be alerted of emergencies affecting the school 
            attended by their children and adult children may need to know about emergencies affecting 
            elderly parents. The subscription step may, however, also happen outside the Internet 
            communication infrastructure and instead by the Recipient signing a contract and thereby 
            agreeing to receive certain alerts. The Receiver, a software application, still needs to be configured 
			in such a way that incoming alerts are accepted, processed and passed up to the user interface alerting a Recipient. 
			Additionally, certain subscriptions may happen without 
            the Recipient's explicit consent and without the Receiver sending a subscription. For example, 
            a Tsunami flood alert may be delivered to all Receivers in case they are located in a specific 
            geographical area.
            <vspace blankLines="1"/>
            It is important to note that a protocol interaction initiated by the Receiver may need to take 
            place to subscribe to certain types of alerts. 
            In some other cases the subscription does not require such interaction from the Receiver. Orthogonal 
            to the need to have a protocol interaction is the question of opt-in vs. opt-out. Whether the Recipient, as 
			a human actor, needs to consent to receive certain types of alerts is a  
            policy decision that is largely outside the scope of a technical specification. 
            <vspace blankLines="1"/>
            </t>
            <t hangText="Alert Delivery:"><vspace blankLines="1"/> In this step the alert message is distributed 
            to one or multiple Receivers. The Receiver as a software module that presents the alert message to 
            the Recipient. The alert encoding is accomplished via the Common Alerting Protocol (CAP) and such an 
            alert message contains useful information needed for dealing with the imminent danger.</t>  
         </list>
        </t>
        <t>
         Note that an alert receiver software modules may not necessarily only be executed on end devices humans 
         typically carry around, such as mobile phones, Internet tablets, or laptops. Instead, alerts may 
         well be directly sent to displays in subway stations, or electronic bill boards. Furthermore, a software module that 
         obtains an alert may not necessarily need to interact with a human (as the Recipient) but may 
         instead use it as input to another process to trigger automated behaviors, such as closing vents 
         during a chemical spill or activating sirens or other warning systems in commercial buildings.
        </t>
        <t>This document provides terminology, requirements and an architectural description. Note that the 
        requirements focus on the communication protocols for subscription and alert delivery rather than on the 
        content of the alert message itself. With the usage of CAP these alert message content requirements are 
        delegated to the Authors and Originators of alerts.</t>
      </section>
    </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="terminology" title="Terminology">
      <t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
        "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
          <xref target="RFC2119"/>, with the important qualification that, unless otherwise stated,
        these terms apply to the design of a protocol conveying warning messages, not its
        implementation or application. </t>

<!--  

   <t>This section introduces useful terminology for alert delivery.</t>
   
    <t>The communication system used for the dissemination of alert messages builds on top of
        existing communication infrastructure. At the time of writing this underlying communication 
        infrastructure is the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). 
        These distributed services consist of a variety of
        actors playing different roles. On a high level we differentiate between the User, and the Message Handling Service (MHS) actors.
        We will describe them in more detail below.
     </t>
-->

        <t>Alert messages are typically produced by humans and consumed by users, Authors and 
           Recipients in our system, are the sources and sinks of alert messages.</t>
          
        <t> The Author is a human responsible for creating the content of the alert message, and to make a decision about the
            intended recipients, even though the exact list of recipients may be unknown to the
            Author at the time of writing the alert message. Instead, the recipients may, for example, be described in terms of a geographical region, or recipients with interest in a specific alert type.</t>

        <t> The Recipient is a consumer of the delivered alert message. 
            It is a human reading the alert message.</t>

        <t> From the user's perspective, all alert message transfer activities are performed by a
           monolithic Message Handling Service (MHS), even though the actual service can be provided
          by many independent organizations. The Message Handling Service (MHS) performs a single 
          end-to-end transfer of warning messages on behalf of the Author to reach the Recipients.</t>
          
        <t><xref target="actors-figure"/> shows the relationships among transfer participants.
          Transfers typically entail one
          or more Relays. However, direct delivery from the Originator to Receiver is possible.</t>
        <t>
          <figure anchor="actors-figure" title="Relationships Among MHS Actors">
            <artwork>
              <![CDATA[
    ++==========++                        ++===========++
    ||  Author  ||                        || Recipient ||
    ++====++====++                        ++===========++
          ||                                     /\
          ||                                     ||
          \/                                     ||
     +----------+                            +---++----+
     |          |                            |         |
   /-+----------+----------------------------+---------+---\
   | |          |     Message Handling       |         |   |
   | |Originator|       System (MHS)         |Receiver |   |
   | |          |                            |         |   |
   | +---++-----+                            +---------+   |
   |     ||                                      /\        |
   |     ||                                      ||        |
   |     \/                                      ||        |
   | +---------+         +---------+        +-+--++---+    |
   | |  Relay  +======-=>|  Relay  +=======>|  Relay  |    |
   | +---------+         +----++---+        +---------+    |
   |                          ||                           |
   |                          ||                           |
   |                          \/                           |
   |                     +---------+                       |
   |                     | Gateway +-->                    |
   |                     +---------+                       |
   \-------------------------------------------------------/

  Legend: === and || lines indicate primary (possibly
              indirect) transfers or roles
           ]]></artwork>
          </figure>
        </t>

        <section title="Originator">
          <t> The Originator ensures that a warning message is valid for transfer and then submits
            it to a Relay. A message is valid if it conforms to both communication and warning
            message encapsulation standards and local operational policies. The Originator can
            simply review the message for conformance and reject it if it finds errors, or it can
            create some or all of the necessary information. </t>
          <t> The Originator serves the Author and can be the same entity in absence of a human crafting alert messages.
          </t>
          <t> The Originator also performs any post-submission, Author-related administrative tasks
            associated with message transfer and delivery. Notably, these tasks pertain to sending
            error and delivery notices, and enforcing local policies. The Author creates the
            message, but the Originator handles any transmission issues with it. </t>
        </section>

        <section title="Relay">
          <t> The Relay performs MHS-level transfer-service routing and store-and-forward, by
            transmitting or retransmitting the message to its Recipients. The Relay may add history
            information (e.g., the SIP History Info <xref
              target="RFC4244"/> serves as a good example of the type of information that may be conveyed) or security related protection (e.g., as available with SIP
            Identity <xref target="RFC4474"/>) but does not modify the envelope information or the
            message content semantics.</t>
          <t> A Message Handling System (MHS) network consists of a set of Relays. This MHS network is
            typically above any underlying IP network but may involve technologies like IP multicast. </t>
        </section>

        <section title="Gateway">
          <t> A Gateway connects heterogeneous communication
            infrastructures and its purpose is to emulate a Relay and the closer it comes to this, the
            better. A Gateway needs the ability to modify message
            content. </t>
          <t> Differences between the different communication systems can be as small as minor
            syntax variations, but they usually encompass significant, semantic distinctions. Hence,
            the Relay function in a Gateway presents a significant design challenge, if the
            resulting performance is to be seen as nearly seamless. The challenge is to ensure
            end-to-end communication between the communication services, despite differences in
            their syntax and semantics. </t>
        </section>

        <section title="Receiver">
          <t> The Receiver performs final delivery and is typically responsible for ensuring that the
            appropriate user interface rendering is executed to interact with the Recipient. 
          </t>
        </section>

    </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->
   
   <section anchor="architecture" title="Framework">

   <t><xref target="introduction"/> describes the basic two steps that are involved with the alert message
   handling, namely subscription and alert delivery. From an architectural point of view there are, however,  
   a few variations possible depending on the characteristics of the subscription process and the style of 
   message delivery. This section offers more details on the communication architecture. Note that this document 
   does not mandate a specific deployment architecture. Instead it aims to illustrate how various different 
   protocol components fit together to present the reader with the 'big picture'.</t>
   
   <section title="Small Group Alert Delivery"> 
   
   <t>We start our description with the so-called "school closed" example where school authorities send alerts
   to all parents to notify them about the fact that their children cannot attend school. Parents subscribe to 
   these events when their children start attending the school and unsubscribe when they are finished with a
   particular school. The subscription procedures establishes some form of group communication by requiring an initial 
   registration procedure. Typically, alert messages stay within the closed group and are 
   not shared with others and alert message delivery is point-to-point with whatever 
   communication protocol is most suitable. This also means that the alerts reach those who have subscribed 
   rather than those who are in the vicinity of the school. The number of Recipients is typically rather small, 
   in the order of hundreds to several thousands. </t>
   
   <t>A variation of the "school closed" example is an explicit subscription model where no closed group pattern 
   exists. The main difference to the former case is in the authorization model. Consider a traveler who would like to receive weather alerts about a specific geographical region. He may have to manually search for how to subscribe to alerts for the desired region, potentially looking a different subscription points for different types of alerts. As an automated version of this procedure some form of discovery may help to find these subscription servers. The approach described in <xref target="I-D.rosen-ecrit-lost-early-warning"/> is one possible way to discovery such alert subscription 
   servers.
   The number of alert message Recipients is much larger than in the previous school example but will typically stay below the millions.
   </t>
   <t>These alert delivery examples are supported by a number of standardized communication protocols, such as SIP, XMPP, eMail, or RSS feeds.</t>
   
   <t>Note that there are optimizations for application layer alert delivery that mimic a multicast delivery with the help of Relays. However, a subscription is still necessary by the Receiver and the last-hop delivery of the alert is still done using 
   unicast transmission.</t>
   <t>While these two examples are important for many deployments they are not in focus of the ATOCA working group.</t>
   </section> 
   
   <section title="Mass Alert Delivery"> 
      
   <t>With the next category we move to a scenario where large number of Recipients shall be notified but 
   the subscription itself is implicit, as it is the case when persons are within a specific region that can 
   easily be reached by making use of broadcast link layer technologies. The placement of the actors from <xref target="actors-figure"/> is thereby important. An Originator distributes the alert message to Relays within the geographically affected area. Those Relays are located within Internet Service Providers so that multicast and broadcast communication protocols can be utilized for efficient distribution to a large number of Recipients within the affected area. When the alert message delivery has to be accomplished at the network layer then various requirements, such as the ability to traverse NATs and firewalls, have to be met by such a protocol. In this scenario the number of alert message Recipients is very large, potentially in the millions.
</t>
     
<t>As a variation of the previously described model consider an alert distribution with subscriptions to the alerts. <xref target="arch"/> shows the architecture.</t>

<t> A discovery server ensures that Receivers are able to learn the local alert distribution servers. Once a Receiver had discovered a local alert distribution server it sends a subscribe message to it. As a response, it will receive information about the security credentials the alert distribution server is going to use for subsequent alert delivery.</t>

<t>When an Author creates an alert for distribution the affected region will be indicated and so the alert will be sent to a Relay within the realm of the local alert distribution server and a notification will be sent to all the subscribed Receivers. 
</t>
        <t>
          <figure anchor="arch" title="Multicast/Broadcast Alert Delivery Mechanism with Explicit Subscription">
            <artwork>
              <![CDATA[
                        ,-----------.
                        | Discovery |
                        | Server    |
                        `...........'
                             :
                             :
 ,''''''''''''''''''''''''\  :
 | Local         ,------. |  :
 | Alert         | Local| |  :                ...................
 | Distribution  | Relay|.|..:   Alert        | +------+ Author |
 | Server        `......'-+<------------------+-|Sender|    O   |
 |                  |     |     Notification  | |      |   /|\  |
 '`'''''''''''''''''+''''''                   | +------+   / \  |
    ^        Alert  |                         `-----------------'
 Subscr.  +---------+
    |     |  Notification
    |     |
    |     V
 .....................
 | +------+ Recipient|
 | |Recvr |    O     |
 | |      |   /|\    |
 | +------+   / \    |
 `-------------------'
           ]]></artwork>
          </figure>
        </t>
   </section> 
  </section> 
  
     <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section title="Requirements" toc="default">

	  <t>The requirements listed below focus on the goal of mass alert distribution, which has to utilize multicast/broadcast communication for scalability reasons.  
		The requirements for point-to-point alert delivery are shown in <xref target="point-to-point-req"/> for completeness reasons only since the focus of the IETF ATOCA working group is on the multicast/broadcast alert delivery.</t>
		
      <section title="Requirements for the Discovery of an Alert Distribution Server">
        <t>
          <list style="hanging">
            <t hangText="Req-D1:"><vspace blankLines="1"/>
            The protocol solution MUST allow a receiver to discover a local alert distribution server, as discussed in 
             <xref target="architecture"/> and shown in <xref target="arch"/>, and to discover the necessary security credentials
			 for subsequent alert message distribution.
            </t>
          </list>
        </t>        
      </section> 
      
      <section title="Requirements for Multicast/Broadcast Alert Message Delivery">
        <t>
          <list style="hanging">
            <t hangText="Req-B1:">
            <vspace blankLines="1"/>The protocol solution MUST leverage multicast/broadcast technologies. This implies non-TCP transport and congestion control being considered.<vspace blankLines="1"/>
            </t>
            <t hangText="Req-B2:">
              <vspace blankLines="1"/>The protocol solution MUST allow delivery of messages
              simultaneously to a large audience. <vspace blankLines="1"/>
              </t>
            <t hangText="Req-B3:">
            <vspace blankLines="1"/>The protocol solution MUST be able to traverse firewalls and NATs as they are common in today's deployments.<!-- This typically requires a registration procedure and regular fresh messages to ensure that state at firealls and NATs is kept alive. --> 
            </t>
          </list>
        </t>
      </section>

    </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section title="IANA Considerations" toc="default">
      <t>This document does not require actions by IANA.</t>
    </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section title="Security Considerations" toc="default" anchor="section-security">
    
     <t><xref target="actors-figure"/> shows the actors for delivering an alert message assuming 
     that a prior subscription has taken place already. The desired security properties of an MHS 
     for conveying alerts will depend on the number of administrative domains involved. Each 
     administrative domain can have vastly different operating policies and trust-based 
     decision-making. One obvious example is the distinction between alert messages that are 
     exchanged within an closed group (such as alert messages received by parents affecting the 
     school attended by their children) and alert messages that are exchanged between independent 
     organizations (e.g., in case of large scale disasters). The rules for handling both types 
     of communication architectures tend to be quite different. That difference requires defining 
     the boundaries of each.</t>
     <t> Operation of communication systems that are used to convey alert messages are typically 
     carried out by different providers (or operators). Since each be in operated in an 
     independent administrative domain it is useful to consider administrative domain boundaries 
     in the description to facilitate discussion about designs, policies and operations that need 
     to distinguish between internal issues and external entities. Most significant is that the 
     entities communicating across administrative boundaries typically have the added burden of 
     enforcing organizational policies concerning external communications. For example, routing 
     alerts between administrative domains can create requirements, such as needing to route
     alert messages between organizational partners over specially trusted paths.</t>
     <t> The communication interactions are subject to the policies of that domain, which cover 
     concerns such as these:</t>
        <t>
          <list style="symbols">
            <t>Reliability</t>
            <t>Access control</t>
            <t>Accountability</t>
            <t>Content evaluation, adaptation, and modification</t>
          </list>
        </t>
        
    <t>Many communication systems make the distinction of administrative domains since they impact the 
    requirements on security solutions. However, with the distribution of alert messages a number of 
    additional security threats need to be addressed. Due to the nature of alerts it is quite likely 
    that end device implementations will offer user interface enhancements to get the Recipients 
    attention whenever an alert arrives, which is an attractive property for adversaries to exploit. 
    Below we list the most important threats any solution will have to deal with.
    </t>    
   <t>
    <list style="hanging"> 
       <t hangText="Originator Impersonation:">
              <vspace blankLines="1"/> An attacker could then conceivably attempt to impersonate
              the Originator of an alert message. This threat is particularly applicable to those 
              deployment environments where authorization decisions are based on the identity of 
              the Originator.<vspace blankLines="1"/>
       </t>     
       <t hangText="Alert Message Forgery:">
              <vspace blankLines="1"/> An attacker could forge or alter an alert message in order
              to convey custom messages to Recipients to get their immediate attention.
              <vspace blankLines="1"/>
       </t>
       <t hangText="Replay:">
              <vspace blankLines="1"/> An attacker could obtain previously distributed alert messages 
              and to replay them at a later time in the hope that Recipients could be tricked into 
              believing they are fresh. <vspace blankLines="1"/>
       </t>
       <t hangText="Unauthorized Distribution:">
              <vspace blankLines="1"/> When a Receiver receives an alert message it has to determine
              whether the Author distributing the alert messages is genuine to avoid accepting
              messages that are injected by malicious entities with the potential desire to at least
              get the immediate attention of the Recipient.<vspace blankLines="1"/>
       </t>
       <t hangText="Amplification Attack:">
              <vspace blankLines="1"/> An attacker may use the Message Handling System to inject a single 
              alert message for distribution that may then be instantly turned into potentially millions 
              of alert messages for distribution. 
       </t>
    </list> 
    </t>          
    <t>One important security challenge is related to authorization. When an alert message arrives at the 
    Receiver then certain security checks may need to be performed to ensure that the alert message meets 
    certain criteria. The final consumer of the alert message is, however, the Recipient - a human. From 
    a security point of view the work split between the Recipient and the Receiver for making the 
    authorization decision is important, particularly when an alert message is rejected due to a failed 
    security verification by the Receiver. False positives may be fatal but accepting every alert message 
    lowers the trustworthiness in the overall system.
    </t>
    </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section title="Acknowledgments" toc="default">

      <!-- 
      <t>This document reuses requirements captured outside the IETF, namely ETSI (with <xref
          target="ETSI-TS-102-182"/>), and the 3GPP (with <xref target="3GPP-TR-22.968"/>). We would
        like to thank the authors of these specifications for their work. Note, however, that only a
        small subset of the requirements have been reflected that do not relate to specific
        deployments, user interface aspects, detailed regulatory requirements, management and
        operational considerations, and non-IP specific technologies.</t>
        
        <t>We would like to thank Leopold Murhammer for his review in July 2007.</t>
        
      -->
      <t>This document re-uses text from <xref target="RFC5598"/>. The
        authors would like to thank Dave Crocker for his work.</t>
        
        
        <t>The authors would like to thank Martin Thomson, Carl Reed, Leopold Murhammer, and 
        Tony Rutkowski for their comments.</t>
        <t>At IETF#79 the following persons provided feedback leading to changes in this document: 
        Keith Drage, Scott Bradner, Ken Carberg, Keeping Li, Martin Thomson, Igor Faynberg, 
        Mark Wood, Peter Saint-Andre.</t>
		
    </section>

  </middle>

  <back>
    <references title="Normative References"> &RFC2119; &RFC5598; </references>

    <references title="Informative References"> &RFC4244; &RFC4474; &RFC5582; &I-D.rosen-ecrit-lost-early-warning; <reference
        anchor="July2005">
        <front>
          <title>Report of the 7 July Review Committee, ISBN 1 85261 878 7</title>
          <author fullname="Greater London Authority" initials=" " surname=" ">
            <organization>www.london.gov.uk</organization>
          </author>
          <date month="June" year="2006"/>
        </front>
        <seriesInfo name="(PDF document),"
          value="http://www.london.gov.uk/assembly/reports/7july/report.pdf"/>
      </reference>
      <!--      <reference anchor="ETSI-TS-102-182">
        <front>
          <title>ETSI TS 102 182, V1.2.1 (2006-12), Technical Specification, Emergency
            Communications (EMTEL); Requirements for communications from authorities/organizations
            to individuals, groups or the general public during emergencies</title>
          <author fullname=" " initials=" " surname=" ">
            <organization>ETSI</organization>
          </author>
          <date month="December" year="2006"/>
        </front>
        <format target="" type="PDF"/>
      </reference>        
        
      <reference anchor="3GPP-TR-22.968">
        <front>
          <title>3GPP TR 22.968, V1.0.0 (2007-04), 3rd Generation Partnership Project; Technical
            Specification Group Services and System Aspects; Study for requirements for a Public
            Warning System (PWS) Service (Release 8) </title>
          <author fullname=" " initials=" " surname=" ">
            <organization>ETSI</organization>
          </author>
          <date month="December" year="2006"/>
        </front>
        <format target="" type="PDF"/>
      </reference>
-->
    </references>
	
	<section anchor="point-to-point-req" title="Supplementary Requirements"> 
	
	
	      <section title="Requirements for Alert Subscription">
        <t>The requirements listed below refer to the alert subscription phase as it is used to tailor alert message delivery in a point-to-point alert delivery scenario. As noted in the main part of the document these requirements are not the main focus of the ATOCA work.</t>
        <t>
          <list style="hanging">
            <t hangText="Req-S1:"><vspace blankLines="1"/>The protocol solution MUST allow a potential 
            Recipient to indicate the language used by alert messages.
            <vspace blankLines="1"/>
            </t>
            <t hangText="Req-S2:"><vspace blankLines="1"/>The protocol solution MUST allow a potential 
            Recipient to express the geographical area it wants to receive alerts about.
            <vspace blankLines="1"/></t>
            <t hangText="Req-S3:"><vspace blankLines="1"/>The protocol solution MUST allow a potential 
            Recipient to indicate preferences about the type of alerts it wants to receive.
            <vspace blankLines="1"/></t>
            <t hangText="Req-S4:"><vspace blankLines="1"/>The protocol solution MUST allow a potential 
              Recipient to  express preference for certain media types. The support for different media 
              types depends on the content of the warning message but also impacts the communication protocol. 
              This functionality is, for example, useful for hearing and vision impaired persons.
            </t>
          </list>
        </t>
      </section>

	  
	  
	       <section title="Point-to-Point Alert Delivery">
        <t>
          <list style="hanging">
            <t hangText="Req-P1:">
            <vspace blankLines="1"/>The protocol solution MUST build on existing communication protocols
            and support the delivery of alert messages. Examples of such protocols are SIP, XMPP, Atom, eMail. <vspace blankLines="1"/>
            </t>
            <t hangText="Req-P2:">
              <vspace blankLines="1"/>The protocol solution MUST allow targeting notifications to
              specific subscribers.
            </t>
          </list> 
        </t>
       </section> 
	   
	</section> 
	
  </back>
</rfc>
