idnits 2.17.00 (12 Aug 2021) /tmp/idnits24026/draft-rosen-ecrit-lost-early-warning-01.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: ---------------------------------------------------------------------------- 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 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 4688 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) == Outdated reference: A later version (-04) exists of draft-rosen-sipping-cap-03 == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft NeuStar, Inc. 4 Intended status: Standards Track H. Schulzrinne 5 Expires: January 14, 2010 Columbia U. 6 H. Tschofenig 7 Nokia Siemens Networks 8 July 13, 2009 10 A Uniform Resource Name (URN) for Early Warning Emergency Services and 11 Location-to-Service Translation (LoST) Protocol Usage 12 draft-rosen-ecrit-lost-early-warning-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 14, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 The Common Alerting Protocol (CAP) is an XML document format for 51 exchanging emergency alerts and public warnings. Different 52 organizations issue alerts for specific geographic regions. The 53 Location-to-Service Translation (LoST) protocol provides a way to 54 discover servers that distribute these alerts for a geographical 55 region. This document defines the Service Uniform Resource Names 56 (URN)s for warnings in the same way as they have been defined with 57 RFC 5031 for citizen-to-authority emergency services. Additionally, 58 this document suggests to use LoST for the discovery of servers 59 distributing alerts. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Protocol Semantics . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. Sub-Services for the 'warning' Service . . . . . . . . . . 7 70 6.2. Initial IANA Registration . . . . . . . . . . . . . . . . . 8 71 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 The Common Alerting Protocol (CAP) is an XML document format for 80 exchanging emergency alerts and public warnings. Different 81 organizations issue alerts for specific geographical regions. The 82 Location-to-Service Translation (LoST) protocol provides a way to 83 discover servers that distribute these alerts for a geographical 84 region. This document defines the Service Uniform Resource Names 85 (URN)s for warnings in the same way as they have been defined with 86 RFC 5031 for citizen-to-authority emergency services. Additionally, 87 this document suggests to use LoST for the discovery of servers 88 distributing alerts. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 3. Protocol Semantics 98 This document makes use of LoST, RFC 5222 [RFC5222]. However, 99 instead of performing a translation from location information and a 100 Service URN to a PSAP URI (plus supplementary information), as used 101 with [I-D.ietf-ecrit-phonebcp] for the citizen-to-authority emergency 102 services use case, the LoST client asks the LoST server for a URI to 103 receive further information on how to obtain warning alerts. In a 104 response the URIs in the element MUST be from the following 105 format: sip, xmpp or http. The SIP URI MUST subsequently be used 106 with [I-D.rosen-sipping-cap]. An XMPP URI MUST be used as described 107 in [XEP-0127]. An HTTP URI MUST be used with GeoRSS ([Reference to 108 be added.]). 110 In a LoST response the optional element is not used 111 by this specification. In mapping citizen-to-authority services, 112 receiving multiple mappings is an exception. However, since many 113 organizations may provide warnings for the same area, this is likely 114 to be more common for alerts. As such, the extensions defined in 115 [I-D.forte-ecrit-lost-extensions] (e.g., the ability to limit the 116 number of returned mappings) are useful in this context. 118 4. Examples 120 Figure 1 shows a regular LoST query including geodetic location 121 information with the Service URN pointing to 'urn:service:warning'. 123 The semantic of the query is: "I am at location (point,"37.775 124 -122.422"). Please give me a URI where I can obtain information for 125 warnings under the category 'urn:service:warning'. 127 128 134 135 136 37.775 -122.422 137 138 139 urn:service:warning 141 143 Figure 1: A geodetic query 145 In response to the query in Figure 1 the LoST server returns a 146 regular LoST response, as shown in Figure 2. The returned mapping 147 information indicates that the URIs (sip:alerts@example.com and 148 xmpp:alerts@example.com) can be contacted to subscribe to warning 149 events. The service boundary indicates that subsequent requests to 150 the same service will lead to the same response for the geodetic 151 region indicated by the polygon in the element. 153 154 156 161 162 Austrian Early Warning Center 163 164 urn:service:warning 165 166 167 168 169 37.775 -122.4194 170 37.555 -122.4194 171 37.555 -122.4264 172 37.775 -122.4264 173 37.775 -122.4194 174 175 176 177 178 sip:alerts@example.com 179 xmpp:alerts@example.com 180 181 182 183 184 185 186 188 Figure 2: A geodetic answer 190 Figure 3 shows a query asking for the 191 services that are available at a given location; in this example at a 192 point (-34.407 150.883). 194 195 199 200 201 -34.407 150.883 202 203 204 urn:service:warning 205 207 Figure 3: Example of query 209 Figure 4 lists a possible response to the 210 query with 6 subservices being offered for the indicated geographical 211 region. 213 214 216 217 urn:service:warning.geo 218 urn:service:warning.met 219 urn:service:warning.safety 220 urn:service:warning.security 221 urn:service:warning.rescue 222 urn:service:warning.fire 223 224 225 226 227 228 229 231 Figure 4: Example of 233 5. Security Considerations 235 The security considerations of RFC 5031 [RFC5031], RFC 5222 [RFC5222] 236 and [I-D.rosen-sipping-cap] are relevant to this document. This 237 document does not introduce new security vulnerabilities. 239 6. IANA Considerations 241 6.1. Sub-Services for the 'warning' Service 243 This section defines the service registration within the IANA 244 registry defined in Section 4.1 of [RFC5031], using the top-level 245 service label 'warning'. 247 The 'warning' service type describes services providing public safety 248 alerts, i.e., alerts that can warn members of the public about 249 dangers to life, health and property. Additional sub-services can be 250 added after expert review and must be of general public interest and 251 have a similar emergency nature. The expert is designated by the 252 ECRIT working group, its successor, or, in their absence, the IESG. 253 The expert review should only approve early warning based emergency 254 services that are offered widely and in different countries, with 255 approximately the same caller expectation in terms of services 256 rendered. The 'warning' service is not meant to be used by non- 257 emergency services related information. 259 The warning classification (including description) in the list below 260 is taken from the CAP specification [cap]: 262 'urn:service:warning': The generic 'warning' service denotes a 263 generic early warning message of any type encompassing all of the 264 services listed below. 266 'urn:service:warning:geo': Geophysical (inc. landslide) 268 'urn:service:warning:met': Meteorological (inc. flood) 270 'urn:service:warning:safety': General emergency and public safety 272 'urn:service:warning:security': Law enforcement, military, homeland 273 and local/private security 275 'urn:service:warning:rescue': Rescue and recovery 277 'urn:service:warning:fire': Fire suppression and rescue 279 'urn:service:warning:health': Medical and public health 281 'urn:service:warning:env': Pollution and other environmental 282 'urn:service:warning:transport': Public and private transportation 284 'urn:service:warning:infra': Utility, telecommunication, other non- 285 transport infrastructure 287 'urn:service:warning:cbrne': Chemical, Biological, Radiological, 288 Nuclear or High-Yield Explosive threat or attack 290 6.2. Initial IANA Registration 292 The following table contains the initial IANA registration for early 293 warning services. 295 Service Reference Description 296 ------------------------------------------------------------------------ 297 warning RFC TBD Early Warning Services 298 warning.geo RFC TBD Geophysical (inc. landslide) 299 warning.met RFC TBD Meteorological (inc. flood) 300 warning.safety RFC TBD General emergency and public safety 301 warning.security RFC TBD Law enforcement, military, 302 homeland and local/private security 303 warning.rescue RFC TBD Rescue and recovery 304 warning.fire RFC TBD Fire suppression and rescue 305 warning.health RFC TBD Medical and public health 306 warning.env RFC TBD Pollution and other environmental 307 warning.transport RFC TBD Public and private transportation 308 warning.infra RFC TBD Utility, telecommunication, other 309 non-transport infrastructure 310 warning.cbrne RFC TBD Chemical, Biological, 311 Radiological, Nuclear or High-Yield 312 Explosive threat or attack 314 7. Acknowledgments 316 We would also like to thank the participants of the Early Warning 317 Adhoc meeting at IETF#69. 319 8. References 321 8.1. Normative References 323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 324 Requirement Levels", March 1997. 326 [cap] Jones, E. and A. Botterell, "Common Alerting Protocol v. 327 1.1", October 2005. 329 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 330 Tschofenig, "LoST: A Location-to-Service Translation 331 Protocol", RFC 5222, August 2008. 333 [I-D.rosen-sipping-cap] 334 Rosen, B., Schulzrinne, H., and H. Tschofenig, "Session 335 Initiation Protocol (SIP) Event Package for the Common 336 Alerting Protocol (CAP)", draft-rosen-sipping-cap-03 337 (work in progress), March 2009. 339 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 340 Emergency and Other Well-Known Services", RFC 5031, 341 January 2008. 343 8.2. Informative References 345 [XEP-0127] 346 Saint-Andre, P. and B. Fletcher, "Common Alerting Protocol 347 (CAP) Over XMPP", XSF XEP 0127, December 2004. 349 [I-D.forte-ecrit-lost-extensions] 350 Forte, A. and H. Schulzrinne, "Location-to-Service 351 Translation Protocol (LoST) Extensions", 352 draft-forte-ecrit-lost-extensions-02 (work in progress), 353 March 2009. 355 [I-D.ietf-ecrit-phonebcp] 356 Rosen, B. and J. Polk, "Best Current Practice for 357 Communications Services in support of Emergency Calling", 358 draft-ietf-ecrit-phonebcp-12 (work in progress), 359 July 2009. 361 Authors' Addresses 363 Brian Rosen 364 NeuStar, Inc. 365 470 Conrad Dr 366 Mars, PA 16046 367 US 369 Phone: 370 Email: br@brianrosen.net 371 Henning Schulzrinne 372 Columbia University 373 Department of Computer Science 374 450 Computer Science Building 375 New York, NY 10027 376 US 378 Phone: +1 212 939 7004 379 Email: hgs+ecrit@cs.columbia.edu 380 URI: http://www.cs.columbia.edu 382 Hannes Tschofenig 383 Nokia Siemens Networks 384 Linnoitustie 6 385 Espoo 02600 386 Finland 388 Phone: +358 (50) 4871445 389 Email: Hannes.Tschofenig@gmx.net 390 URI: http://www.tschofenig.priv.at