idnits 2.17.1 draft-ietf-atoca-cap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 date (October 18, 2010) is 4910 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) == Outdated reference: A later version (-09) exists of draft-ietf-sipcore-event-rate-control-04 == Outdated reference: A later version (-03) exists of draft-ietf-atoca-requirements-00 == Outdated reference: A later version (-08) exists of draft-forte-lost-extensions-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ATOCA B. Rosen 3 Internet-Draft NeuStar, Inc. 4 Intended status: Standards Track H. Schulzrinne 5 Expires: April 21, 2011 Columbia U. 6 H. Tschofenig 7 Nokia Siemens Networks 8 October 18, 2010 10 Session Initiation Protocol (SIP) Event Package for the Common Alerting 11 Protocol (CAP) 12 draft-ietf-atoca-cap-00.txt 14 Abstract 16 The Common Alerting Protocol (CAP) is an XML document format for 17 exchanging emergency alerts and public warnings. This document 18 allows CAP documents to be distributed via the event notification 19 mechanism available with the Session Initiation Protocol (SIP). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 21, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. The 'common-alerting-protocol' Event Package . . . . . . . . . 5 58 3.1. Package Name . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 5 60 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 61 3.3.1. Location Filter . . . . . . . . . . . . . . . . . . . 5 62 3.3.2. Service Filter . . . . . . . . . . . . . . . . . . . . 6 63 3.3.3. Rate Control . . . . . . . . . . . . . . . . . . . . . 7 64 3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 7 65 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 7 66 3.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 8 67 3.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8 68 3.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 9 69 3.9. Handling of Forked Requests . . . . . . . . . . . . . . . 9 70 3.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9 71 3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.13. Use of URIs to Retrieve State . . . . . . . . . . . . . . 10 74 3.14. PUBLISH Bodies . . . . . . . . . . . . . . . . . . . . . . 10 75 3.15. PUBLISH Response Bodies . . . . . . . . . . . . . . . . . 10 76 3.16. Multiple Sources for Event State . . . . . . . . . . . . . 10 77 3.17. Event State Segmentation . . . . . . . . . . . . . . . . . 10 78 3.18. Rate of Publication . . . . . . . . . . . . . . . . . . . 11 79 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 5.1. Amplification . . . . . . . . . . . . . . . . . . . . . . 13 82 5.1.1. Forgery of Alerts . . . . . . . . . . . . . . . . . . 14 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 6.1. Registration of the 'common-alerting-protocol' Event 85 Package . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 6.2. Registration of the 87 'application/common-alerting-protocol+xml' MIME type . . . 15 88 6.3. Early Warning Service URNs . . . . . . . . . . . . . . . . 16 89 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 96 1. Introduction 98 The Common Alerting Protocol (CAP) [cap] is an XML document format 99 for exchanging emergency alerts and public warnings. The abstract 100 architectural description for the distribution of alerts can be found 101 in [I-D.ietf-atoca-requirements]. 103 This document specifies how CAP documents are distributed via the 104 event notification mechanism available with the Session Initiation 105 Protocol (SIP). Additionally, a MIME object is registered to allow 106 CAP documents to be exchanged in other SIP messages. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 Note that early warning specific definitions can be found in 115 [I-D.ietf-atoca-requirements]. 117 3. The 'common-alerting-protocol' Event Package 119 RFC 3265 [RFC3265] defines a SIP extension for subscribing to remote 120 nodes and receiving notifications of changes (events) in their 121 states. It leaves the definition of many aspects of these events to 122 concrete extensions, i.e. event packages. This document defines such 123 a new "common-alerting-protocol" event package. RFC 3903 [RFC3903] 124 defines an extension that allows SIP User Agents to publish event 125 state. Event Publication Agents (EPA) use PUBLISH requests to inform 126 an Event State Compositor (ESC) of changes in the "common-alerting- 127 protocol event package. Acting as a notifier, the ESC notifies 128 subscribers about emergency alerts and public warnings. 130 3.1. Package Name 132 The name of this package is "common-alerting-protocol". As specified 133 in RFC 3265 [RFC3265], this value appears in the Event header field 134 present in SUBSCRIBE and NOTIFY requests. As specified in RFC 3903 135 [RFC3903], this value also appears in the Event header field present 136 in PUBLISH requests. 138 3.2. Event Package Parameters 140 RFC 3265 [RFC3265] allows event packages to define additional 141 parameters carried in the Event header field. This event package 142 does not define additional parameters. 144 3.3. SUBSCRIBE Bodies 146 RFC 3265 [RFC3265] allows a SUBSCRIBE request to contain a body. 147 This document allows the body to contain event filters, see [RFC4660] 148 and [RFC4661] with the information elements listed in the subsections 149 below. 151 3.3.1. Location Filter 153 The 2D location shapes listed in [RFC5491] (e.g., , 154 , , ) and the element, 155 defined in [RFC5139]. Repeating these elements is allowed and the 156 semantic is equivalent to a union. The element indicates 157 the area of interest; whenever an event happens in this area an alert 158 message is delivered. 160 An example can be found below: 162 163 169 170 171 172 174 42.5463 -73.2512 175 177 5000 178 179 180 181 182 183 185 Example of a SIP SUBSCRIBE Body with a Location Filter 187 3.3.2. Service Filter 189 To filter different types of alerts the element MUST 190 be included as a child element of the element and it MUST list 191 one or more Service URNs [RFC5031], which indicate the type of alerts 192 the recipient is interested in. This document registers a number of 193 alerts relevant for exigent communications, which can be found in 194 Section 6. 196 An example can be found below: 198 199 202 203 204 205 urn:service:warning.met 206 207 209 210 212 Example of a SIP SUBSCRIBE Body with a Service Filter 214 3.3.3. Rate Control 216 [I-D.ietf-sipcore-event-rate-control] extends the SIP events 217 framework by defining three "Event" header field parameters that 218 allow a subscriber to set a minimum, a maximum and an average rate of 219 event notifications generated by the notifier. This allows a 220 subscriber to have overall control over the stream of notifications, 221 for example to avoid being flooded. 223 A notifier is required to send a NOTIFY request immediately after 224 creation of a subscription. If state is not available at that time, 225 then the NOTIFY request may be sent with no content. A separate 226 NOTIFY containing an alert message may be generated some time later 227 when it becomes available. Figure 1 shows a SUBSCRIBE/NOTIFY 228 exchange. 230 Subscriber Notifier 231 |---SUBSCRIBE(1)--->| Create subscription 232 |<-------200--------| 233 |<-----NOTIFY(2)----| Return initial notify with no state 234 |--------200------->| 235 |<-----NOTIFY(3)----| Alert message comes available 236 |--------200------->| 238 Figure 1: SUBSCRIBE/NOTIFY with Rate Control 240 3.4. Subscription Duration 242 The default expiration time for subscriptions within this package is 243 3600 seconds. As per RFC 3265 [RFC3265], the subscriber MAY specify 244 an alternate expiration in the Expires header field. 246 3.5. NOTIFY Bodies 248 As described in RFC 3265 [RFC3265], the NOTIFY message will contain 249 bodies describing the state of the subscribed resource. This body is 250 in a format listed in the Accept header field of the SUBSCRIBE 251 request, or a package-specific default format if the Accept header 252 field was omitted from the SUBSCRIBE request. 254 In this event package, the body of the notification contains a Common 255 Alerting Protocol (CAP) document, i.e., an XML document. The format 256 of the XML documents used by CAP are described in [cap]. 258 For an initial notify, unlike for other event packages, there is no 259 current initial state, unless there's a pending alert. Hence, 260 returning a NOTIFY with a non-empty body only makes sense if there 261 are indeed active alerts. 263 All subscribers and notifiers of the "common-alerting-protocol" event 264 package MUST support the "application/common-alerting-protocol+xml" 265 data format. The SUBSCRIBE request MAY contain an Accept header 266 field. If no such header field is present, it has a default value of 267 "application/common-alerting-protocol+xml" (assuming that the Event 268 header field contains a value of "common-alerting-protocol"). If the 269 Accept header field is present, it MUST include "application/ 270 common-alerting-protocol+xml". 272 3.6. Notifier Processing of SUBSCRIBE Requests 274 The contents of a CAP document may contain public information, 275 depending on the alert message type and the intended recipient of the 276 alert message. It is, however, expected that in many cases providing 277 CAP documents does not require authorization by subscribers. 279 3.7. Notifier Generation of NOTIFY Requests 281 RFC 3265 [RFC3265] details the formatting and structure of NOTIFY 282 messages. However, packages are mandated to provide detailed 283 information on when to send a NOTIFY, how to compute the state of the 284 resource, how to generate neutral or fake state information, and 285 whether state information is complete or partial. This section 286 describes those details for the common-alerting-protocol event 287 package. 289 A notifier MAY send a NOTIFY at any time. Typically, it will send 290 one when an alert or early warning message is available. The NOTIFY 291 request contains a body containing one or multiple CAP document(s). 292 The times at which the NOTIFY is sent for a particular subscriber, 293 and the contents of the body within that notification, are subject to 294 any rules specified by the authorization policy that governs the 295 subscription. 297 If the subscription is rejected, a NOTIFY MAY be sent. As described 298 in RFC 3265 [RFC3265], the Subscription-State header field indicates 299 the state of the subscription. 301 The body of the NOTIFY MUST be sent using one of the types listed in 302 the Accept header field in the most recent SUBSCRIBE request, or 303 using the type "application/common-alerting-protocol+xml" if no 304 Accept header field was present. 306 Notifiers act as Event State Compositors (ESC). Thus, they learn the 307 'common-alerting-protocol' event state via PUBLISH requests sent from 308 authorized Event Publication Agents (EPAs). A Notifier may also be 309 an EPA, or might accept PUBLISH requests from authorized EPAs. 311 3.8. Subscriber Processing of NOTIFY Requests 313 RFC 3265 [RFC3265] leaves it to event packages to describe the 314 process followed by the subscriber upon receipt of a NOTIFY request, 315 including any logic required to form a coherent resource state. 317 3.9. Handling of Forked Requests 319 RFC 3265 [RFC3265] requires each package to describe handling of 320 forked SUBSCRIBE requests. 322 Given that a single SUBSCRIBE might include multiple services and 323 locations, it is reasonable and useful for a SUBSCRIBE request to 324 fork and to reach multiple UAs. This is equivalent to multiple 325 sources providing alerts for the same geographical, with a dedicated 326 relay serving an aggregation function. 328 As a result, a forked SUBSCRIBE request can install multiple 329 subscriptions. Subscribers to this package MUST be prepared to 330 install subscription state for each NOTIFY generated as a result of a 331 single SUBSCRIBE. 333 3.10. Rate of Notifications 335 RFC 3265 [RFC3265] requires each package to specify the maximum rate 336 at which notifications can be sent. 338 Notifiers SHOULD NOT generate notifications for a single user at a 339 rate of more than once every five seconds. 341 3.11. State Agents 343 RFC 3265 [RFC3265] requires each package to consider the role of 344 state agents in the package and, if they are used, to specify how 345 authentication and authorization are done. This specification allows 346 state agents to be located in the network. 348 3.12. Examples 350 An example is provided in Section 4. 352 3.13. Use of URIs to Retrieve State 354 RFC 3265 [RFC3265] allows packages to use URIs to retrieve large 355 state documents. 357 CAP documents are fairly small. This event package does not provide 358 a mechanism to use URIs to retrieve large state documents. 360 3.14. PUBLISH Bodies 362 RFC 3903 [RFC3903] requires event packages to define the content 363 types expected in PUBLISH requests. 365 In this event package, the body of a PUBLISH request may contain a 366 CAP document. A CAP document describes an emergency alert or an 367 early warning event. 369 All EPAs and ESCs MUST support the "application/ 370 common-alerting-protocol+xml" data format and MAY support other 371 formats. 373 3.15. PUBLISH Response Bodies 375 This specification assumes that the response to a PUBLISH does not 376 contain a body. 378 3.16. Multiple Sources for Event State 380 RFC 3903 [RFC3903] requires event packages to specify whether 381 multiple sources can contribute to the event state view at the ESC. 383 This event package allows different EPAs to publish CAP documents for 384 a particular user. The concept of composition is not applicable for 385 this application usage. 387 3.17. Event State Segmentation 389 RFC 3903 [RFC3903] defines segments within a state document. Each 390 segment is defined as one of potentially many identifiable sections 391 in the published event state. 393 This event package defines does not differentiate between different 394 segments. 396 3.18. Rate of Publication 398 RFC 3903 [RFC3903] allows event packages to define their own rate of 399 publication. This event package allows rate control to be utilized, 400 as described in Section 3.3.3. 402 4. Examples 404 Here is an example of a CAP document. 406 408 409 KSTO1055887203 410 KSTO@NWS.NOAA.GOV 411 2003-06-17T14:57:00-07:00 412 Actual 413 Alert 414 Public 415 416 Met 417 SEVERE THUNDERSTORM 418 Severe 419 Likely 420 NATIONAL WEATHER SERVICE SACRAMENTO 421 SEVERE THUNDERSTORM WARNING 422 AT 254 PM PDT... 423 NATIONAL WEATHER SERVICE 424 DOPPLER RADAR INDICATED A SEVERE 425 THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY... 426 OR ABOUT 18 MILES SOUTHEAST OF 427 KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL... 428 INTENSE RAIN AND STRONG DAMAGING WINDS 429 ARE LIKELY WITH THIS STORM 430 TAKE COVER IN A SUBSTANTIAL SHELTER 431 UNTIL THE STORM PASSES 432 BARUFFALDI/JUSKIE 433 434 EXTREME NORTH CENTRAL TUOLUMNE COUNTY 435 IN CALIFORNIA, EXTREME NORTHEASTERN 436 CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN 437 ALPINE COUNTY IN CALIFORNIA 438 38.47,-120.14 38.34,-119.95 38.52,-119.74 439 38.62,-119.89 38.47,-120.14 440 441 442 444 Example for a Severe Thunderstorm Warning 446 5. Security Considerations 448 This section discusses security considerations when using SIP to 449 distribute warning messages using CAP. 451 Based on the framework outlined in [I-D.ietf-atoca-requirements] the 452 following security concerns arise: 454 Amplification Attacks: An adversary could inject alerts into the 455 message handling system and therefore a single PUBLISH request 456 could potentially results in millions of NOTIFY messages delivered 457 to receivers. Injecting messages may happen at a number of ways, 458 such as by adversaries who manage to impersonate a legitimate 459 originator, a relay or gateway. Ensuring that only authorized 460 entities are permitted to inject alerts is a pre-condition. This 461 does, however, not help if the host of a trusted participant in 462 the message handling system got compromised. 464 Forgery of Alerts: Alerts may get modified or replayed. The former 465 is possible if the adversary manages to get access to a relay or 466 gateway. Two mechanisms are proposed for countering forgery: 467 using digital signatures or channel security (TLS). The first 468 provides end-to-end security; the second utilizes a hop by hop 469 security model based on a transitive chain of trust. 471 The sub-sections below discuss these threats and their 472 countermeasures in more detail. 474 5.1. Amplification 476 Threat: 478 The attacker could then conceivably attempt to impersonate an 479 originator, or a relay. A side effect of being able to inject an 480 alert for distribution is the amplification effect. 482 Countermeasures: 484 When an entity receives a CAP message it has to determine whether 485 the entity distributing the CAP messages is genuine to avoid 486 accepting messages that are injected by malicious entities. 488 When receiving a CAP document a couple of verification steps must 489 be performed. First, it needs to be ensured that the message was 490 delivered via a trusted entity and that the communication channel 491 between the User Agent and it's SIP proxy is properly secured to 492 exclude various attacks at the SIP level. Then, the message 493 contains the that may contain an entity that falls within 494 the white list of the entity receiving the message. Finally, the 495 message is protected by a digital signature and the entity signing 496 the CAP message may again be listed in a white list of the 497 receiving entity and may therefore be trusted. If none of these 498 verification checks lead to a positive indication of a known 499 sender then the CAP document should be treated as suspicious and 500 configuration at the receiving entity may dictate how to process 501 and display CAP documents in such a case. 503 5.1.1. Forgery of Alerts 505 Threat: 507 A malicious user could forge a CAP document. Alternatively, a CAP 508 document distributed earlier could be replied. 510 Countermeasures: 512 To avoid forgery, the entities must assure that proper mechanisms 513 for protecting the CAP documents are employed, for example signing 514 the CAP document itself or securing the communication between 515 participating entities using TLS. Section 3.3.2.1 of [cap] 516 specifies the signing of CAP documents. 518 Regarding replay attacks the following observations can be made. 519 A CAP document contains the mandatory , , 520 elements and an optional element. These 521 attributes make the CAP document unique for a specific originator/ 522 author and provide time restrictions. An entity that has received 523 a CAP message already within the indicated timeframe is able to 524 detect a replayed message and, if the content of that message is 525 unchanged, then no additional security vulnerability is created. 526 Recipients who enter the area of a disaster after the initial 527 distribution of warnings may not yet have seen the original CAP 528 message and, as such, would not be able to distinguish a replay 529 from the initial message being sent around. However, if the 530 threat that lead to the distribution of warning messages is still 531 imminent then there is no reason not to worry about that message. 532 The originator/author distributing the alert is, however, adviced 533 to carefully select a value for the element and it is 534 RECOMMENDED to set a value for this element. 536 6. IANA Considerations 538 6.1. Registration of the 'common-alerting-protocol' Event Package 540 This specification registers an event package, based on the 541 registration procedures defined in RFC 3265 [RFC3265]. The following 542 is the information required for such a registration: 544 Package Name: common-alerting-protocol 546 Package or Template-Package: This is a package. 548 Published Document: RFC XXX [Replace by the RFC number of this 549 specification]. 551 Person to Contact: Hannes Tschofenig, Hannes.Tschofenig@nsn.com 553 6.2. Registration of the 'application/common-alerting-protocol+xml' 554 MIME type 556 To: ietf-types@iana.org 558 Subject: Registration of MIME media type application/ common- 559 alerting-protocol+xml 561 MIME media type name: application 563 MIME subtype name: common-alerting-protocol+xml 565 Required parameters: (none) 567 Optional parameters: charset; Indicates the character encoding of 568 enclosed XML. Default is UTF-8 [RFC3629]. 570 Encoding considerations: Uses XML, which can employ 8-bit 571 characters, depending on the character encoding used. See RFC 572 3023 [RFC3023], Section 3.2. 574 Security considerations: This content type is designed to carry 575 payloads of the Common Alerting Protocol (CAP). 577 Interoperability considerations: This content type provides a way to 578 convey CAP payloads. 580 Published specification: RFC XXX [Replace by the RFC number of this 581 specification]. 583 Applications which use this media type: Applications that convey 584 alerts and early warnings according to the CAP standard. 586 Additional information: OASIS has published the Common Alerting 587 Protocol at [cap]. 589 Person & email address to contact for further information: Hannes 590 Tschofenig, Hannes.Tschofenig@nsn.com 592 Intended usage: Limited use 594 Author/Change controller: IETF SIPPING working group 596 Other information: This media type is a specialization of 597 application/xml RFC 3023 [RFC3023], and many of the considerations 598 described there also apply to application/ 599 common-alerting-protocol+xml. 601 6.3. Early Warning Service URNs 603 In according with RFC 5031 this document defines a new top-level 604 service called 'warning'. This section defines the first service 605 registration within the IANA registry using the top-level service 606 label 'warning'. 608 The 'warning' service type describes emergency services requiring an 609 immediate action or remedy by the recipient of the alert message as 610 instructed by the author of the message. Additional sub-services can 611 be added after expert review and must be of general public interest 612 and have a similar emergency nature. The expert is designated by the 613 ECRIT working group, its successor, or, in their absence, the IESG. 614 The expert review should only approve emergency services that are 615 offered widely and in different countries, with approximately the 616 same caller expectation in terms of services rendered. 618 The following list contains the initial IANA registration for the 619 'warning' service. 621 urn:service:warning.geo: Geophysical (inc. landslide) 623 urn:service:warning.met: Meteorological (inc. flood) 625 urn:service:warning.safety: General emergency and public safety 627 urn:service:warning.security: Law enforcement, military, homeland 628 and local/private security 630 urn:service:warning.rescue: Rescue and recovery 632 urn:service:warning.fire: Fire suppression and rescue 634 urn:service:warning.health: Medical and public health 636 urn:service:warning.env: Pollution and other environmental 638 urn:service:warning.transport: Public and private transportation 640 urn:service:warning.infra: Utility, telecommunication, other non- 641 transport infrastructure 643 urn:service:warning.cbrne: Chemical, Biological, Radiological, 644 Nuclear or High-Yield Explosive threat or attack 646 urn:service:warning.other: Other events 648 7. Open Issues 650 The authors would like to point to a number of issues that require 651 discussion: 653 Rate Control: The -00 version of the document introduced rate 654 control for notifications Section 3.3.3. Is this functionality is 655 needed? 657 Early Warning Service URNs: Specifying services is always difficult 658 since there is no universally agreed service semantic. This 659 document contains a proposal that re-use the classification in the 660 CAP specification [cap]. Is the proposal acceptable? 662 Event Filter: By using [RFC4660] and [RFC4661] filters in the body 663 of a SUBSCRIBE the number of notifications can be reduced to those 664 of interest to the subscriber. There is a certain overhead 665 associated with the generic usage of those event filters. Should 666 alternatives be considered? 668 Forked SUBSCRIBE Requests: This document allows forked subscribe 669 request. This is useful when a single service is offered by more 670 than one entity and therefore related to the cases discussed in 671 [I-D.forte-lost-extensions] and in 672 [I-D.forte-ecrit-service-classification]. For example, imagine a 673 warning service like 'urn:service:warning.geo' that is advertised 674 by a number of different service providers. 676 Security: The security consideration section was re-written and 677 focuses now mostly on two types of attacks, namely amplificiation 678 and forgery. Does this reflect the understanding of the group? 680 8. Acknowledgments 682 The authors would like to thank Cullen Jennings for his early support 683 and the participants of the Early Warning Adhoc meeting at IETF#69 684 for their feedback. 686 We would furthermore like to thank Martin Thomson for his detailed 687 draft review in July 2010. 689 9. References 691 9.1. Normative References 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", March 1997. 696 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 697 1.1", October 2005. 699 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 700 Event Notification", RFC 3265, June 2002. 702 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 703 for Event State Publication", RFC 3903, October 2004. 705 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 706 Types", RFC 3023, January 2001. 708 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 709 10646", STD 63, RFC 3629, November 2003. 711 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 712 Presence Information Data Format Location Object (PIDF-LO) 713 Usage Clarification, Considerations, and Recommendations", 714 RFC 5491, March 2009. 716 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 717 Format for Presence Information Data Format Location 718 Object (PIDF-LO)", RFC 5139, February 2008. 720 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 721 Emergency and Other Well-Known Services", RFC 5031, 722 January 2008. 724 [I-D.ietf-sipcore-event-rate-control] 725 Niemi, A., Kiss, K., and S. Loreto, "Session Initiation 726 Protocol (SIP) Event Notification Extension for 727 Notification Rate Control", 728 draft-ietf-sipcore-event-rate-control-04 (work in 729 progress), July 2010. 731 [RFC4660] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 732 Requena, "Functional Description of Event Notification 733 Filtering", RFC 4660, September 2006. 735 [RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa- 736 Requena, "An Extensible Markup Language (XML)-Based Format 737 for Event Notification Filtering", RFC 4661, 738 September 2006. 740 9.2. Informative References 742 [I-D.ietf-atoca-requirements] 743 Schulzrinne, H., Norreys, S., Rosen, B., and H. 744 Tschofenig, "Requirements, Terminology and Framework for 745 Exigent Communications", draft-ietf-atoca-requirements-00 746 (work in progress), September 2010. 748 [I-D.forte-lost-extensions] 749 Forte, A. and H. Schulzrinne, "Location-to-Service 750 Translation Protocol (LoST) Extensions", 751 draft-forte-lost-extensions-02 (work in progress), 752 September 2010. 754 [I-D.forte-ecrit-service-classification] 755 Forte, A. and H. Schulzrinne, "Labels for Common Location- 756 Based Services", 757 draft-forte-ecrit-service-classification-03 (work in 758 progress), January 2010. 760 Authors' Addresses 762 Brian Rosen 763 NeuStar, Inc. 764 470 Conrad Dr 765 Mars, PA 16046 766 US 768 Phone: 769 Email: br@brianrosen.net 771 Henning Schulzrinne 772 Columbia University 773 Department of Computer Science 774 450 Computer Science Building 775 New York, NY 10027 776 US 778 Phone: +1 212 939 7004 779 Email: hgs+ecrit@cs.columbia.edu 780 URI: http://www.cs.columbia.edu 782 Hannes Tschofenig 783 Nokia Siemens Networks 784 Linnoitustie 6 785 Espoo 02600 786 Finland 788 Phone: +358 (50) 4871445 789 Email: Hannes.Tschofenig@gmx.net 790 URI: http://www.tschofenig.priv.at