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