< draft-norreys-ecrit-authority2individuals-requirements-02.txt		draft-norreys-ecrit-authority2individuals-requirements-03.txt >
	ECRIT S. Norreys		ECRIT S. Norreys
	Internet-Draft BT Group		Internet-Draft BT Group
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: September 9, 2009 Nokia Siemens Networks		Expires: January 14, 2010 Nokia Siemens Networks
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	March 8, 2009		July 13, 2009
	Authority-to-Individuals Communication for Emergency Situations:		Requirements, Terminology and Framework for Exigent Communications
	Requirements, Terminology and Architecture		draft-norreys-ecrit-authority2individuals-requirements-03.txt
	draft-norreys-ecrit-authority2individuals-requirements-02.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 35 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2009.		This Internet-Draft will expire on January 14, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Abstract		Abstract
	Public safety agencies need to provide information to the general		Various agencies need to provide information to the restricted group
	public before and during large-scale emergencies. While many aspects		of persons or even to the generic public before, during and after
	of such systems are specific to national or local jurisdictions,		emergency situations. While many aspects of such systems are
	emergencies span such boundaries and notifications need to reach		specific to national or local jurisdictions, emergencies span such
	visitors from other jurisdictions. This document summarizes		boundaries and notifications need to reach visitors from other
	requirements for protocols to alert individuals within a defined		jurisdictions. This document summarizes requirements for protocols
	geographic area.		to allow alerts to be conveyed to IP-based end points.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
			1.1. Classical Early Warning Situations . . . . . . . . . . . . 3
			1.2. Exigent Communications . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Architectures . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 5
	3.1. Closed Warning Notification Provider and Aggregator		3.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 5
	Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1.1. Author . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Open Communication between Warning Notification		3.1.2. Recipient . . . . . . . . . . . . . . . . . . . . . . 6
	Provider and Aggregator . . . . . . . . . . . . . . . . . 6		3.1.3. Return Handler . . . . . . . . . . . . . . . . . . . . 6
	3.3. Open Communication towards Warning Notification		3.1.4. Mediator . . . . . . . . . . . . . . . . . . . . . . . 6
	Customers . . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Message Handling Service (MHS) Actors . . . . . . . . . . 7
	3.4. Notification Population . . . . . . . . . . . . . . . . . 9		3.2.1. Originator . . . . . . . . . . . . . . . . . . . . . . 8
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2.2. Relay . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		3.2.3. Gateway . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security considerations . . . . . . . . . . . . . . . . . . . 11		3.2.4. Receiver . . . . . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		3.3. Administrative Actors . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 11		4.1. Communication Model Independent Requirements . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . . 11		4.2. Requirements for a Subscription Model . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		4.3. Requirements for a Push Communication Model . . . . . . . 12
			5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
			6. Security considerations . . . . . . . . . . . . . . . . . . . 13
			7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
			8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
			8.2. Informative References . . . . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
			1.1. Classical Early Warning Situations
	During large-scale emergencies, public safety authorities need to		During large-scale emergencies, public safety authorities need to
	reliably communicate with citizens in the affected areas, to provide		reliably communicate with citizens in the affected areas, to provide
	warnings, indicate whether citizens should evacuate and how, and to		warnings, indicate whether citizens should evacuate and how, and to
	dispel misinformation. Accurate information can reduce the impact of		dispel misinformation. Accurate information can reduce the impact of
	such emergencies.		such emergencies.
	Traditionally, emergency alerting has used church bells, sirens,		Traditionally, emergency alerting has used church bells, sirens,
	loudspeakers, radio and television to warn citizens and to provide		loudspeakers, radio and television to warn citizens and to provide
	information. However, techniques such as sirens and bells provide		information. However, techniques, such as sirens and bells, provide
	limited information content; loud speakers cover only very small		limited information content; loud speakers cover only very small
	areas and are often hard to understand, even for those not hearing		areas and are often hard to understand, even for those not hearing
	impaired or fluent in the local language. Radio and television offer		impaired or fluent in the local language. Radio and television offer
	larger information volume, but are hard to target geographically and		larger information volume, but are hard to target geographically and
	do not work well to address the "walking wounded" or other		do not work well to address the "walking wounded" or other
	pedestrians. Both are not suitable for warnings, as many of those		pedestrians. Both are not suitable for warnings, as many of those
	needing the information will not be listening or watching at any		needing the information will not be listening or watching at any
	given time, particularly during work/school and sleep hours.		given time, particularly during work/school and sleep hours.
	This problem has recently been illustrated by the London underground		This problem has been illustrated by the London underground bombing
	bombing on July 7, 2006, as described in a government report [ref].		on July 7, 2006, as described in a government report [July2005]. The
	The UK authorities could only use broadcast media and could not, for		UK authorities could only use broadcast media and could not, for
	example, easily announce to the "walking wounded" where to assemble.		example, easily announce to the "walking wounded" where to assemble.
	This document summarizes key requirements for IP-based protocols to		1.2. Exigent Communications
	enhance and complement existing authority-to-citizen warning systems.
	These protocols may either directly reach the citizen or may be used
	to trigger more traditional alerts, such as, among many others,
	displays in subway stations, electronic bill boards, or SMS.
	Public safety authorities need to reach, with an appropriate message,		With the usage of the term 'Exigent Communications' this document
	as many affected people as possible within the area impacted by the		aims to generalize the concept of conveying alerts to IP-based
	emergency, including not just residents, but also workers and		systems and at the same time to re-define the actors that participate
	travelers who may only be in the area temporarily.		in the messaging communication. More precisely, exigent
			communications is defined as:
	In addition, people around the immediately affected area should be		Communication that requirs immediate action or remedy.
	able to receive information and differentiated instructions, such as		Information about the reason for action and details about the
	warnings to avoid travel or to clear roads.		steps that have to be taken are provided in the alert message.
	Emergency alerts may be issued once for an emergency or authorities		An alert message (or warning message) is a cautionary advice about
	may repeat or update information during an event.		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, provides sufficient context about the specific
			state of the lifecycle the alert message refers to.
	Some messages are addressed to all individuals within a certain		For that purpose, the terminology utilized by the EMail architecture,
	geographic area. Other messages may target only specific individuals		see [I-D.crocker-email-arch], is applied to this context.
	or groups of individuals, such as medical personnel or those
	particularly susceptible to an incident.
	Machine-parseable alerts may also be used to trigger automated		Three types of communication models can be envisioned:
	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 may not have the		1. Alerts may be addressed to all individuals within a certain
	appropriate capabilities to receive such warnings. Thus, protocols		geographic area. Today, this is often realized with the help of
	need to be designed to allow gatewaying to traditional systems, e.g.,		dedicated functionality provided by link layer technology (e.g.,
	the PSTN.		multicast, broadcast).
	We assume an event notification model, i.e., individuals subscribe to		2. Alerts need to be delivered to dedicated end points via unicast
	warnings that affect their current location. As a mobile device		messaging. Examples are displays in subway stations, or
	moves, the subscription may need to be updated. Thus, location		electronic bill boards. Some of these alerts may also be used to
	information needs to be available during the subscription process.		trigger automated behaviors, such as closing vents during a
			chemical spill or activating sirens or other warning systems in
			commercial buildings. Other messages may target only specific
			groups of individuals, such as medical personnel. These may
			include cases where legacy end points need to be integrated into
			the overall architecture and some form of protocol translation is
			necessary. The communication end point from an IP point of view
			is therefore a single gateway (or a small number of them).
	Users may want to subscribe to warnings that do not affect their		3. The two models described above illustrate a push communication
	current location. For example, parents may want to be alerted of		whereas the third model represents a subscription model where an
	emergencies affecting the school attended by their children and adult		opt-in model is used to provide further information about the
	children may need to know about emergencies affecting elderly		type of alerts that the recipient is interested in. The
	parents.		information that may lead to 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 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		This document focuses on all three types of communication models
	multicast.		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		2. Terminology
	The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119], with the		document are to be interpreted as described in [RFC2119], with the
	important qualification that, unless otherwise stated, these terms		important qualification that, unless otherwise stated, these terms
	apply to the design of a protocol conveying emergency alerts and		apply to the design of a protocol conveying warning messages, not its
	early warning messages, not its implementation or application.		implementation or application.
	This document reuses the terminology introduced by [3GPP-TR-22.968]		This document reuses the terminology from [I-D.crocker-email-arch].
	and modifies it to fit to IETF terminology:		For editorial and consistency reasons parts of the text are repeated
			in this document and modified as appropriate.
	Notification Population:		3. Responsible Actor Roles
	The term notification population refers to the set of warning		The communication system used for the dissemination of alert messages
	notification consumers that receive a warning notification.		builds on top of existing communication infrastructure. These
			distributed services consist of a variety of actors playing different
			roles. These actors fall into three basic categories:
	Public Warning System:		o User
			o Message Handling Service (MHS)
			o ADministrative Management Domain (ADMD)
	A public warning system delivers warning notifications provided by		3.1. User Actors
	warning notification providers to IP-capable end hosts within
	notification areas.
	Warning Notification:		Users are the sources and sinks of alert messages. Users can be
			people, organizations, or processes. There are four types of Users:
	Warning notifications inform recipients of the occurrence of		o Authors
	current or pending public safety-related events and additionally		o Recipients
	may provide users with instructions on what to do and where to get		o Return Handlers
	help for the duration of the emergency.		o Mediators
	Warning Notification Provider:		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 many independent organizations.
	A warning notification provider is an agency that injects warning		Whenever any MHS actor sends information to back to an Author or
	notifications in the communication system. Examples of such		Originator in the sequence of handling a message, that actor is a
	agencies are branches of governments, public transport providers		User.
	or weather organizations. A private institution, such as a
	university, hospital or enterprise, may also provide such warnings
	to people located within their facilities.
	Warning Notification Consumer: A warning notification consumer is		3.1.1. Author
	the final recipient of a warning notification from an IP
	communication point of view. Examples are Web browsers and SIP
	clients on mobile phones and laptops that process warning
	notification messages. Once received such a warning is shown to
	the user (a human) via an appropriately designed user interface to
	ensure that it is properly understood.
	Warning Notification Aggregator:		The Author is responsible for creating the alert message, its
			contents, and its intended recipients, even though the exact list of
			recipients may be unknown to the Author at the time of writing the
			alert message. The MHS transfers the alert message from the Author
			and delivers it to the Recipients. The MHS has an Originator role
			that correlates with the Author role.
	A warning notification aggregator receives alert notifications		3.1.2. Recipient
	from different providers, performs security functions (e.g.,
	authentication, authorization) and may need to transform message
	into a different format before forwarding them towards warning
	notification consumers.
	3. Architectures		The Recipient is a consumer of the delivered alert message. The MHS
			has a Receiver role that correlates with the Recipient role.
	The following sub-sections illustrate different architectural		3.1.3. Return Handler
	approaches.
	3.1. Closed Warning Notification Provider and Aggregator Groups		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
			address that is specified by the Originator. This Return Handling
			address (also known as a Return address) might have no visible
			characteristics in common with the address of the Author or
			Originator.
	The first architectural variant allows the distribution of warning		3.1.4. Mediator
	notifications from warning notification providers to warning
	notification aggregators. The communication is largely in a point-
	to-point fashion and the number of involved players is rather small,
	particularly on the side of the warning notification providers.
	Furthermore, a new warning notification aggregator is allowed to
	receive warning notifications only after certain verification
	procedures are conducted and thereby the entire communication
	infrastructure re-essembles a closed group. To ensure that the
	content of the warning notifications is properly understood the
	involved parties are very likely to agree on the detailed semantics
	of the warning messages prior to distributing any alert.
	Figure 1 shows the involved parties graphically.		A Mediator receives, aggregates, reformulates, and redistributes
			alert messages among Authors and Recipients who are the principals in
			(potentially) protracted exchanges. When submitting a reformulated
			message, the Mediator is an Author, albeit an author actually serving
			as an agent of one or more other authors. So, a Mediator really is a
			full-fledged User.
	+----------------------------------------+		The aspect of a Mediator that distinguishes it from any other MUA
	| .--------------. |		creating a message is that a Mediator preserves the integrity and
	| | Warning | Closed |		tone of the original message, including the essential aspects of its
	| | Notification |\ Federation |		origination information. The Mediator might also add commentary.
	| Aggregator A | \ |
	| `--------------' \\ |
	| \ |
	| \\ |
	| \ |
	| \\ |
	| \ |
	| .--------------. .............. |
	| | Warning | : Warning : |
	| | Notification |-----: Notification : |
	| Aggregator B | : Provider : |
	| `--------------' `..............' |
	| / |
	| // |
	| // |
	| // |
	| .--------------. // |
	| | Warning | // |
	| | Notification | / |
	| Aggregator C | |
	| `--------------' |
	+----------------------------------------+
	Figure 1: Closed Warning Notification Provider and Aggregator Groups		A Mediator attempts to preserve the original Author's information in
			the message it reformulates but is permitted to make meaningful
			changes to the message content or envelope. The MHS sees a 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 role of a Mediator is not limited to merely connecting other
			participants; the Mediator is responsible for the new message.
	An example of this system can be seen in national early warning		A Mediator's role is complex and contingent, for example, modifying
	systems where regulatory requirements force warning notification		and adding content or regulating which users are allowed to
	provider and aggregators to work together.		participate and when. The common example of this role is an
			aggregator that accepts alert messages from a set of Originators and
			distributes them to a potentially large set of Recipients. This
			functionality is 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 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 Recipient is interested in receiving a
			particular alert message.
	3.2. Open Communication between Warning Notification Provider and		A Gateway is a particularly interesting form of Mediator. It is a
	Aggregator		hybrid of User and Relay that connects to other communication
			systems. Its purpose is to emulate a Relay.
	This model is similar to the closed group presented in the previous		3.2. Message Handling Service (MHS) Actors
	section with a difference in the way how warning notification
	aggregators can retrieve warning notifications from warning
	notification providers. When the aggregator interacts with the
	provider then no special client-side authentication procedure is
	assumed and no access restrictions are enforced. As such, the
	aggregator might be located anywhere on the Internet to retrieve the
	warning notifications. Warning notification aggregators might offer
	their subscribers the ability to receive warnings of a certain type
	(e.g., weather alerts) for a specific region (e.g., for a specific
	country or an entire continent). Hence, the aggregator might find
	the relevant warning notification providers and interacts with them
	to retrieve alerts. Finally, the aggregator might use different
	protocol mechanisms (e.g., SMS, Web pages) towards the warning
	notification customers, often depending on the client capabilities.
	In general, the number of aggregators is very likely larger than in a
	closed group but there are no significant challenges with respect to
	scalability or congestion to expect.
	Figure 2 shows the involved parties graphically.		The Message Handling Service (MHS) performs a single end-to-end
			transfer of warning messages on behalf of the Author to reach the
			Recipient addresses. Exchanges that are either mediated or iterative
			and protracted, such as those used for communicating information
			about the lifetime of an alert are handled by the User actors, not by
			the MHS actors. As a pragmatic heuristic MHS actors actors generate,
			modify or look at only transfer data, rather than the entire message.
	o		Figure 1 shows the relationships among transfer participants.
	\|/		Although it shows the Originator as distinct from the Author and
	| ..............		Receiver as distinct from Recipient, each pair of roles usually has
	/ \ : Warning :		the same actor. Transfers typically entail one or more Relays.
	.--------------. : Notification :		However, direct delivery from the Originator to Receiver is possible.
	| Warning | : Provider X :		Delivery of warning messages within a single administrative boundary
	| Notification |-- `..............'		usually only involve a single Relay.
	Consumer (1)| -- --
	`--------------' --- --- /
	--- .--------------. --- /
	-- | Warning | --- /
	--| Notification |-- /
	Aggregator A | \ /
	...... `--------------' \\ /
	\ //
	X\
	o / \
	\|/ / \\
	| / \
	/ \ .--------------. / ..............
	.--------------. | Warning |/ : Warning :
	| Warning | ------- | Notification |-----: Notification :
	| Notification |------ Aggregator B | : Provider Y :
	Consumer (n)| `--------------' `..............'
	`--------------'
	Figure 2: Open Communication between Warning Notification Provider		++==========++ ++===========++
	and Aggregator		|| Author || || Recipient ||
			++====++====++ +--------+ ++===========++
			|| | Return | /\
			|| +-+------+ ||
			\/ . ^ ||
			+----------+ . . +---++----+
			| | . . | |
			/-+----------+----------------------------+---------+---\
			| | | . . MHS | | |
			| |Originator+<...........................+Receiver | |
			| | | ^ | | |
			| +---++-----+ . +---------+ |
			| || . /\ |
			| || ...............+.................. || |
			| \/ . . . || |
			| +-------+-+ +--+------+ +-+--++---+ |
			| | Relay +======-=>| Relay +=======>| Relay | |
			| +---------+ +----++---+ +---------+ |
			| || |
			| || |
			| \/ |
			| +---------+ |
			| | Gateway +-->... |
			| +---------+ |
			\-------------------------------------------------------/
	3.3. Open Communication towards Warning Notification Customers		Legend: === and || lines indicate primary (possibly
			indirect) transfers or roles
			... lines indicate supporting transfers or roles
	In the following architectural variant the customers directly		Figure 1: Relationships Among MHS Actors
	interact with various warning notification providers that a relevant
	for a specific type of alert type. In order to learn about the
	relevant warning notification providers it may be necessary 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		3.2.1. Originator
	as this model assumes an opt-in approach from the customer. The
	total number of warning notification customers are provider has to
	serve may be considerable. There are a more security challenges
	since there are no pre-established trust relationships between the
	warning notification customers and the providers.
	.-----------.		The Originator ensures that a warning message is valid for transfer
	| Discovery |		and then submits it to a Relay. A message is valid if it conforms to
	| Service |		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.
	/ ..............
	/ : Warning :
	/ / : Notification :
	/ // : Provider X :
	/ // `..............'
	/ //
	o / //
	\|/ / /
	| / //
	/ \ v //
	.--------------. // ..............
	| Warning | // : Warning :
	| Notification |-------------------- : Notification :
	Consumer (1)|-- : Provider Y :
	`--------------' -- `..............'
	---
	--
	---
	--
	---
	-- : Warning :
	--: Notification :
	: Provider Y :
	`..............'
	Open Communication towards Warning Notification Customers		The Originator operates with dual allegiance. It serves the Author
			and can be the same entity. But its role in assuring validity means
			that it also represents the local operator of the MHS, that is, the
			local ADministrative Management Domain (ADMD).
	3.4. Notification Population		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,
			enforcing local policies, and dealing with messages from the Author
			that prove to be problematic for the Internet. The Originator is
			accountable for the message content, even when it is not responsible
			for it. The Author creates the message, but the Originator handles
			any transmission issues with it.
	What warning notification customers are put into the notification		3.2.2. Relay
	population is an important architectural aspect that is largely
	orthongonal to the architecture presented in Section 3.1 and
	Section 3.2.
	In an opt-in model the the warning notification customer need to		The Relay performs MHS-level transfer-service routing and store-and-
	provide information about what type of alerts it is interested in		forward, by transmitting or retransmitting the message to its
	and, in order for the warning notification aggregator or the warning		Recipients. The Relay may add history / trace information
	notification provider to be able to distribute warnings it is		information (e.g., as available with SIP History Info [RFC4244]) or
	necessary for them to know the context, such as the current location,		security related protection (e.g., as available with SIP Identity
	preferred language or device capabilities. This information may be		[RFC4474]) but does not modify the envelope information or the
	provided by the customer itself or by other entities, such as the		message content semantics.
	access provider.
	Alternatively, the topological structure of networks is used to		A Message Handling System (MHS) network consists of a set of Relays.
	distribute warning notifications to all hosts that are located within		This network is above any underlying packet-switching network that
	a specific IP-subsetwork or hosts in a specific link layer broadcast		might be used and below any Gateways or other Mediators.
	domain. This approach typically requires co-operation from the
	network provider.
	4. Requirements		3.2.3. Gateway
	The following requirements are related to the communication protocol		A Gateway is a hybrid of User and Relay that connects heterogeneous
	and the context.		communication infrastructures. Its purpose is to emulate a Relay and
			the closer it comes to this, the better. A Gateway operates as a
			User when it needs the ability to modify message content.
	Req-1:		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 user-to-user functionality between the communication services,
			despite differences in their syntax and semantics.
	The protocol mechanisms MUST allow targeting notifications to		The basic test of Gateway design is whether an Author on one side of
	specific individuals, groups of individuals or specific geographic		a Gateway can send a useful warning message to a Recipient on the
	regions. Different regions or groups may receive different		other side, without requiring changes to any components in the
	instructions for the same disaster. (For example, people very		Author's or Recipient's communication service other than adding the
	close to a chemical spill may be asked to evacuate, while those		Gateway. To each of these otherwise independent services, the
	further away may be asked to close windows.)		Gateway appears to be a native participant.
	Req-2:		3.2.4. Receiver
	The protocol solution MUST provide real-time message delivery.		The Receiver performs final delivery or sends the warning message to
			an alternate address. In case of warning messages it is typically
			responsible for ensuring that the appropriate user interface
			interactions are triggered.
	Req-3:		3.3. Administrative Actors
	The solution MUST support the delivery of warning notifications		Administrative actors can be associated with different organizations,
	that allow for predictable or likely events.		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 messages that are
			exchanged within an closed group (such as alert messages received by
			parents affecting the school attended by their children) and warning
			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 quite different. That difference requires
			defining the boundaries of each, and this requires the ADMD
			construct.
	Req-4		Operation of communication systems that are used to 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 to facilitate discussion about designs, policies
			and operations that need to distinguish between internal issues and
			external ones. Most significant is that the entities communicating
			across ADMD boundaries typically have the added burden of enforcing
			organizational policies concerning external communications. At a
			more mundane level, routing mail between ADMDs can be an issue, such
			as needing to route alert messages between organizational partners
			over specially trusted paths.
	The protocol mechanisms MUST allow delivery of messages		The interactions of ADMD components are subject to the 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 encoding and the content of alert
			messages is outside the scope of this document. This document
			focuses on protocols being utilized to convey alert messages only.
			The requirements for the two main communication models are different
			and reflected in separate sub-sections, Section 4.2 and Section 4.3 .
			There are, however, a few generic requirements applicable to both
			communication models described in Section 4.1.
			4.1. Communication Model Independent Requirements
			Req-G1:
			The protocol solution MUST allow delivery of messages
	simultaneously to a large audience.		simultaneously to a large audience.
	Req-5		Req-G2:
	The protocol mechanisms MAY provide an option to return a receipt		The protocol solution MUST be independent of the underlying link
	on reading message. However, the confirmation SHOULD NOT be		layer technology.
	required.
	Req-6:		Req-G3:
	The protocol mechanism MUST be independent of the underlying		The protocol solution MUST offer the typical communication
	access network technology.		security mechanisms. Additional security mechanisms applied to
			the alert message itself are outside the scope of the
			communication protocol and therefore outside the scope of this
			document.
	Req-7:		Req-G4:
	Protocol mechanisms MUST allow to tailor the message to the		The protocol solution MUST allow targeting notifications to
	language preferences of the receiver and/or deliver multiple		specific individuals and to groups of individuals.
	versions in different languages within the same message, so that
	the recipient can choose the most appropriate one.
	Req-8:		Req-G5:
	A user SHOULD be able to indicate the preferred method of		The protocol solution MAY provide an option to return a receipt on
	communication to the public warning service, such as notification		reading message.
	by email, different instant messaging protocols or automated voice
	calls.
	Req-9:		Req-G6:
	The protocol conveying warning notifications SHOULD identify the		The protocol solution MUST ensure that congestion handling is
	warning notification provider in a secure manner.		provided.
	Req-10:		4.2. Requirements for a Subscription Model
	The solution MUST provide a mechanism for transmitting warning		The requirements for subscription / opt-in model require information
	notification test messages.		about the type of alerts that are being asked for to be made
			available by the potential Recipient to the Originator or set of
			orginators.
	Req-11:		Req-S1:
	A solution MUST support delivery of notification messages (e.g.,		The protocol solution MUST allow to tailor the message to the
	with different media types) to those with special needs, such as		language preferences of the receiver.
	hearing and vision impaired.
			Req-S2:
			The protocol solution MUST allow an indication about the
			geographical area the potential Recipient is interested in.
			Req-S3:
			The protocol solution MUST allow an indication about the type of
			alert the potential Recipient is interested in.
			Req-S4:
			The protocol solution MUST allow an indication of the media types
			that are understood or preferred by the potential Recipient.
			The support for different media 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 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		5. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	6. Security considerations		6. Security considerations
	This document outlines requirements and security security		This document outlines requirements and security requirements are a
	requirements are a part of them.		part of them.
	7. Acknowledgments		7. Acknowledgments
	This document reuses requirements captured outside the IETF, namely		This document re-uses a lot of text from [I-D.crocker-email-arch].
	ETSI (with [ETSI-TS-102-182]), and the 3GPP (with [3GPP-TR-22.968]).		The authors would like to thank Dave Crocker for his work.
	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.
	We would like to thank Leopold Murhammer for his review in July 2007.
	8. References		8. References
	8.1. Normative 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		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	8.2. Informative References		8.2. Informative References
	[3GPP-TR-22.968]		[July2005]
	, ., "3GPP TR 22.968, V1.0.0 (2007-04), 3rd Generation		, ., "Report of the 7 July Review Committee, ISBN 1
	Partnership Project; Technical Specification Group		85261 878 7", (PDF document), http://www.london.gov.uk/
	Services and System Aspects; Study for requirements for a		assembly/reports/7july/report.pdf, June 2006.
	Public Warning System (PWS) Service (Release 8)",
	December 2006.
	[ETSI-TS-102-182]		[RFC4244] Barnes, M., "An Extension to the Session Initiation
	, ., "ETSI TS 102 182, V1.2.1 (2006-12), Technical		Protocol (SIP) for Request History Information", RFC 4244,
	Specification, Emergency Communications (EMTEL);		November 2005.
	Requirements for communications from authorities/
	organizations to individuals, groups or the general public		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	during emergencies", December 2006.		Authenticated Identity Management in the Session
			Initiation Protocol (SIP)", RFC 4474, August 2006.
	Authors' Addresses		Authors' Addresses
	Steve Norreys		Steve Norreys
	BT Group		BT Group
	1 London Road		1 London Road
	Brentwood, Essex CM14 4QP		Brentwood, Essex CM14 4QP
	UK		UK
	Phone: +44 1277 32 32 20		Phone: +44 1277 32 32 20
End of changes. 84 change blocks.
	329 lines changed or deleted		407 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/