idnits 2.17.00 (12 Aug 2021) /tmp/idnits44664/draft-norreys-ecrit-authority2individuals-requirements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 6, 2010) is 4452 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-crocker-email-arch has been published as RFC 5598 -- Obsolete informational reference (is this intentional?): RFC 4244 (Obsoleted by RFC 7044) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 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 7, 2010 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 March 6, 2010 10 Requirements, Terminology and Framework for Exigent Communications 11 draft-norreys-ecrit-authority2individuals-requirements-04.txt 13 Abstract 15 Various agencies need to provide information to the restricted group 16 of persons or even to the generic public before, during and after 17 emergency situations. While many aspects of such systems are 18 specific to national or local jurisdictions, emergencies span such 19 boundaries and notifications need to reach visitors from other 20 jurisdictions. This document summarizes requirements for protocols 21 to allow alerts to be conveyed to IP-based end points. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on September 7, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Classical Early Warning Situations . . . . . . . . . . . . 3 65 1.2. Exigent Communications . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Responsible Actor Roles . . . . . . . . . . . . . . . . . . . 5 68 3.1. User Actors . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1.1. Author . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1.2. Recipient . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1.3. Return Handler . . . . . . . . . . . . . . . . . . . . 6 72 3.1.4. Mediator . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2. Message Handling Service (MHS) Actors . . . . . . . . . . 7 74 3.2.1. Originator . . . . . . . . . . . . . . . . . . . . . . 8 75 3.2.2. Relay . . . . . . . . . . . . . . . . . . . . . . . . 9 76 3.2.3. Gateway . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.2.4. Receiver . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.3. Administrative Actors . . . . . . . . . . . . . . . . . . 10 79 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.1. Communication Model Independent Requirements . . . . . . . 11 81 4.2. Requirements for a Subscription Model . . . . . . . . . . 11 82 4.3. Requirements for a Push Communication Model . . . . . . . 12 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 6. Security considerations . . . . . . . . . . . . . . . . . . . 13 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 1.1. Classical Early Warning Situations 95 During large-scale emergencies, public safety authorities need to 96 reliably communicate with citizens in the affected areas, to provide 97 warnings, indicate whether citizens should evacuate and how, and to 98 dispel misinformation. Accurate information can reduce the impact of 99 such emergencies. 101 Traditionally, emergency alerting has used church bells, sirens, 102 loudspeakers, radio and television to warn citizens and to provide 103 information. However, techniques, such as sirens and bells, provide 104 limited information content; loud speakers cover only very small 105 areas and are often hard to understand, even for those not hearing 106 impaired or fluent in the local language. Radio and television offer 107 larger information volume, but are hard to target geographically and 108 do not work well to address the "walking wounded" or other 109 pedestrians. Both are not suitable for warnings, as many of those 110 needing the information will not be listening or watching at any 111 given time, particularly during work/school and sleep hours. 113 This problem has been illustrated by the London underground bombing 114 on July 7, 2006, as described in a government report [July2005]. The 115 UK authorities could only use broadcast media and could not, for 116 example, easily announce to the "walking wounded" where to assemble. 118 1.2. Exigent Communications 120 With the usage of the term 'Exigent Communications' this document 121 aims to generalize the concept of conveying alerts to IP-based 122 systems and at the same time to re-define the actors that participate 123 in the messaging communication. More precisely, exigent 124 communications is defined as: 126 Communication that requirs immediate action or remedy. 127 Information about the reason for action and details about the 128 steps that have to be taken are provided in the alert message. 130 An alert message (or warning message) is a cautionary advice about 131 something imminent (especially imminent danger or other 132 unpleasantness). In the context of exigent communication such an 133 alert message refers to a future, ongoing or past event as the 134 signaling exchange itself may relate to different stages of the 135 lifecycle of the event. The alert message itself, and not the 136 signaling protocol, provides sufficient context about the specific 137 state of the lifecycle the alert message refers to. 139 For that purpose, the terminology utilized by the EMail architecture, 140 see [I-D.crocker-email-arch], is applied to this context. 142 Three types of communication models can be envisioned: 144 1. Alerts may be addressed to all individuals within a certain 145 geographic area. Today, this is often realized with the help of 146 dedicated functionality provided by link layer technology (e.g., 147 multicast, broadcast). 149 2. Alerts need to be delivered to dedicated end points via unicast 150 messaging. Examples are displays in subway stations, or 151 electronic bill boards. Some of these alerts may also be used to 152 trigger automated behaviors, such as closing vents during a 153 chemical spill or activating sirens or other warning systems in 154 commercial buildings. Other messages may target only specific 155 groups of individuals, such as medical personnel. These may 156 include cases where legacy end points need to be integrated into 157 the overall architecture and some form of protocol translation is 158 necessary. The communication end point from an IP point of view 159 is therefore a single gateway (or a small number of them). 161 3. The two models described above illustrate a push communication 162 whereas the third model represents a subscription model where an 163 opt-in model is used to provide further information about the 164 type of alerts that the recipient is interested in. The 165 information that may lead to an alert message being distributed 166 may depend on certain factors, including certain types of events 167 happening in a specific geographic region irrespectively of 168 whether the entity issuing the subscription is actually located 169 in that geographic region. For example, parents may want to be 170 alerted of emergencies affecting the school attended by their 171 children and adult children may need to know about emergencies 172 affecting elderly parents. 174 This document focuses on all three types of communication models 175 whereby a stronger emphasis is given to the subscription model since 176 it is very powerful but less widely deployed on the Internet for 177 exigent communication. Content-wise this document provides 178 terminology, requirements and the architecture for IP-based protocols 179 to enhance and complement existing authority-to-citizen warning 180 systems. 182 2. Terminology 184 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119], with the 187 important qualification that, unless otherwise stated, these terms 188 apply to the design of a protocol conveying warning messages, not its 189 implementation or application. 191 This document reuses the terminology from [I-D.crocker-email-arch]. 192 For editorial and consistency reasons parts of the text are repeated 193 in this document and modified as appropriate. 195 3. Responsible Actor Roles 197 The communication system used for the dissemination of alert messages 198 builds on top of existing communication infrastructure. These 199 distributed services consist of a variety of actors playing different 200 roles. These actors fall into three basic categories: 202 o User 203 o Message Handling Service (MHS) 204 o ADministrative Management Domain (ADMD) 206 3.1. User Actors 208 Users are the sources and sinks of alert messages. Users can be 209 people, organizations, or processes. There are four types of Users: 211 o Authors 212 o Recipients 213 o Return Handlers 214 o Mediators 216 From the user perspective, all alert message transfer activities are 217 performed by a monolithic Message Handling Service (MHS), even though 218 the actual service can be provided by many independent organizations. 220 Whenever any MHS actor sends information to back to an Author or 221 Originator in the sequence of handling a message, that actor is a 222 User. 224 3.1.1. Author 226 The Author is responsible for creating the alert message, its 227 contents, and its intended recipients, even though the exact list of 228 recipients may be unknown to the Author at the time of writing the 229 alert message. The MHS transfers the alert message from the Author 230 and delivers it to the Recipients. The MHS has an Originator role 231 that correlates with the Author role. 233 3.1.2. Recipient 235 The Recipient is a consumer of the delivered alert message. The MHS 236 has a Receiver role that correlates with the Recipient role. 238 3.1.3. Return Handler 240 The Return Handler is a special form of Recipient tasked with 241 servicing notifications that the MHS generates, as it transfers or 242 delivers the message. These notices can be about failures or 243 completions (such as utilized by test messages) and are sent to an 244 address that is specified by the Originator. This Return Handling 245 address (also known as a Return address) might have no visible 246 characteristics in common with the address of the Author or 247 Originator. 249 3.1.4. Mediator 251 A Mediator receives, aggregates, reformulates, and redistributes 252 alert messages among Authors and Recipients who are the principals in 253 (potentially) protracted exchanges. When submitting a reformulated 254 message, the Mediator is an Author, albeit an author actually serving 255 as an agent of one or more other authors. So, a Mediator really is a 256 full-fledged User. 258 The aspect of a Mediator that distinguishes it from any other MUA 259 creating a message is that a Mediator preserves the integrity and 260 tone of the original message, including the essential aspects of its 261 origination information. The Mediator might also add commentary. 263 A Mediator attempts to preserve the original Author's information in 264 the message it reformulates but is permitted to make meaningful 265 changes to the message content or envelope. The MHS sees a new 266 message, but users receive a message that they interpret as being 267 from, or at least initiated by, the Author of the original message. 268 The role of a Mediator is not limited to merely connecting other 269 participants; the Mediator is responsible for the new message. 271 A Mediator's role is complex and contingent, for example, modifying 272 and adding content or regulating which users are allowed to 273 participate and when. The common example of this role is an 274 aggregator that accepts alert messages from a set of Originators and 275 distributes them to a potentially large set of Recipients. This 276 functionality is similar to a multicast, or even a broadcast. 277 Recipients might have also indicated their interest to receive 278 certain type of alerts messages or they might implicitly get entitled 279 to receive specific alerts purely by their presence in a specific 280 geographical region. Hence, a Mediator might have additional 281 information about the Recipients context and might therefore be able 282 to make a decision whether the Recipient is interested in receiving a 283 particular alert message. 285 A Gateway is a particularly interesting form of Mediator. It is a 286 hybrid of User and Relay that connects to other communication 287 systems. Its purpose is to emulate a Relay. 289 3.2. Message Handling Service (MHS) Actors 291 The Message Handling Service (MHS) performs a single end-to-end 292 transfer of warning messages on behalf of the Author to reach the 293 Recipient addresses. Exchanges that are either mediated or iterative 294 and protracted, such as those used for communicating information 295 about the lifetime of an alert are handled by the User actors, not by 296 the MHS actors. As a pragmatic heuristic MHS actors actors generate, 297 modify or look at only transfer data, rather than the entire message. 299 Figure 1 shows the relationships among transfer participants. 300 Although it shows the Originator as distinct from the Author and 301 Receiver as distinct from Recipient, each pair of roles usually has 302 the same actor. Transfers typically entail one or more Relays. 303 However, direct delivery from the Originator to Receiver is possible. 304 Delivery of warning messages within a single administrative boundary 305 usually only involve a single Relay. 307 ++==========++ ++===========++ 308 || Author || || Recipient || 309 ++====++====++ +--------+ ++===========++ 310 || | Return | /\ 311 || +-+------+ || 312 \/ . ^ || 313 +----------+ . . +---++----+ 314 | | . . | | 315 /-+----------+----------------------------+---------+---\ 316 | | | . . MHS | | | 317 | |Originator+<...........................+Receiver | | 318 | | | ^ | | | 319 | +---++-----+ . +---------+ | 320 | || . /\ | 321 | || ...............+.................. || | 322 | \/ . . . || | 323 | +-------+-+ +--+------+ +-+--++---+ | 324 | | Relay +======-=>| Relay +=======>| Relay | | 325 | +---------+ +----++---+ +---------+ | 326 | || | 327 | || | 328 | \/ | 329 | +---------+ | 330 | | Gateway +-->... | 331 | +---------+ | 332 \-------------------------------------------------------/ 334 Legend: === and || lines indicate primary (possibly 335 indirect) transfers or roles 336 ... lines indicate supporting transfers or roles 338 Figure 1: Relationships Among MHS Actors 340 3.2.1. Originator 342 The Originator ensures that a warning message is valid for transfer 343 and then submits it to a Relay. A message is valid if it conforms to 344 both communication and warning message encapsulation standards and 345 local operational policies. The Originator can simply review the 346 message for conformance and reject it if it finds errors, or it can 347 create some or all of the necessary information. 349 The Originator operates with dual allegiance. It serves the Author 350 and can be the same entity. But its role in assuring validity means 351 that it also represents the local operator of the MHS, that is, the 352 local ADministrative Management Domain (ADMD). 354 The Originator also performs any post-submission, Author-related 355 administrative tasks associated with message transfer and delivery. 356 Notably, these tasks pertain to sending error and delivery notices, 357 enforcing local policies, and dealing with messages from the Author 358 that prove to be problematic for the Internet. The Originator is 359 accountable for the message content, even when it is not responsible 360 for it. The Author creates the message, but the Originator handles 361 any transmission issues with it. 363 3.2.2. Relay 365 The Relay performs MHS-level transfer-service routing and store-and- 366 forward, by transmitting or retransmitting the message to its 367 Recipients. The Relay may add history / trace information 368 information (e.g., as available with SIP History Info [RFC4244]) or 369 security related protection (e.g., as available with SIP Identity 370 [RFC4474]) but does not modify the envelope information or the 371 message content semantics. 373 A Message Handling System (MHS) network consists of a set of Relays. 374 This network is above any underlying packet-switching network that 375 might be used and below any Gateways or other Mediators. 377 3.2.3. Gateway 379 A Gateway is a hybrid of User and Relay that connects heterogeneous 380 communication infrastructures. Its purpose is to emulate a Relay and 381 the closer it comes to this, the better. A Gateway operates as a 382 User when it needs the ability to modify message content. 384 Differences between the different communication systems can be as 385 small as minor syntax variations, but they usually encompass 386 significant, semantic distinctions. Hence, the Relay function in a 387 Gateway presents a significant design challenge, if the resulting 388 performance is to be seen as nearly seamless. The challenge is to 389 ensure user-to-user functionality between the communication services, 390 despite differences in their syntax and semantics. 392 The basic test of Gateway design is whether an Author on one side of 393 a Gateway can send a useful warning message to a Recipient on the 394 other side, without requiring changes to any components in the 395 Author's or Recipient's communication service other than adding the 396 Gateway. To each of these otherwise independent services, the 397 Gateway appears to be a native participant. 399 3.2.4. Receiver 401 The Receiver performs final delivery or sends the warning message to 402 an alternate address. In case of warning messages it is typically 403 responsible for ensuring that the appropriate user interface 404 interactions are triggered. 406 3.3. Administrative Actors 408 Administrative actors can be associated with different organizations, 409 each with its own administrative authority. This operational 410 independence, coupled with the need for interaction between groups, 411 provides the motivation to distinguish among ADministrative 412 Management Domains (ADMDs). Each ADMD can have vastly different 413 operating policies and trust-based decision-making. One obvious 414 example is the distinction between warning messages that are 415 exchanged within an closed group (such as alert messages received by 416 parents affecting the school attended by their children) and warning 417 messages that exchanged between independent organizations (e.g., in 418 case of large scale disasters). The rules for handling both types of 419 traffic tend to be quite different. That difference requires 420 defining the boundaries of each, and this requires the ADMD 421 construct. 423 Operation of communication systems that are used to convey alert 424 messages are typically carried out by different providers (or 425 operators). Each can be an independent ADMD. The benefit of the 426 ADMD construct is to facilitate discussion about designs, policies 427 and operations that need to distinguish between internal issues and 428 external ones. Most significant is that the entities communicating 429 across ADMD boundaries typically have the added burden of enforcing 430 organizational policies concerning external communications. At a 431 more mundane level, routing mail between ADMDs can be an issue, such 432 as needing to route alert messages between organizational partners 433 over specially trusted paths. 435 The interactions of ADMD components are subject to the policies of 436 that domain, which cover concerns such as these: 438 o Reliability 439 o Access control 440 o Accountability 441 o Content evaluation, adaptation, and modification 443 4. Requirements 445 Requirements that relate to the encoding and the content of alert 446 messages is outside the scope of this document. This document 447 focuses on protocols being utilized to convey alert messages only. 449 The requirements for the two main communication models are different 450 and reflected in separate sub-sections, Section 4.2 and Section 4.3 . 451 There are, however, a few generic requirements applicable to both 452 communication models described in Section 4.1. 454 4.1. Communication Model Independent Requirements 456 Req-G1: 458 The protocol solution MUST allow delivery of messages 459 simultaneously to a large audience. 461 Req-G2: 463 The protocol solution MUST be independent of the underlying link 464 layer technology. 466 Req-G3: 468 The protocol solution MUST offer the typical communication 469 security mechanisms. Additional security mechanisms applied to 470 the alert message itself are outside the scope of the 471 communication protocol and therefore outside the scope of this 472 document. 474 Req-G4: 476 The protocol solution MUST allow targeting notifications to 477 specific individuals and to groups of individuals. 479 Req-G5: 481 The protocol solution MAY provide an option to return a receipt on 482 reading message. 484 Req-G6: 486 The protocol solution MUST ensure that congestion handling is 487 provided. 489 4.2. Requirements for a Subscription Model 491 The requirements for subscription / opt-in model require information 492 about the type of alerts that are being asked for to be made 493 available by the potential Recipient to the Originator or set of 494 orginators. 496 Req-S1: 498 The protocol solution MUST allow to tailor the message to the 499 language preferences of the receiver. 501 Req-S2: 503 The protocol solution MUST allow an indication about the 504 geographical area the potential Recipient is interested in. 506 Req-S3: 508 The protocol solution MUST allow an indication about the type of 509 alert the potential Recipient is interested in. 511 Req-S4: 513 The protocol solution MUST allow an indication of the media types 514 that are understood or preferred by the potential Recipient. 516 The support for different media types depends to some extend on 517 the content of the warning message but the communication protocol 518 may be impacted as well. This functionality would, for example, 519 be useful for those with special needs, such as hearing and vision 520 impaired persons. 522 Req-S5: 524 The protocol solution MUST allow a potential Recipient to discover 525 the responsible Originator or set of Originators for a certain 526 category of warning messages. 528 4.3. Requirements for a Push Communication Model 530 The topological structure of networks is used to distribute warning 531 notifications to all hosts that are located within a specific IP- 532 subsetwork or multicast group. 534 Req-P1: 536 The protocol solution MUST allow network layer multicast and 537 broadcast mechanisms to be utilized. 539 5. IANA Considerations 541 This document does not require actions by IANA. 543 6. Security considerations 545 This document outlines requirements and security requirements are a 546 part of them. 548 7. Acknowledgments 550 This document re-uses a lot of text from [I-D.crocker-email-arch]. 551 The authors would like to thank Dave Crocker for his work. 553 8. References 555 8.1. Normative References 557 [I-D.crocker-email-arch] 558 Crocker, D., "Internet Mail Architecture", 559 draft-crocker-email-arch-14 (work in progress), June 2009. 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, March 1997. 564 8.2. Informative References 566 [July2005] 567 , ., "Report of the 7 July Review Committee, ISBN 1 568 85261 878 7", (PDF document), http://www.london.gov.uk/ 569 assembly/reports/7july/report.pdf, June 2006. 571 [RFC4244] Barnes, M., "An Extension to the Session Initiation 572 Protocol (SIP) for Request History Information", RFC 4244, 573 November 2005. 575 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 576 Authenticated Identity Management in the Session 577 Initiation Protocol (SIP)", RFC 4474, August 2006. 579 Authors' Addresses 581 Steve Norreys 582 BT Group 583 1 London Road 584 Brentwood, Essex CM14 4QP 585 UK 587 Phone: +44 1277 32 32 20 588 Email: steve.norreys@bt.com 590 Hannes Tschofenig 591 Nokia Siemens Networks 592 Linnoitustie 6 593 Espoo 02600 594 Finland 596 Phone: +358 (50) 4871445 597 Email: Hannes.Tschofenig@gmx.net 598 URI: http://www.tschofenig.priv.at 600 Henning Schulzrinne 601 Columbia University 602 Department of Computer Science 603 450 Computer Science Building 604 New York, NY 10027 605 US 607 Phone: +1 212 939 7004 608 Email: hgs+ecrit@cs.columbia.edu 609 URI: http://www.cs.columbia.edu