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