idnits 2.17.00 (12 Aug 2021) /tmp/idnits13593/draft-norreys-ecrit-authority2individuals-requirements-00.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 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 395. 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 1, 2007) is 5438 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 2, 2008 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 July 1, 2007 10 Requirements for Authority-to-Individuals Communication for Emergency 11 Situations 12 draft-norreys-ecrit-authority2individuals-requirements-00.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 2, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 Public safety agencies need to provide information to the general 46 public before and during large-scale emergencies. While many aspects 47 of such systems are specific to national or local jurisdictions, 48 emergencies span such boundaries and notifications need to reach 49 visitors from other jurisdictions. This document summarizes 50 requirements for protocols to alert individuals within a defined 51 geographic area. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . . . 10 67 1. Introduction 69 During large-scale emergencies, public safety authorities need to 70 reliably communicate with citizens in the affected areas, to provide 71 warnings, indicate whether citizens should evacuate and how, and to 72 dispel misinformation. Accurate information can reduce the impact of 73 such emergencies. 75 Traditionally, emergency alerting has used church bells, sirens, 76 loudspeakers, radio and television to warn citizens and to provide 77 information. However, techniques such as sirens and bells provide 78 limited information content; loud speakers cover only very small 79 areas and are often hard to understand, even for those not hearing 80 impaired or fluent in the local language. Radio and television offer 81 larger information volume, but are hard to target geographically and 82 do not work well to address the "walking wounded" or other 83 pedestrians. Both are not suitable for warnings, as many of those 84 needing the information will not be listening or watching at any 85 given time, particularly during work/school and sleep hours. 87 This problem has recently been illustrated by the London underground 88 bombing on July 7, 2006, as described in a government report [ref]. 89 The UK authorities could only use broadcast media and could not, for 90 example, easily announce to the "walking wounded" where to assemble. 92 This document summarizes key requirements for IP-based protocols to 93 enhance and complement existing authority-to-citizen warning systems. 94 These protocols may either directly reach the citizen or may be used 95 to trigger more traditional alerts, such as, among many others, 96 displays in subway stations, electronic bill boards, or SMS. 98 Public safety authorities need to reach, with an appropriate message, 99 as many affected people as possible within the area impacted by the 100 emergency, including not just residents, but also workers and 101 travelers who may only be in the area temporarily. 103 In addition, people around the immediately affected area should be 104 able to receive information and differentiated instructions, such as 105 warnings to avoid travel or to clear roads. 107 Emergency alerts may be issued once for an emergency or authorities 108 may repeat or update information during an event. 110 Some messages are addressed to all individuals within a certain 111 geographic area. Other messages may target only specific individuals 112 or groups of individuals, such as medical personnel or those 113 particularly susceptible to an incident. 115 Machine-parseable alerts may also be used to trigger automated 116 behaviors, such as closing vents during a chemical spill or 117 activating sirens or other warning systems in commercial buildings. 119 At least initially, mobile and stationary devices may not have the 120 appropriate capabilities to receive such warnings. Thus, protocols 121 need to be designed to allow gatewaying to traditional systems, e.g., 122 the PSTN. 124 We assume an event notification model, i.e., individuals subscribe to 125 warnings that affect their current location. As a mobile device 126 moves, the subscription may need to be updated. Thus, location 127 information needs to be available during the subscription process. 129 Users may want to subscribe to warnings that do not affect their 130 current location. For example, parents may want to be alerted of 131 emergencies affecting the school attended by their children and adult 132 children may need to know about emergencies affecting elderly 133 parents. 135 Some technologies may also support network-level broadcast or 136 multicast. 138 2. Terminology 140 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119], with the 143 important qualification that, unless otherwise stated, these terms 144 apply to the design of a protocol conveying emergency alerts and 145 early warning messages, not its implementation or application. 147 This document reuses the terminology introduced by [3GPP-TR-22.968] 148 and modifies it to fit to IETF terminology: 150 Notification Area: 152 Notification area is an area where warning notifications are sent. 154 Public Warning System: 156 A public warning system delivers warning notifications provided by 157 warning notification providers to IP-capable end hosts within 158 notification areas. 160 Warning Notification: 162 Warning notifications notify recipients of the occurrence of 163 current or pending public safety-related events and additionally 164 may provide users with instructions on what to do and where to get 165 help for the duration of the emergency. 167 Warning Notification Provider: 169 A warning notification provider is an agency such as a branch of 170 government or a public transport agency that provides warning 171 notifications. A private institution, such as a university, 172 hospital or enterprise, may also provide such warnings to people 173 located within their facilities. 175 3. Requirements 177 The objective of these requirements is to allow authorities dealing 178 with an emergency situation to communicate adequately with effected 179 people in a timely fashion. 181 Req-1: 183 The protocol mechanisms MUST provide real-time message delivery. 185 Req-2: 187 The protocol mechanisms MUST deliver messages within a pre-planned 188 time frame in the future, as agencies may want to prepare 189 announcements for predictable or likely events. 191 Req-3: 193 The protocol mechanisms MUST convey sufficient details of the 194 emergency situation. 196 Req-4: 198 The protocol mechanisms MUST provide the public with sufficient 199 instructions to take appropriate actions. 201 Req-5: 203 The protocol mechanisms MUST allow targeting notifications to 204 specific individuals, groups of individuals or specific geographic 205 regions. Different regions or groups may receive different 206 instructions for the same emergency. (For example, people very 207 close to a chemical spill may be asked to evacuate, while those 208 further away may be asked to close windows.) 210 Req-6 212 Early warning notifications MAY be given preferential processing 213 and delivery treatment. 215 Req-7 217 The protocol mechanisms MUST allow delivery of messages 218 simultaneously to a large audience. 220 Req-8 222 The protocol mechanisms MAY provide an option to return a receipt 223 on reading message. Message alert confirmation SHOULD NOT be 224 required. 226 Req-9: 228 An emergency notification system MUST be independent of the 229 underlying access network technology. 231 Req-10: 233 Protocol mechanisms MUST allow to tailor the message to the 234 language preferences of the receiver and/or deliver multiple 235 versions in different languages within the same message, so that 236 the recipient can choose the most appropriate one. 238 Req-11: 240 A solution MUST support delivery of notification messages (e.g., 241 with different media types) to those with special needs, such as 242 hearing and vision impaired. 244 Req-12: 246 A user SHOULD be able to indicate the preferred method of 247 communication to the public warning service, such as notification 248 by email, different instant messaging protocols or automated voice 249 calls. 251 Req-13: 253 A solution MUST prevent misuse of the emergency infrastructure by 254 unauthorized entities. 256 Req-14: 258 Emergency notification systems SHOULD identify the message and 259 notification originator, preferably in a cryptographically secure 260 manner. 262 Req-15: 264 A solution MUST offer sufficient details of the emergency 265 situation. 267 Req-16: 269 A solution MUST support integrity protection of early warning 270 notifications. 272 Req-17: 274 A solution MUST provide a mechanism for testing authority-to- 275 individuals early warning messages just as test support is 276 provided by individuals-to-authority emergency services. 278 Req-18: 280 Devices should be able to recognize alerts that requires that the 281 device override user interface configurations such as vibrate-only 282 mode. (For example, a school closing advisory due to snow may not 283 require such an immediate alert in the middle of the night.) 285 4. IANA Considerations 287 This document does not require actions by IANA. 289 5. Security considerations 291 This document outlines requirements and security security 292 requirements are a part of them. 294 6. Acknowledgments 296 This document reuses requirements captured outside the IETF, namely 297 ETSI (with [ETSI-TS-102-182]), and the 3GPP (with [3GPP-TR-22.968]). 298 We would like to thank the authors of these specifications for their 299 work. Note, however, that only a small subset of the requirements 300 have been reflected that do not relate to specific deployments, user 301 interface aspects, detailed regulatory requirements, management and 302 operational considerations, and non-IP specific technologies. 304 7. References 306 7.1. Normative References 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, March 1997. 311 7.2. Informative References 313 [3GPP-TR-22.968] 314 , ., "3GPP TR 22.968, V1.0.0 (2007-04), 3rd Generation 315 Partnership Project; Technical Specification Group 316 Services and System Aspects; Study for requirements for a 317 Public Warning System (PWS) Service (Release 8)", 318 December 2006. 320 [ETSI-TS-102-182] 321 , ., "ETSI TS 102 182, V1.2.1 (2006-12), Technical 322 Specification, Emergency Communications (EMTEL); 323 Requirements for communications from authorities/ 324 organizations to individuals, groups or the general public 325 during emergencies", December 2006. 327 Authors' Addresses 329 Steve Norreys 330 BT Group 331 1 London Road 332 Brentwood, Essex CM14 4QP 333 UK 335 Phone: +44 1277 32 32 20 336 Email: steve.norreys@bt.com 337 Hannes Tschofenig 338 Nokia Siemens Networks 339 Otto-Hahn-Ring 6 340 Munich, Bavaria 81739 341 Germany 343 Email: Hannes.Tschofenig@nsn.com 344 URI: http://www.tschofenig.com 346 Henning Schulzrinne 347 Columbia University 348 Department of Computer Science 349 450 Computer Science Building 350 New York, NY 10027 351 US 353 Phone: +1 212 939 7004 354 Email: hgs+ecrit@cs.columbia.edu 355 URI: http://www.cs.columbia.edu 357 Full Copyright Statement 359 Copyright (C) The IETF Trust (2007). 361 This document is subject to the rights, licenses and restrictions 362 contained in BCP 78, and except as set forth therein, the authors 363 retain all their rights. 365 This document and the information contained herein are provided on an 366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 368 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 369 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 370 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 373 Intellectual Property 375 The IETF takes no position regarding the validity or scope of any 376 Intellectual Property Rights or other rights that might be claimed to 377 pertain to the implementation or use of the technology described in 378 this document or the extent to which any license under such rights 379 might or might not be available; nor does it represent that it has 380 made any independent effort to identify any such rights. Information 381 on the procedures with respect to rights in RFC documents can be 382 found in BCP 78 and BCP 79. 384 Copies of IPR disclosures made to the IETF Secretariat and any 385 assurances of licenses to be made available, or the result of an 386 attempt made to obtain a general license or permission for the use of 387 such proprietary rights by implementers or users of this 388 specification can be obtained from the IETF on-line IPR repository at 389 http://www.ietf.org/ipr. 391 The IETF invites any interested party to bring to its attention any 392 copyrights, patents or patent applications, or other proprietary 393 rights that may cover technology that may be required to implement 394 this standard. Please address the information to the IETF at 395 ietf-ipr@ietf.org. 397 Acknowledgment 399 Funding for the RFC Editor function is provided by the IETF 400 Administrative Support Activity (IASA).