idnits 2.17.00 (12 Aug 2021) /tmp/idnits15424/draft-norreys-ecrit-authority2individuals-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 394. 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 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 (July 12, 2008) is 5061 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 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: January 13, 2009 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 July 12, 2008 10 Requirements for Authority-to-Individuals Communication for Emergency 11 Situations 12 draft-norreys-ecrit-authority2individuals-requirements-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 13, 2009. 39 Abstract 41 Public safety agencies need to provide information to the general 42 public before and during large-scale emergencies. While many aspects 43 of such systems are specific to national or local jurisdictions, 44 emergencies span such boundaries and notifications need to reach 45 visitors from other jurisdictions. This document summarizes 46 requirements for protocols to alert individuals within a defined 47 geographic area. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 55 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 56 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 61 Intellectual Property and Copyright Statements . . . . . . . . . . 10 63 1. Introduction 65 During large-scale emergencies, public safety authorities need to 66 reliably communicate with citizens in the affected areas, to provide 67 warnings, indicate whether citizens should evacuate and how, and to 68 dispel misinformation. Accurate information can reduce the impact of 69 such emergencies. 71 Traditionally, emergency alerting has used church bells, sirens, 72 loudspeakers, radio and television to warn citizens and to provide 73 information. However, techniques such as sirens and bells provide 74 limited information content; loud speakers cover only very small 75 areas and are often hard to understand, even for those not hearing 76 impaired or fluent in the local language. Radio and television offer 77 larger information volume, but are hard to target geographically and 78 do not work well to address the "walking wounded" or other 79 pedestrians. Both are not suitable for warnings, as many of those 80 needing the information will not be listening or watching at any 81 given time, particularly during work/school and sleep hours. 83 This problem has recently been illustrated by the London underground 84 bombing on July 7, 2006, as described in a government report [ref]. 85 The UK authorities could only use broadcast media and could not, for 86 example, easily announce to the "walking wounded" where to assemble. 88 This document summarizes key requirements for IP-based protocols to 89 enhance and complement existing authority-to-citizen warning systems. 90 These protocols may either directly reach the citizen or may be used 91 to trigger more traditional alerts, such as, among many others, 92 displays in subway stations, electronic bill boards, or SMS. 94 Public safety authorities need to reach, with an appropriate message, 95 as many affected people as possible within the area impacted by the 96 emergency, including not just residents, but also workers and 97 travelers who may only be in the area temporarily. 99 In addition, people around the immediately affected area should be 100 able to receive information and differentiated instructions, such as 101 warnings to avoid travel or to clear roads. 103 Emergency alerts may be issued once for an emergency or authorities 104 may repeat or update information during an event. 106 Some messages are addressed to all individuals within a certain 107 geographic area. Other messages may target only specific individuals 108 or groups of individuals, such as medical personnel or those 109 particularly susceptible to an incident. 111 Machine-parseable alerts may also be used to trigger automated 112 behaviors, such as closing vents during a chemical spill or 113 activating sirens or other warning systems in commercial buildings. 115 At least initially, mobile and stationary devices may not have the 116 appropriate capabilities to receive such warnings. Thus, protocols 117 need to be designed to allow gatewaying to traditional systems, e.g., 118 the PSTN. 120 We assume an event notification model, i.e., individuals subscribe to 121 warnings that affect their current location. As a mobile device 122 moves, the subscription may need to be updated. Thus, location 123 information needs to be available during the subscription process. 125 Users may want to subscribe to warnings that do not affect their 126 current location. For example, parents may want to be alerted of 127 emergencies affecting the school attended by their children and adult 128 children may need to know about emergencies affecting elderly 129 parents. 131 Some technologies may also support network-level broadcast or 132 multicast. 134 2. Terminology 136 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119], with the 139 important qualification that, unless otherwise stated, these terms 140 apply to the design of a protocol conveying emergency alerts and 141 early warning messages, not its implementation or application. 143 This document reuses the terminology introduced by [3GPP-TR-22.968] 144 and modifies it to fit to IETF terminology: 146 Notification Area: 148 Notification area is an area where warning notifications are sent. 150 Public Warning System: 152 A public warning system delivers warning notifications provided by 153 warning notification providers to IP-capable end hosts within 154 notification areas. 156 Warning Notification: 158 Warning notifications notify recipients of the occurrence of 159 current or pending public safety-related events and additionally 160 may provide users with instructions on what to do and where to get 161 help for the duration of the emergency. 163 Warning Notification Provider: 165 A warning notification provider is an agency such as a branch of 166 government or a public transport agency that provides warning 167 notifications. A private institution, such as a university, 168 hospital or enterprise, may also provide such warnings to people 169 located within their facilities. 171 3. Requirements 173 The objective of these requirements is to allow authorities dealing 174 with an emergency situation to communicate adequately with effected 175 people in a timely fashion. 177 Req-1: 179 The protocol mechanisms MUST provide real-time message delivery. 181 Req-2: 183 The protocol mechanisms MUST deliver messages within a pre-planned 184 time frame in the future, as agencies may want to prepare 185 announcements for predictable or likely events. 187 Req-3: 189 The protocol mechanisms MUST convey sufficient details of the 190 emergency situation. 192 Req-4: 194 The protocol mechanisms MUST provide the public with sufficient 195 instructions to take appropriate actions. 197 Req-5: 199 The protocol mechanisms MUST allow targeting notifications to 200 specific individuals, groups of individuals or specific geographic 201 regions. Different regions or groups may receive different 202 instructions for the same emergency. (For example, people very 203 close to a chemical spill may be asked to evacuate, while those 204 further away may be asked to close windows.) 206 Req-6 208 Early warning notifications MAY be given preferential processing 209 and delivery treatment. 211 Req-7 213 The protocol mechanisms MUST allow delivery of messages 214 simultaneously to a large audience. 216 Req-8 218 The protocol mechanisms MAY provide an option to return a receipt 219 on reading message. Message alert confirmation SHOULD NOT be 220 required. 222 Req-9: 224 An emergency notification system MUST be independent of the 225 underlying access network technology. 227 Req-10: 229 Protocol mechanisms MUST allow to tailor the message to the 230 language preferences of the receiver and/or deliver multiple 231 versions in different languages within the same message, so that 232 the recipient can choose the most appropriate one. 234 Req-11: 236 A solution MUST support delivery of notification messages (e.g., 237 with different media types) to those with special needs, such as 238 hearing and vision impaired. 240 Req-12: 242 A user SHOULD be able to indicate the preferred method of 243 communication to the public warning service, such as notification 244 by email, different instant messaging protocols or automated voice 245 calls. 247 Req-13: 249 A solution MUST prevent misuse of the emergency infrastructure by 250 unauthorized entities. 252 Req-14: 254 Emergency notification systems SHOULD identify the message and 255 notification originator, preferably in a cryptographically secure 256 manner. 258 Req-15: 260 A solution MUST offer sufficient details of the emergency 261 situation. 263 Req-16: 265 A solution MUST support integrity protection of early warning 266 notifications. 268 Req-17: 270 A solution MUST provide a mechanism for testing authority-to- 271 individuals early warning messages just as test support is 272 provided by individuals-to-authority emergency services. 274 Req-18: 276 Devices should be able to recognize alerts that requires that the 277 device override user interface configurations such as vibrate-only 278 mode. (For example, a school closing advisory due to snow may not 279 require such an immediate alert in the middle of the night.) 281 4. IANA Considerations 283 This document does not require actions by IANA. 285 5. Security considerations 287 This document outlines requirements and security security 288 requirements are a part of them. 290 6. Acknowledgments 292 This document reuses requirements captured outside the IETF, namely 293 ETSI (with [ETSI-TS-102-182]), and the 3GPP (with [3GPP-TR-22.968]). 294 We would like to thank the authors of these specifications for their 295 work. Note, however, that only a small subset of the requirements 296 have been reflected that do not relate to specific deployments, user 297 interface aspects, detailed regulatory requirements, management and 298 operational considerations, and non-IP specific technologies. 300 We would like to thank Leopold Murhammer for his review in July 2007. 302 7. References 304 7.1. Normative References 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 7.2. Informative References 311 [3GPP-TR-22.968] 312 , ., "3GPP TR 22.968, V1.0.0 (2007-04), 3rd Generation 313 Partnership Project; Technical Specification Group 314 Services and System Aspects; Study for requirements for a 315 Public Warning System (PWS) Service (Release 8)", 316 December 2006. 318 [ETSI-TS-102-182] 319 , ., "ETSI TS 102 182, V1.2.1 (2006-12), Technical 320 Specification, Emergency Communications (EMTEL); 321 Requirements for communications from authorities/ 322 organizations to individuals, groups or the general public 323 during emergencies", December 2006. 325 Authors' Addresses 327 Steve Norreys 328 BT Group 329 1 London Road 330 Brentwood, Essex CM14 4QP 331 UK 333 Phone: +44 1277 32 32 20 334 Email: steve.norreys@bt.com 335 Hannes Tschofenig 336 Nokia Siemens Networks 337 Linnoitustie 6 338 Espoo 02600 339 Finland 341 Phone: +358 (50) 4871445 342 Email: Hannes.Tschofenig@gmx.net 343 URI: http://www.tschofenig.priv.at 345 Henning Schulzrinne 346 Columbia University 347 Department of Computer Science 348 450 Computer Science Building 349 New York, NY 10027 350 US 352 Phone: +1 212 939 7004 353 Email: hgs+ecrit@cs.columbia.edu 354 URI: http://www.cs.columbia.edu 356 Full Copyright Statement 358 Copyright (C) The IETF Trust (2008). 360 This document is subject to the rights, licenses and restrictions 361 contained in BCP 78, and except as set forth therein, the authors 362 retain all their rights. 364 This document and the information contained herein are provided on an 365 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 366 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 367 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 368 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 369 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 370 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 372 Intellectual Property 374 The IETF takes no position regarding the validity or scope of any 375 Intellectual Property Rights or other rights that might be claimed to 376 pertain to the implementation or use of the technology described in 377 this document or the extent to which any license under such rights 378 might or might not be available; nor does it represent that it has 379 made any independent effort to identify any such rights. Information 380 on the procedures with respect to rights in RFC documents can be 381 found in BCP 78 and BCP 79. 383 Copies of IPR disclosures made to the IETF Secretariat and any 384 assurances of licenses to be made available, or the result of an 385 attempt made to obtain a general license or permission for the use of 386 such proprietary rights by implementers or users of this 387 specification can be obtained from the IETF on-line IPR repository at 388 http://www.ietf.org/ipr. 390 The IETF invites any interested party to bring to its attention any 391 copyrights, patents or patent applications, or other proprietary 392 rights that may cover technology that may be required to implement 393 this standard. Please address the information to the IETF at 394 ietf-ipr@ietf.org.