< draft-norreys-ecrit-authority2individuals-requirements-01.txt		draft-norreys-ecrit-authority2individuals-requirements-02.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: January 13, 2009 Nokia Siemens Networks		Expires: September 9, 2009 Nokia Siemens Networks
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	July 12, 2008		March 8, 2009
	Requirements for Authority-to-Individuals Communication for Emergency		Authority-to-Individuals Communication for Emergency Situations:
	Situations		Requirements, Terminology and Architecture
	draft-norreys-ecrit-authority2individuals-requirements-01.txt		draft-norreys-ecrit-authority2individuals-requirements-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of 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.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 January 13, 2009.		This Internet-Draft will expire on September 9, 2009.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			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		Abstract
	Public safety agencies need to provide information to the general		Public safety agencies need to provide information to the general
	public before and during large-scale emergencies. While many aspects		public before and during large-scale emergencies. While many aspects
	of such systems are specific to national or local jurisdictions,		of such systems are specific to national or local jurisdictions,
	emergencies span such boundaries and notifications need to reach		emergencies span such boundaries and notifications need to reach
	visitors from other jurisdictions. This document summarizes		visitors from other jurisdictions. This document summarizes
	requirements for protocols to alert individuals within a defined		requirements for protocols to alert individuals within a defined
	geographic area.		geographic area.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Architectures . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		3.1. Closed Warning Notification Provider and Aggregator
	5. Security considerations . . . . . . . . . . . . . . . . . . . 7		Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Open Communication between Warning Notification
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		Provider and Aggregator . . . . . . . . . . . . . . . . . 6
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 8		3.3. Open Communication towards Warning Notification
	7.2. Informative References . . . . . . . . . . . . . . . . . . 8		Customers . . . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		3.4. Notification Population . . . . . . . . . . . . . . . . . 9
	Intellectual Property and Copyright Statements . . . . . . . . . . 10		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9
			5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
			6. Security considerations . . . . . . . . . . . . . . . . . . . 11
			7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
			8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
			8.2. Informative References . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	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,
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 40 ¶
	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 emergency alerts and
	early warning messages, not its implementation or application.		early warning messages, not its implementation or application.
	This document reuses the terminology introduced by [3GPP-TR-22.968]		This document reuses the terminology introduced by [3GPP-TR-22.968]
	and modifies it to fit to IETF terminology:		and modifies it to fit to IETF terminology:
	Notification Area:		Notification Population:
	Notification area is an area where warning notifications are sent.		The term notification population refers to the set of warning
			notification consumers that receive a warning notification.
	Public Warning System:		Public Warning System:
	A public warning system delivers warning notifications provided by		A public warning system delivers warning notifications provided by
	warning notification providers to IP-capable end hosts within		warning notification providers to IP-capable end hosts within
	notification areas.		notification areas.
	Warning Notification:		Warning Notification:
	Warning notifications notify recipients of the occurrence of		Warning notifications inform recipients of the occurrence of
	current or pending public safety-related events and additionally		current or pending public safety-related events and additionally
	may provide users with instructions on what to do and where to get		may provide users with instructions on what to do and where to get
	help for the duration of the emergency.		help for the duration of the emergency.
	Warning Notification Provider:		Warning Notification Provider:
	A warning notification provider is an agency such as a branch of		A warning notification provider is an agency that injects warning
	government or a public transport agency that provides warning		notifications in the communication system. Examples of such
	notifications. A private institution, such as a university,		agencies are branches of governments, public transport providers
	hospital or enterprise, may also provide such warnings to people		or weather organizations. A private institution, such as a
	located within their facilities.		university, hospital or enterprise, may also provide such warnings
			to people located within their facilities.
	3. Requirements		Warning Notification Consumer: A warning notification consumer is
			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.
	The objective of these requirements is to allow authorities dealing		Warning Notification Aggregator:
	with an emergency situation to communicate adequately with effected
	people in a timely fashion.
	Req-1:		A warning notification aggregator receives alert notifications
			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.
	The protocol mechanisms MUST provide real-time message delivery.		3. Architectures
	Req-2:		The following sub-sections illustrate different architectural
			approaches.
	The protocol mechanisms MUST deliver messages within a pre-planned		3.1. Closed Warning Notification Provider and Aggregator Groups
	time frame in the future, as agencies may want to prepare
	announcements for predictable or likely events.
	Req-3:		The first architectural variant allows the distribution of warning
			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.
	The protocol mechanisms MUST convey sufficient details of the		Figure 1 shows the involved parties graphically.
	emergency situation.
	Req-4:		+----------------------------------------+
			| .--------------. |
			| | Warning | Closed |
			| | Notification |\ Federation |
			| Aggregator A | \ |
			| `--------------' \\ |
			| \ |
			| \\ |
			| \ |
			| \\ |
			| \ |
			| .--------------. .............. |
			| | Warning | : Warning : |
			| | Notification |-----: Notification : |
			| Aggregator B | : Provider : |
			| `--------------' `..............' |
			| / |
			| // |
			| // |
			| // |
			| .--------------. // |
			| | Warning | // |
			| | Notification | / |
			| Aggregator C | |
			| `--------------' |
			+----------------------------------------+
	The protocol mechanisms MUST provide the public with sufficient		Figure 1: Closed Warning Notification Provider and Aggregator Groups
	instructions to take appropriate actions.
	Req-5:		An example of this system can be seen in national early warning
			systems where regulatory requirements force warning notification
			provider and aggregators to work together.
			3.2. Open Communication between Warning Notification Provider and
			Aggregator
			This model is similar to the closed group presented in the previous
			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.
			o
			\|/
			| ..............
			/ \ : Warning :
			.--------------. : Notification :
			| Warning | : Provider X :
			| Notification |-- `..............'
			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
			3.3. Open Communication towards Warning Notification Customers
			In the following architectural variant the customers directly
			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
			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.
			.-----------.
			| Discovery |
			| Service |
			`-----------'
			^
			/
			/ ..............
			/ : Warning :
			/ / : Notification :
			/ // : Provider X :
			/ // `..............'
			/ //
			o / //
			\|/ / /
			| / //
			/ \ v //
			.--------------. // ..............
			| Warning | // : Warning :
			| Notification |-------------------- : Notification :
			Consumer (1)|-- : Provider Y :
			`--------------' -- `..............'
			---
			--
			---
			--
			---
			-- : Warning :
			--: Notification :
			: Provider Y :
			`..............'
			Open Communication towards Warning Notification Customers
			3.4. Notification Population
			What warning notification customers are put into the notification
			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
			provide information about what type of alerts it is interested in
			and, in order for the warning notification aggregator or the warning
			notification provider to be able to distribute warnings it is
			necessary for them to know the context, such as the current location,
			preferred language or device capabilities. This information may be
			provided by the customer itself or by other entities, such as the
			access provider.
			Alternatively, the topological structure of networks is used to
			distribute warning notifications to all hosts that are located within
			a specific IP-subsetwork or hosts in a specific link layer broadcast
			domain. This approach typically requires co-operation from the
			network provider.
			4. Requirements
			The following requirements are related to the communication protocol
			and the context.
			Req-1:
	The protocol mechanisms MUST allow targeting notifications to		The protocol mechanisms MUST allow targeting notifications to
	specific individuals, groups of individuals or specific geographic		specific individuals, groups of individuals or specific geographic
	regions. Different regions or groups may receive different		regions. Different regions or groups may receive different
	instructions for the same emergency. (For example, people very		instructions for the same disaster. (For example, people very
	close to a chemical spill may be asked to evacuate, while those		close to a chemical spill may be asked to evacuate, while those
	further away may be asked to close windows.)		further away may be asked to close windows.)
	Req-6		Req-2:
	Early warning notifications MAY be given preferential processing		The protocol solution MUST provide real-time message delivery.
	and delivery treatment.
	Req-7		Req-3:
			The solution MUST support the delivery of warning notifications
			that allow for predictable or likely events.
			Req-4
	The protocol mechanisms MUST allow delivery of messages		The protocol mechanisms MUST allow delivery of messages
	simultaneously to a large audience.		simultaneously to a large audience.
	Req-8		Req-5
	The protocol mechanisms MAY provide an option to return a receipt		The protocol mechanisms MAY provide an option to return a receipt
	on reading message. Message alert confirmation SHOULD NOT be		on reading message. However, the confirmation SHOULD NOT be
	required.		required.
	Req-9:		Req-6:
	An emergency notification system MUST be independent of the		The protocol mechanism MUST be independent of the underlying
	underlying access network technology.		access network technology.
	Req-10:		Req-7:
	Protocol mechanisms MUST allow to tailor the message to the		Protocol mechanisms MUST allow to tailor the message to the
	language preferences of the receiver and/or deliver multiple		language preferences of the receiver and/or deliver multiple
	versions in different languages within the same message, so that		versions in different languages within the same message, so that
	the recipient can choose the most appropriate one.		the recipient can choose the most appropriate one.
	Req-11:		Req-8:
	A solution MUST support delivery of notification messages (e.g.,
	with different media types) to those with special needs, such as
	hearing and vision impaired.
	Req-12:
	A user SHOULD be able to indicate the preferred method of		A user SHOULD be able to indicate the preferred method of
	communication to the public warning service, such as notification		communication to the public warning service, such as notification
	by email, different instant messaging protocols or automated voice		by email, different instant messaging protocols or automated voice
	calls.		calls.
	Req-13:		Req-9:
	A solution MUST prevent misuse of the emergency infrastructure by
	unauthorized entities.
	Req-14:
	Emergency notification systems SHOULD identify the message and
	notification originator, preferably in a cryptographically secure
	manner.
	Req-15:
	A solution MUST offer sufficient details of the emergency
	situation.
	Req-16:
	A solution MUST support integrity protection of early warning		The protocol conveying warning notifications SHOULD identify the
	notifications.		warning notification provider in a secure manner.
	Req-17:		Req-10:
	A solution MUST provide a mechanism for testing authority-to-		The solution MUST provide a mechanism for transmitting warning
	individuals early warning messages just as test support is		notification test messages.
	provided by individuals-to-authority emergency services.
	Req-18:		Req-11:
	Devices should be able to recognize alerts that requires that the		A solution MUST support delivery of notification messages (e.g.,
	device override user interface configurations such as vibrate-only		with different media types) to those with special needs, such as
	mode. (For example, a school closing advisory due to snow may not		hearing and vision impaired.
	require such an immediate alert in the middle of the night.)
	4. IANA Considerations		5. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	5. Security considerations		6. Security considerations
	This document outlines requirements and security security		This document outlines requirements and security security
	requirements are a part of them.		requirements are a part of them.
	6. Acknowledgments		7. Acknowledgments
	This document reuses requirements captured outside the IETF, namely		This document reuses requirements captured outside the IETF, namely
	ETSI (with [ETSI-TS-102-182]), and the 3GPP (with [3GPP-TR-22.968]).		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		We would like to thank the authors of these specifications for their
	work. Note, however, that only a small subset of the requirements		work. Note, however, that only a small subset of the requirements
	have been reflected that do not relate to specific deployments, user		have been reflected that do not relate to specific deployments, user
	interface aspects, detailed regulatory requirements, management and		interface aspects, detailed regulatory requirements, management and
	operational considerations, and non-IP specific technologies.		operational considerations, and non-IP specific technologies.
	We would like to thank Leopold Murhammer for his review in July 2007.		We would like to thank Leopold Murhammer for his review in July 2007.
	7. References		8. References
	7.1. Normative References		8.1. Normative References
	[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.
	7.2. Informative References		8.2. Informative References
	[3GPP-TR-22.968]		[3GPP-TR-22.968]
	, ., "3GPP TR 22.968, V1.0.0 (2007-04), 3rd Generation		, ., "3GPP TR 22.968, V1.0.0 (2007-04), 3rd Generation
	Partnership Project; Technical Specification Group		Partnership Project; Technical Specification Group
	Services and System Aspects; Study for requirements for a		Services and System Aspects; Study for requirements for a
	Public Warning System (PWS) Service (Release 8)",		Public Warning System (PWS) Service (Release 8)",
	December 2006.		December 2006.
	[ETSI-TS-102-182]		[ETSI-TS-102-182]
	, ., "ETSI TS 102 182, V1.2.1 (2006-12), Technical		, ., "ETSI TS 102 182, V1.2.1 (2006-12), Technical
	skipping to change at page 9, line 4 ¶		skipping to change at page 12, line 15 ¶
	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
	Email: steve.norreys@bt.com		Email: steve.norreys@bt.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	US		US
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	Email: hgs+ecrit@cs.columbia.edu		Email: hgs+ecrit@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 45 change blocks.
	96 lines changed or deleted		269 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/