idnits 2.17.00 (12 Aug 2021) /tmp/idnits14914/draft-norreys-ecrit-authority2individuals-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Too long document name: The document name (without revision number), 'draft-norreys-ecrit-authority2individuals-requirements', is 54 characters long, but may be at most 50 characters Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 4822 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT S. Norreys 3 Internet-Draft BT Group 4 Intended status: Informational H. Tschofenig 5 Expires: September 9, 2009 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 March 8, 2009 10 Authority-to-Individuals Communication for Emergency Situations: 11 Requirements, Terminology and Architecture 12 draft-norreys-ecrit-authority2individuals-requirements-02.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 9, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 Public safety agencies need to provide information to the general 51 public before and during large-scale emergencies. While many aspects 52 of such systems are specific to national or local jurisdictions, 53 emergencies span such boundaries and notifications need to reach 54 visitors from other jurisdictions. This document summarizes 55 requirements for protocols to alert individuals within a defined 56 geographic area. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Architectures . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Closed Warning Notification Provider and Aggregator 64 Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.2. Open Communication between Warning Notification 66 Provider and Aggregator . . . . . . . . . . . . . . . . . 6 67 3.3. Open Communication towards Warning Notification 68 Customers . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.4. Notification Population . . . . . . . . . . . . . . . . . 9 70 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 6. Security considerations . . . . . . . . . . . . . . . . . . . 11 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 During large-scale emergencies, public safety authorities need to 82 reliably communicate with citizens in the affected areas, to provide 83 warnings, indicate whether citizens should evacuate and how, and to 84 dispel misinformation. Accurate information can reduce the impact of 85 such emergencies. 87 Traditionally, emergency alerting has used church bells, sirens, 88 loudspeakers, radio and television to warn citizens and to provide 89 information. However, techniques such as sirens and bells provide 90 limited information content; loud speakers cover only very small 91 areas and are often hard to understand, even for those not hearing 92 impaired or fluent in the local language. Radio and television offer 93 larger information volume, but are hard to target geographically and 94 do not work well to address the "walking wounded" or other 95 pedestrians. Both are not suitable for warnings, as many of those 96 needing the information will not be listening or watching at any 97 given time, particularly during work/school and sleep hours. 99 This problem has recently been illustrated by the London underground 100 bombing on July 7, 2006, as described in a government report [ref]. 101 The UK authorities could only use broadcast media and could not, for 102 example, easily announce to the "walking wounded" where to assemble. 104 This document summarizes key requirements for IP-based protocols to 105 enhance and complement existing authority-to-citizen warning systems. 106 These protocols may either directly reach the citizen or may be used 107 to trigger more traditional alerts, such as, among many others, 108 displays in subway stations, electronic bill boards, or SMS. 110 Public safety authorities need to reach, with an appropriate message, 111 as many affected people as possible within the area impacted by the 112 emergency, including not just residents, but also workers and 113 travelers who may only be in the area temporarily. 115 In addition, people around the immediately affected area should be 116 able to receive information and differentiated instructions, such as 117 warnings to avoid travel or to clear roads. 119 Emergency alerts may be issued once for an emergency or authorities 120 may repeat or update information during an event. 122 Some messages are addressed to all individuals within a certain 123 geographic area. Other messages may target only specific individuals 124 or groups of individuals, such as medical personnel or those 125 particularly susceptible to an incident. 127 Machine-parseable alerts may also be used to trigger automated 128 behaviors, such as closing vents during a chemical spill or 129 activating sirens or other warning systems in commercial buildings. 131 At least initially, mobile and stationary devices may not have the 132 appropriate capabilities to receive such warnings. Thus, protocols 133 need to be designed to allow gatewaying to traditional systems, e.g., 134 the PSTN. 136 We assume an event notification model, i.e., individuals subscribe to 137 warnings that affect their current location. As a mobile device 138 moves, the subscription may need to be updated. Thus, location 139 information needs to be available during the subscription process. 141 Users may want to subscribe to warnings that do not affect their 142 current location. For example, parents may want to be alerted of 143 emergencies affecting the school attended by their children and adult 144 children may need to know about emergencies affecting elderly 145 parents. 147 Some technologies may also support network-level broadcast or 148 multicast. 150 2. Terminology 152 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119], with the 155 important qualification that, unless otherwise stated, these terms 156 apply to the design of a protocol conveying emergency alerts and 157 early warning messages, not its implementation or application. 159 This document reuses the terminology introduced by [3GPP-TR-22.968] 160 and modifies it to fit to IETF terminology: 162 Notification Population: 164 The term notification population refers to the set of warning 165 notification consumers that receive a warning notification. 167 Public Warning System: 169 A public warning system delivers warning notifications provided by 170 warning notification providers to IP-capable end hosts within 171 notification areas. 173 Warning Notification: 175 Warning notifications inform recipients of the occurrence of 176 current or pending public safety-related events and additionally 177 may provide users with instructions on what to do and where to get 178 help for the duration of the emergency. 180 Warning Notification Provider: 182 A warning notification provider is an agency that injects warning 183 notifications in the communication system. Examples of such 184 agencies are branches of governments, public transport providers 185 or weather organizations. A private institution, such as a 186 university, hospital or enterprise, may also provide such warnings 187 to people located within their facilities. 189 Warning Notification Consumer: A warning notification consumer is 190 the final recipient of a warning notification from an IP 191 communication point of view. Examples are Web browsers and SIP 192 clients on mobile phones and laptops that process warning 193 notification messages. Once received such a warning is shown to 194 the user (a human) via an appropriately designed user interface to 195 ensure that it is properly understood. 197 Warning Notification Aggregator: 199 A warning notification aggregator receives alert notifications 200 from different providers, performs security functions (e.g., 201 authentication, authorization) and may need to transform message 202 into a different format before forwarding them towards warning 203 notification consumers. 205 3. Architectures 207 The following sub-sections illustrate different architectural 208 approaches. 210 3.1. Closed Warning Notification Provider and Aggregator Groups 212 The first architectural variant allows the distribution of warning 213 notifications from warning notification providers to warning 214 notification aggregators. The communication is largely in a point- 215 to-point fashion and the number of involved players is rather small, 216 particularly on the side of the warning notification providers. 217 Furthermore, a new warning notification aggregator is allowed to 218 receive warning notifications only after certain verification 219 procedures are conducted and thereby the entire communication 220 infrastructure re-essembles a closed group. To ensure that the 221 content of the warning notifications is properly understood the 222 involved parties are very likely to agree on the detailed semantics 223 of the warning messages prior to distributing any alert. 225 Figure 1 shows the involved parties graphically. 227 +----------------------------------------+ 228 | .--------------. | 229 | | Warning | Closed | 230 | | Notification |\ Federation | 231 | Aggregator A | \ | 232 | `--------------' \\ | 233 | \ | 234 | \\ | 235 | \ | 236 | \\ | 237 | \ | 238 | .--------------. .............. | 239 | | Warning | : Warning : | 240 | | Notification |-----: Notification : | 241 | Aggregator B | : Provider : | 242 | `--------------' `..............' | 243 | / | 244 | // | 245 | // | 246 | // | 247 | .--------------. // | 248 | | Warning | // | 249 | | Notification | / | 250 | Aggregator C | | 251 | `--------------' | 252 +----------------------------------------+ 254 Figure 1: Closed Warning Notification Provider and Aggregator Groups 256 An example of this system can be seen in national early warning 257 systems where regulatory requirements force warning notification 258 provider and aggregators to work together. 260 3.2. Open Communication between Warning Notification Provider and 261 Aggregator 263 This model is similar to the closed group presented in the previous 264 section with a difference in the way how warning notification 265 aggregators can retrieve warning notifications from warning 266 notification providers. When the aggregator interacts with the 267 provider then no special client-side authentication procedure is 268 assumed and no access restrictions are enforced. As such, the 269 aggregator might be located anywhere on the Internet to retrieve the 270 warning notifications. Warning notification aggregators might offer 271 their subscribers the ability to receive warnings of a certain type 272 (e.g., weather alerts) for a specific region (e.g., for a specific 273 country or an entire continent). Hence, the aggregator might find 274 the relevant warning notification providers and interacts with them 275 to retrieve alerts. Finally, the aggregator might use different 276 protocol mechanisms (e.g., SMS, Web pages) towards the warning 277 notification customers, often depending on the client capabilities. 278 In general, the number of aggregators is very likely larger than in a 279 closed group but there are no significant challenges with respect to 280 scalability or congestion to expect. 282 Figure 2 shows the involved parties graphically. 284 o 285 \|/ 286 | .............. 287 / \ : Warning : 288 .--------------. : Notification : 289 | Warning | : Provider X : 290 | Notification |-- `..............' 291 Consumer (1)| -- -- 292 `--------------' --- --- / 293 --- .--------------. --- / 294 -- | Warning | --- / 295 --| Notification |-- / 296 Aggregator A | \ / 297 ...... `--------------' \\ / 298 \ // 299 X\ 300 o / \ 301 \|/ / \\ 302 | / \ 303 / \ .--------------. / .............. 304 .--------------. | Warning |/ : Warning : 305 | Warning | ------- | Notification |-----: Notification : 306 | Notification |------ Aggregator B | : Provider Y : 307 Consumer (n)| `--------------' `..............' 308 `--------------' 310 Figure 2: Open Communication between Warning Notification Provider 311 and Aggregator 313 3.3. Open Communication towards Warning Notification Customers 315 In the following architectural variant the customers directly 316 interact with various warning notification providers that a relevant 317 for a specific type of alert type. In order to learn about the 318 relevant warning notification providers it may be necessary to 319 consult some form of discovery service; this may be done out-of-band 320 via manual configuration or via a protocol mechanism. 322 Scalability and congestion control concerns arise with this scenario 323 as this model assumes an opt-in approach from the customer. The 324 total number of warning notification customers are provider has to 325 serve may be considerable. There are a more security challenges 326 since there are no pre-established trust relationships between the 327 warning notification customers and the providers. 329 .-----------. 330 | Discovery | 331 | Service | 332 `-----------' 333 ^ 334 / 335 / .............. 336 / : Warning : 337 / / : Notification : 338 / // : Provider X : 339 / // `..............' 340 / // 341 o / // 342 \|/ / / 343 | / // 344 / \ v // 345 .--------------. // .............. 346 | Warning | // : Warning : 347 | Notification |-------------------- : Notification : 348 Consumer (1)|-- : Provider Y : 349 `--------------' -- `..............' 350 --- 351 -- 352 --- 353 -- 354 --- 355 -- : Warning : 356 --: Notification : 357 : Provider Y : 358 `..............' 360 Open Communication towards Warning Notification Customers 362 3.4. Notification Population 364 What warning notification customers are put into the notification 365 population is an important architectural aspect that is largely 366 orthongonal to the architecture presented in Section 3.1 and 367 Section 3.2. 369 In an opt-in model the the warning notification customer need to 370 provide information about what type of alerts it is interested in 371 and, in order for the warning notification aggregator or the warning 372 notification provider to be able to distribute warnings it is 373 necessary for them to know the context, such as the current location, 374 preferred language or device capabilities. This information may be 375 provided by the customer itself or by other entities, such as the 376 access provider. 378 Alternatively, the topological structure of networks is used to 379 distribute warning notifications to all hosts that are located within 380 a specific IP-subsetwork or hosts in a specific link layer broadcast 381 domain. This approach typically requires co-operation from the 382 network provider. 384 4. Requirements 386 The following requirements are related to the communication protocol 387 and the context. 389 Req-1: 391 The protocol mechanisms MUST allow targeting notifications to 392 specific individuals, groups of individuals or specific geographic 393 regions. Different regions or groups may receive different 394 instructions for the same disaster. (For example, people very 395 close to a chemical spill may be asked to evacuate, while those 396 further away may be asked to close windows.) 398 Req-2: 400 The protocol solution MUST provide real-time message delivery. 402 Req-3: 404 The solution MUST support the delivery of warning notifications 405 that allow for predictable or likely events. 407 Req-4 409 The protocol mechanisms MUST allow delivery of messages 410 simultaneously to a large audience. 412 Req-5 414 The protocol mechanisms MAY provide an option to return a receipt 415 on reading message. However, the confirmation SHOULD NOT be 416 required. 418 Req-6: 420 The protocol mechanism MUST be independent of the underlying 421 access network technology. 423 Req-7: 425 Protocol mechanisms MUST allow to tailor the message to the 426 language preferences of the receiver and/or deliver multiple 427 versions in different languages within the same message, so that 428 the recipient can choose the most appropriate one. 430 Req-8: 432 A user SHOULD be able to indicate the preferred method of 433 communication to the public warning service, such as notification 434 by email, different instant messaging protocols or automated voice 435 calls. 437 Req-9: 439 The protocol conveying warning notifications SHOULD identify the 440 warning notification provider in a secure manner. 442 Req-10: 444 The solution MUST provide a mechanism for transmitting warning 445 notification test messages. 447 Req-11: 449 A solution MUST support delivery of notification messages (e.g., 450 with different media types) to those with special needs, such as 451 hearing and vision impaired. 453 5. IANA Considerations 455 This document does not require actions by IANA. 457 6. Security considerations 459 This document outlines requirements and security security 460 requirements are a part of them. 462 7. Acknowledgments 464 This document reuses requirements captured outside the IETF, namely 465 ETSI (with [ETSI-TS-102-182]), and the 3GPP (with [3GPP-TR-22.968]). 466 We would like to thank the authors of these specifications for their 467 work. Note, however, that only a small subset of the requirements 468 have been reflected that do not relate to specific deployments, user 469 interface aspects, detailed regulatory requirements, management and 470 operational considerations, and non-IP specific technologies. 472 We would like to thank Leopold Murhammer for his review in July 2007. 474 8. References 476 8.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 8.2. Informative References 483 [3GPP-TR-22.968] 484 , ., "3GPP TR 22.968, V1.0.0 (2007-04), 3rd Generation 485 Partnership Project; Technical Specification Group 486 Services and System Aspects; Study for requirements for a 487 Public Warning System (PWS) Service (Release 8)", 488 December 2006. 490 [ETSI-TS-102-182] 491 , ., "ETSI TS 102 182, V1.2.1 (2006-12), Technical 492 Specification, Emergency Communications (EMTEL); 493 Requirements for communications from authorities/ 494 organizations to individuals, groups or the general public 495 during emergencies", December 2006. 497 Authors' Addresses 499 Steve Norreys 500 BT Group 501 1 London Road 502 Brentwood, Essex CM14 4QP 503 UK 505 Phone: +44 1277 32 32 20 506 Email: steve.norreys@bt.com 508 Hannes Tschofenig 509 Nokia Siemens Networks 510 Linnoitustie 6 511 Espoo 02600 512 Finland 514 Phone: +358 (50) 4871445 515 Email: Hannes.Tschofenig@gmx.net 516 URI: http://www.tschofenig.priv.at 518 Henning Schulzrinne 519 Columbia University 520 Department of Computer Science 521 450 Computer Science Building 522 New York, NY 10027 523 US 525 Phone: +1 212 939 7004 526 Email: hgs+ecrit@cs.columbia.edu 527 URI: http://www.cs.columbia.edu