wdiff draft-norreys-ecrit-authority2individuals-requirements-02.txt draft-norreys-ecrit-authority2individuals-requirements-03.txt

ECRIT S. Norreys
Internet-Draft BT Group
Intended status: Informational H. Tschofenig
Expires: September 9, 2009 January 14, 2010 Nokia Siemens Networks
H. Schulzrinne
Columbia University
March 8,
July 13, 2009

Authority-to-Individuals Communication for Emergency Situations:

Requirements, Terminology and Architecture
draft-norreys-ecrit-authority2individuals-requirements-02.txt Framework for Exigent Communications
draft-norreys-ecrit-authority2individuals-requirements-03.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 9, 2009. January 14, 2010.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Abstract

Public safety

Various agencies need to provide information to the general restricted group
of persons or even to the generic public before and before, during large-scale emergencies. and after
emergency situations. 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. This document summarizes requirements for protocols
to alert individuals within a defined
geographic area. allow alerts to be conveyed to IP-based end points.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Classical Early Warning Situations . . . . . . . . . . . . 3
1.2. Exigent Communications . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architectures Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 5
3.1. User Actors . . . . . . . . . . . . . 5
3.1. Closed Warning Notification Provider and Aggregator
Groups . . . . . . . . . . 5
3.1.1. Author . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Open Communication between Warning Notification
Provider and Aggregator
3.1.2. Recipient . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Open Communication towards Warning Notification
Customers
3.1.3. Return Handler . . . . . . . . . . . . . . . . . . . . 6
3.1.4. Mediator . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Message Handling Service (MHS) Actors . . . . . . . . . . 7
3.2.1. Originator . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Notification Population
3.2.2. Relay . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. Gateway . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.4. Receiver . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Administrative Actors . . . . . . . . . . . . . . . . . . 10
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 10
4.1. Communication Model Independent Requirements . . . . . . . 11
4.2. Requirements for a Subscription Model . . . . . . . . . . 11
4.3. Requirements for a Push Communication Model . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 13
6. Security considerations . . . . . . . . . . . . . . . . . . . 11 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 13

1. Introduction

1.1. Classical Early Warning Situations

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.

Traditionally, emergency alerting has used church bells, sirens,
loudspeakers, radio and television to warn citizens and to provide
information. However, techniques techniques, such as sirens and bells 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.

This problem has recently been illustrated by the London underground bombing
on July 7, 2006, as described in a government report [ref]. [July2005]. The
UK authorities could only use broadcast media and could not, for
example, easily announce to the "walking wounded" where to assemble.

This

1.2. Exigent Communications

With the usage of the term 'Exigent Communications' this document summarizes key requirements for IP-based protocols
aims to
enhance generalize the concept of conveying alerts to IP-based
systems and complement existing authority-to-citizen warning systems.
These protocols may either directly reach at the citizen or may be used same time to trigger more traditional alerts, such as, among many others,
displays re-define the actors that participate
in subway stations, electronic bill boards, or SMS.

Public safety authorities need to reach, with an appropriate message,
as many affected people as possible within the area impacted by messaging communication. More precisely, exigent
communications is defined as:

Communication that requirs immediate action or remedy.
Information about the
emergency, including not just residents, but also workers reason for action and
travelers who may only details about the
steps that have to be taken are provided in the area temporarily. alert message.

An alert message (or warning message) is a cautionary advice about
something imminent (especially imminent danger or other
unpleasantness). In addition, people around the immediately affected area should be
able to receive information and differentiated instructions, context of exigent communication such as
warnings an
alert message refers to avoid travel a future, ongoing or to clear roads.

Emergency alerts 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, provides sufficient context about the specific
state of the lifecycle the alert message refers to.

For that purpose, the terminology utilized by the EMail architecture,
see [I-D.crocker-email-arch], is applied to this context.

Three types of communication models can be issued once for an emergency or authorities envisioned:

1. Alerts may repeat or update information during an event.

Some messages are be addressed to all individuals within a certain
geographic area. Other messages may target only specific individuals
or groups Today, this is often realized with the help of individuals, such as medical personnel or those
particularly susceptible
dedicated functionality provided by link layer technology (e.g.,
multicast, broadcast).

2. Alerts need to an incident.

Machine-parseable be delivered to dedicated end points via unicast
messaging. Examples are displays in subway stations, or
electronic bill boards. Some of these alerts may also be used to
trigger automated behaviors, such as closing vents during a
chemical spill or activating sirens or other warning systems in
commercial buildings.

At least initially, mobile and stationary devices Other messages may not have the
appropriate capabilities to receive target only specific
groups of individuals, such warnings. Thus, protocols as medical personnel. These may
include cases where legacy end points need to be designed to allow gatewaying to traditional systems, e.g.,
the PSTN.

We assume integrated into
the overall architecture and some form of protocol translation is
necessary. The communication end point from an event notification model, i.e., individuals subscribe to
warnings that affect their current location. As IP point of view
is therefore a single gateway (or a mobile device
moves, small number of them).

3. The two models described above illustrate a push communication
whereas the third model represents a subscription may need model where an
opt-in model is used to be updated. Thus, location provide further information needs to be available during about the subscription process.

Users
type of alerts that the recipient is interested in. The
information that may want to subscribe lead to warnings an alert message being distributed
may depend on certain factors, including certain types of events
happening in a specific geographic region irrespectively of
whether the entity issuing the subscription is actually located
in that do not affect their
current location. geographic region. 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.

Some technologies may also support network-level broadcast or
multicast.

This document focuses on all three types of communication models
whereby a stronger emphasis is given to the subscription model since
it is very powerful but less widely deployed on the Internet for
exigent communication. Content-wise this document provides
terminology, requirements and the architecture for IP-based protocols
to enhance and complement existing authority-to-citizen warning
systems.

2. Terminology

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 [RFC2119], with the
important qualification that, unless otherwise stated, these terms
apply to the design of a protocol conveying emergency alerts and
early warning messages, not its
implementation or application.

This document reuses the terminology introduced by [3GPP-TR-22.968] from [I-D.crocker-email-arch].
For editorial and modifies it to fit to IETF terminology:

Notification Population: consistency reasons parts of the text are repeated
in this document and modified as appropriate.

3. Responsible Actor Roles

The term notification population refers to communication system used for the set dissemination of alert messages
builds on top of existing communication infrastructure. These
distributed services consist of warning
notification consumers that receive a warning notification.

Public Warning System:

A public warning system delivers warning notifications variety of actors playing different
roles. These actors fall into three basic categories:

o User
o Message Handling Service (MHS)
o ADministrative Management Domain (ADMD)

3.1. User Actors

Users are the sources and sinks of alert messages. Users can be
people, organizations, or processes. There are four types of Users:

o Authors
o Recipients
o Return Handlers
o Mediators

From the user perspective, all alert message transfer activities are
performed by a monolithic Message Handling Service (MHS), even though
the actual service can be provided by
warning notification providers many independent organizations.

Whenever any MHS actor sends information to IP-capable end hosts within
notification areas.

Warning Notification:

Warning notifications inform recipients of back to an Author or
Originator in the occurrence sequence of
current or pending public safety-related events handling a message, that actor is a
User.

3.1.1. Author

The Author is responsible for creating the alert message, its
contents, and additionally its intended recipients, even though the exact list of
recipients may provide users with instructions on what be unknown to do the Author at the time of writing the
alert message. The MHS transfers the alert message from the Author
and where delivers it to get
help for the duration Recipients. The MHS has an Originator role
that correlates with the Author role.

3.1.2. Recipient

The Recipient is a consumer of the emergency.

Warning Notification Provider:

A warning notification provider delivered alert message. The MHS
has a Receiver role that correlates with the Recipient role.

3.1.3. Return Handler

The Return Handler is a special form of Recipient tasked with
servicing notifications that the MHS generates, as it transfers or
delivers the message. These notices can be about failures or
completions (such as utilized by test messages) and are sent to an agency
address that injects warning
notifications is specified by the Originator. This Return Handling
address (also known as a Return address) might have no visible
characteristics in common with the communication system. Examples of such
agencies are branches address of governments, public transport providers the Author or weather organizations.
Originator.

3.1.4. Mediator

A private institution, such as Mediator receives, aggregates, reformulates, and redistributes
alert messages among Authors and Recipients who are the principals in
(potentially) protracted exchanges. When submitting a
university, hospital or enterprise, may also provide such warnings
to people located within their facilities.

Warning Notification Consumer: A warning notification consumer is reformulated
message, the final recipient Mediator is an Author, albeit an author actually serving
as an agent of one or more other authors. So, a warning notification from an IP
communication point Mediator really is a
full-fledged User.

The aspect of view. Examples are Web browsers and SIP
clients on mobile phones and laptops a Mediator that process warning
notification messages. Once received such distinguishes it from any other MUA
creating a warning message is shown to that a Mediator preserves the user (a human) via an appropriately designed user interface integrity and
tone of the original message, including the essential aspects of its
origination information. The Mediator might also add commentary.

A Mediator attempts to
ensure that preserve the original Author's information in
the message it reformulates but is properly understood.

Warning Notification Aggregator:

A warning notification aggregator receives alert notifications
from different providers, performs security functions (e.g.,
authentication, authorization) and may need permitted to make meaningful
changes to transform the message
into content or envelope. The MHS sees a different format before forwarding them towards warning
notification consumers.

3. Architectures new
message, but users receive a message that they interpret as being
from, or at least initiated by, the Author of the original message.
The following sub-sections illustrate different architectural
approaches.

3.1. Closed Warning Notification Provider role of a Mediator is not limited to merely connecting other
participants; the Mediator is responsible for the new message.

A Mediator's role is complex and Aggregator Groups contingent, for example, modifying
and adding content or regulating which users are allowed to
participate and when. The first architectural variant allows the distribution common example of warning
notifications this role is an
aggregator that accepts alert messages from warning notification providers a set of Originators and
distributes them to warning
notification aggregators. The communication a potentially large set of Recipients. This
functionality is largely similar to a multicast, or even a broadcast.
Recipients might have also indicated their interest to receive
certain type of alerts messages or they might implicitly get entitled
to receive specific alerts purely by their presence in a point-
to-point fashion specific
geographical region. Hence, a Mediator might have additional
information about the Recipients context and might therefore be able
to make a decision whether the number of involved players Recipient is rather small, interested in receiving a
particular alert message.

A Gateway is a particularly on the side interesting form of the warning notification providers.
Furthermore, Mediator. It is a new warning notification aggregator
hybrid of User and Relay that connects to other communication
systems. Its purpose is allowed to
receive emulate a Relay.

3.2. Message Handling Service (MHS) Actors

The Message Handling Service (MHS) performs a single end-to-end
transfer of warning notifications only after certain verification
procedures messages on behalf of the Author to reach the
Recipient addresses. Exchanges that are conducted either mediated or iterative
and thereby protracted, such as those used for communicating information
about the entire communication
infrastructure re-essembles lifetime of an alert are handled by the User actors, not by
the MHS actors. As a closed group. To ensure that pragmatic heuristic MHS actors actors generate,
modify or look at only transfer data, rather than the
content of entire message.

Figure 1 shows the warning notifications is properly understood relationships among transfer participants.
Although it shows the
involved parties are very likely to agree on Originator as distinct from the detailed semantics Author and
Receiver as distinct from Recipient, each pair of roles usually has
the same actor. Transfers typically entail one or more Relays.
However, direct delivery from the Originator to Receiver is possible.
Delivery of warning messages prior to distributing any alert.

Figure 1 shows the involved parties graphically.

++==========++ ++===========++
|| Author || || Recipient ||
++====++====++ +--------+ ++===========++
|| | Return | /\
|| +-+------+ ||
\/ . ^ ||
+----------+ . . +---++----+
| | \ . . | | \\
/-+----------+----------------------------+---------+---\
| | \ | . . MHS | \\ | | \
| |Originator+<...........................+Receiver | .--------------. .............. |
| | Warning | : Warning : ^ | | | Notification |-----: Notification :
| +---++-----+ . +---------+ | Aggregator B
| : Provider : || . /\ |
| `--------------' `..............' || ...............+.................. || |
| / \/ . . . || |
| // +-------+-+ +--+------+ +-+--++---+ |
| // | Relay +======-=>| Relay +=======>| Relay | // |
| .--------------. // +---------+ +----++---+ +---------+ |
| || | Warning
| // || |
| \/ | Notification
| / +---------+ |
| Aggregator C | Gateway +-->... |
| `--------------' +---------+ |
+----------------------------------------+
\-------------------------------------------------------/

Legend: === and || lines indicate primary (possibly
indirect) transfers or roles
... lines indicate supporting transfers or roles

Figure 1: Closed Warning Notification Provider and Aggregator Groups

An example of this system can be seen in national early warning
systems where regulatory requirements force Relationships Among MHS Actors

3.2.1. Originator

The Originator ensures that a warning notification
provider message is valid for transfer
and aggregators then submits it to work together.

3.2. Open Communication between Warning Notification Provider and
Aggregator

This model a Relay. A message is similar valid if it conforms to
both communication and warning message encapsulation standards and
local operational policies. The Originator can simply review the closed group presented in
message for conformance and reject it if it finds errors, or it can
create some or all of the previous
section necessary information.

The Originator operates with a difference in dual allegiance. It serves the way how warning notification
aggregators Author
and can retrieve warning notifications from warning
notification providers. When be the aggregator interacts with same entity. But its role in assuring validity means
that it also represents the
provider then no special client-side authentication procedure is
assumed and no access restrictions are enforced. As such, local operator of the
aggregator might be located anywhere on MHS, that is, the Internet
local ADministrative Management Domain (ADMD).

The Originator also performs any post-submission, Author-related
administrative tasks associated with message transfer and delivery.
Notably, these tasks pertain to retrieve the
warning notifications. Warning notification aggregators might offer
their subscribers sending error and delivery notices,
enforcing local policies, and dealing with messages from the ability Author
that prove to receive warnings of a certain type
(e.g., weather alerts) be problematic for a specific region (e.g., the Internet. The Originator is
accountable for a specific
country or an entire continent). Hence, the aggregator might find message content, even when it is not responsible
for it. The Author creates the relevant warning notification providers and interacts message, but the Originator handles
any transmission issues with them
to retrieve alerts. Finally, it.

3.2.2. Relay

The Relay performs MHS-level transfer-service routing and store-and-
forward, by transmitting or retransmitting the aggregator might use different
protocol mechanisms message to its
Recipients. The Relay may add history / trace information
information (e.g., SMS, Web pages) towards the warning
notification customers, often depending on as available with SIP History Info [RFC4244]) or
security related protection (e.g., as available with SIP Identity
[RFC4474]) but does not modify the client capabilities.
In general, envelope information or the number
message content semantics.

A Message Handling System (MHS) network consists of aggregators a set of Relays.
This network is above any underlying packet-switching network that
might be used and below any Gateways or other Mediators.

3.2.3. Gateway

A Gateway is very likely larger than in a
closed group but there are no significant challenges with respect hybrid of User and Relay that connects heterogeneous
communication infrastructures. Its purpose is to
scalability or congestion emulate a Relay and
the closer it comes to expect.

Figure 2 shows this, the involved parties graphically.

o
\|/
| ..............
/ \ : Warning :
.--------------. : Notification :
| Warning | : Provider X :
| Notification |-- `..............'
Consumer (1)| -- --
`--------------' --- --- /
--- .--------------. --- /
-- | Warning | --- /
--| Notification |-- /
Aggregator better. A | \ /
...... `--------------' \\ /
\ //
X\
o / \
\|/ / \\
| / \
/ \ .--------------. / ..............
.--------------. | Warning |/ : Warning :
| Warning | ------- | Notification |-----: Notification :
| Notification |------ Aggregator B | : Provider Y :
Consumer (n)| `--------------' `..............'
`--------------'

Figure 2: Open Communication Gateway operates as a
User when it needs the ability to modify message content.

Differences between Warning Notification Provider
and Aggregator

3.3. Open Communication towards Warning Notification Customers

In the following architectural variant the customers directly
interact with various warning notification providers that different communication systems can be as
small as minor syntax variations, but they usually encompass
significant, semantic distinctions. Hence, the Relay function in a relevant
for
Gateway presents a specific type of alert type. In order to learn about significant design challenge, if the
relevant warning notification providers it may be necessary resulting
performance is to
consult some form of discovery service; this may be done out-of-band
via manual configuration or via a protocol mechanism.

Scalability and congestion control concerns arise with this scenario seen as this model assumes an opt-in approach from the customer. nearly seamless. The
total number of warning notification customers are provider has challenge is to
serve may be considerable. There are a more security challenges
since there are no pre-established trust relationships
ensure user-to-user functionality between the
warning notification customers communication services,
despite differences in their syntax and the providers.

Open Communication towards Warning Notification Customers

3.4. Notification Population

What warning notification customers are put into the notification
population semantics.

The basic test of Gateway design is whether an important architectural aspect that is largely
orthongonal Author on one side of
a Gateway can send a useful warning message to a Recipient on the architecture presented
other side, without requiring changes to any components in Section 3.1 and
Section 3.2.

In an opt-in model the
Author's or Recipient's communication service other than adding the
Gateway. To each of these otherwise independent services, the
Gateway appears to be a native participant.

3.2.4. Receiver

The Receiver performs final delivery or sends the warning notification customer need message to
provide information about what type
an alternate address. In case of alerts warning messages it is interested in
and, in order typically
responsible for ensuring that the appropriate user interface
interactions are triggered.

3.3. Administrative Actors

Administrative actors can be associated with different organizations,
each with its own administrative authority. This operational
independence, coupled with the need for interaction between groups,
provides the motivation to distinguish among ADministrative
Management Domains (ADMDs). Each ADMD can have vastly different
operating policies and trust-based decision-making. One obvious
example is the distinction between warning notification aggregator or messages that are
exchanged within an closed group (such as alert messages received by
parents affecting the school attended by their children) and warning
notification provider
messages that exchanged between independent organizations (e.g., in
case of large scale disasters). The rules for handling both types of
traffic tend to be able quite different. That difference requires
defining the boundaries of each, and this requires the ADMD
construct.

Operation of communication systems that are used to distribute warnings it convey alert
messages are typically carried out by different providers (or
operators). Each can be an independent ADMD. The benefit of the
ADMD construct is
necessary for them to know facilitate discussion about designs, policies
and operations that need to distinguish between internal issues and
external ones. Most significant is that the context, such as entities communicating
across ADMD boundaries typically have the current location,
preferred language or device capabilities. This information may added burden of enforcing
organizational policies concerning external communications. At a
more mundane level, routing mail between ADMDs can be
provided by an issue, such
as needing to route alert messages between organizational partners
over specially trusted paths.

The interactions of ADMD components are subject to the customer itself or by other entities, policies of
that domain, which cover concerns such as these:

o Reliability
o Access control
o Accountability
o Content evaluation, adaptation, and modification

4. Requirements

Requirements that relate to the
access provider.

Alternatively, encoding and the topological structure content of networks alert
messages is used to
distribute warning notifications outside the scope of this document. This document
focuses on protocols being utilized to all hosts that convey alert messages only.

The requirements for the two main communication models are located within
a specific IP-subsetwork or hosts different
and reflected in separate sub-sections, Section 4.2 and Section 4.3 .
There are, however, a specific link layer broadcast
domain. This approach typically requires co-operation from the
network provider.

4. Requirements

The following few generic requirements are related applicable to the both
communication protocol
and the context.

Req-1: models described in Section 4.1.

4.1. Communication Model Independent Requirements

Req-G1:

The protocol mechanisms solution MUST allow targeting notifications to
specific individuals, groups delivery of individuals or specific geographic
regions. Different regions or groups may receive different
instructions for the same disaster. (For example, people very
close messages
simultaneously to a chemical spill may be asked to evacuate, while those
further away may be asked to close windows.)

Req-2: large audience.

Req-G2:

The protocol solution MUST provide real-time message delivery.

Req-3: be independent of the underlying link
layer technology.

Req-G3:

The protocol solution MUST support offer the delivery typical communication
security mechanisms. Additional security mechanisms applied to
the alert message itself are outside the scope of warning notifications
that allow for predictable or likely events.

Req-4 the
communication protocol and therefore outside the scope of this
document.

Req-G4:

The protocol mechanisms solution MUST allow delivery of messages
simultaneously targeting notifications to a large audience.

Req-5
specific individuals and to groups of individuals.

Req-G5:

The protocol mechanisms solution MAY provide an option to return a receipt on
reading message. However, the confirmation SHOULD NOT be
required.

Req-6:

Req-G6:

The protocol mechanism solution MUST be independent ensure that congestion handling is
provided.

4.2. Requirements for a Subscription Model

The requirements for subscription / opt-in model require information
about the type of alerts that are being asked for to be made
available by the underlying
access network technology.

Req-7:

Protocol mechanisms potential Recipient to the Originator or set of
orginators.

Req-S1:

The protocol solution MUST allow to tailor the message to the
language preferences of the receiver and/or deliver multiple
versions in different languages within the same message, so that receiver.

Req-S2:

The protocol solution MUST allow an indication about the recipient can choose
geographical area the most appropriate one.

Req-8:

A user SHOULD be able to indicate potential Recipient is interested in.

Req-S3:

The protocol solution MUST allow an indication about the preferred method type of
communication to
alert the public warning service, such as notification
by email, different instant messaging protocols or automated voice
calls.

Req-9: potential Recipient is interested in.

Req-S4:

The protocol conveying warning notifications SHOULD identify the
warning notification provider in a secure manner.

Req-10:

The solution MUST provide a mechanism for transmitting warning
notification test messages.

Req-11:

A solution MUST support delivery allow an indication of notification messages (e.g.,
with the media types
that are understood or preferred by the potential Recipient.

The support for different media types) types depends to some extend on
the content of the warning message but the communication protocol
may be impacted as well. This functionality would, for example,
be useful for those with special needs, such as hearing and vision impaired.
impaired persons.

Req-S5:

The protocol solution MUST allow a potential Recipient to discover
the responsible Originator or set of Originators for a certain
category of warning messages.

4.3. Requirements for a Push Communication Model

The topological structure of networks is used to distribute warning
notifications to all hosts that are located within a specific IP-
subsetwork or multicast group.

Req-P1:

The protocol solution MUST allow network layer multicast and
broadcast mechanisms to be utilized.

5. IANA Considerations

This document does not require actions by IANA.

6. Security considerations

This document outlines requirements and security security requirements are a
part of them.

7. Acknowledgments

This document reuses requirements captured outside the IETF, namely
ETSI (with [ETSI-TS-102-182]), and the 3GPP (with [3GPP-TR-22.968]).
We would like to thank the authors of these specifications for their
work. Note, however, that only re-uses a small subset lot 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.

We text from [I-D.crocker-email-arch].
The authors would like to thank Leopold Murhammer Dave Crocker for his review in July 2007. work.

8. References

8.1. Normative References

[I-D.crocker-email-arch]
Crocker, D., "Internet Mail Architecture",
draft-crocker-email-arch-14 (work in progress), June 2009.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References

[3GPP-TR-22.968]

[July2005]
, ., "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)",
December "Report of the 7 July Review Committee, ISBN 1
85261 878 7", (PDF document), http://www.london.gov.uk/
assembly/reports/7july/report.pdf, June 2006.

[ETSI-TS-102-182]
, ., "ETSI TS 102 182, V1.2.1 (2006-12), Technical
Specification, Emergency Communications (EMTEL);
Requirements for communications from authorities/
organizations

[RFC4244] Barnes, M., "An Extension to individuals, groups or the general public
during emergencies", December Session Initiation
Protocol (SIP) for Request History Information", RFC 4244,
November 2005.

[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.

Authors' Addresses

Steve Norreys
BT Group
1 London Road
Brentwood, Essex CM14 4QP
UK

Phone: +44 1277 32 32 20
Email: steve.norreys@bt.com

Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland

Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at

Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US

Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu