idnits 2.17.1 draft-barnes-atoca-meta-03.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 15, 2012) is 4296 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4648' is defined on line 631, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-barnes-atoca-escape-00 == Outdated reference: A later version (-08) exists of draft-ietf-geopriv-res-gw-lis-discovery-03 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ATOCA M. Lepinski 3 Internet-Draft BBN Technologies 4 Intended status: Informational K. Seo 5 Expires: January 16, 2013 BBN Technologes 6 R. Barnes 7 BBN Technologies 8 July 15, 2012 10 Alert Metadata Protocol (AMP) 11 draft-barnes-atoca-meta-03.txt 13 Abstract 15 This document specifies a set of mechanisms that devices on an IP 16 network can use to discover an alert metadata server able to provide 17 information about local emergency alert services. Additionally, this 18 document provides a protocol that devices on an IP network can use to 19 retrieve local information from an alert metadata server about 20 sources of emergency alerts and register contact information for 21 receipt of alerts. 23 Please send feedback to the atoca@ietf.org mailing list. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 16, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Open Questions . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Server Discovery . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Discovery using Access Network Domain Name . . . . . . . . 5 64 3.1.1. NAPTR Record Format . . . . . . . . . . . . . . . . . 6 65 3.1.2. Client Processing . . . . . . . . . . . . . . . . . . 7 66 3.2. Discovery using LoST . . . . . . . . . . . . . . . . . . . 7 67 3.2.1. LoST Server Discovery . . . . . . . . . . . . . . . . 7 68 3.2.2. Client Processing . . . . . . . . . . . . . . . . . . 7 69 4. AMP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Message Format . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1.1. Advertisement . . . . . . . . . . . . . . . . . . . . 8 72 4.1.2. Registration . . . . . . . . . . . . . . . . . . . . . 9 73 4.1.3. Refer . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1.4. Alert . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.2. AMP Sessions . . . . . . . . . . . . . . . . . . . . . . . 11 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 5.1. AMP Message Type Registry . . . . . . . . . . . . . . . . 13 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 In order for clients to securely receive alerts, both endpoints and 88 servers may need a certain amount of configuration. Clients need to 89 know the identities of trusted alerting authorities so that they can 90 reject false alerts. In some environments, servers need to gather 91 location and contact information for end clients to support alert 92 targeting and delivery, for example client location, language 93 preferences, or device capabilities. 95 In this context, alert delivery proceeds in three phases. First, a 96 client device connects to a network where alerts are provided and 97 discovers a local alert metadata server. Second, the device 98 discovers an alert metadata server, downloads information about local 99 alert servers, and (optionally) registers some information about 100 itself. Third, an alert server delivers an alert to the client. 101 These roles are illustrated in Figure 1. This document addresses the 102 first two phases (discovery and configuration), and provides one 103 possible channel for alert delivery. 104 +-------------------+ 105 | AMP Discovery | 106 +-(1) AMP Srv. URI--| (DHCP, DNS, LoST) | 107 | +-------------------+ 108 | 109 | 110 | 111 | 112 V 113 +--------+ +-------------------+ 114 | AMP |--(2) AMP Reg.-->| AMP | 115 | Client |<-(2) AMP Adv.---| Server | 116 +--------+ +-------------------+ 117 ^ 118 | 119 | 120 | 121 | 122 | +-------------------+ 123 +-(3) Alert Msg.----| Alert Server | 124 +-------------------+ 126 Figure 1: AMP alert configuration 128 This document addresses this problem in two parts. First, we 129 describe the process by which a client discovers an AMP server for a 130 local network or for a location of interest. Second, we define a 131 simple protocol that the client can use to interact with the server 132 to download metadata, register state, and receive alerts. 134 1.1. Open Questions 136 The current version of this draft specifies transport security (i.e., 137 TLS) as the only mechanism for providing security for AMP messages. 138 However, this document could also specify as an option the use the 139 mechanisms defined by of the JOSE working group to provide object 140 security for the JSON bodies on a per-message basis (independent of 141 the underlying transport). 143 The current version of this draft specifies only a WebSocket 144 transport for AMP messages. However, as an alternative this document 145 could also specify an option to use HTTP as a transport for AMP 146 messages. 148 2. Definitions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 The following entities are important in the AMP protocol: 156 Client: An end-user device interested in receiving alerts. The 157 device may be connected to a local network in the area covered by 158 alerts, or may be remote. 160 Alert Metadata Server: A server that maintains information about 161 clients and information about how alerts are delivered within some 162 scope (e.g., within a jurisdiction). 164 Alert Server: A server that delivers emergency alerts to clients. 166 Alerting Authority: An entity that is authorized to originate alerts 167 in a given context (e.g., a jurisdiction) 169 In a given deployment, the Alert Metadata Server and the Alert Server 170 may be the same server, but this is not necessarily the case. 172 3. Server Discovery 174 In this section we describe two mechanisms for clients to discover 175 alert metadata servers. The first mechanism enables a client to rely 176 upon its ISP or access network to provide a reference to an 177 appropriate alert metadata server. Many alerting scenarios are local 178 (e.g., natural disasters) and ISPs are often well-positioned to 179 gather information on their local environment. Therefore, it can be 180 useful for an ISP to provide information about local alerting 181 resources to clients. Likewise, clients should be able to discover 182 information advertised by their local networks. This first 183 mechanism, is based on the discovery procedure described in RFC 5986 184 [RFC5986]. It relies on a DHCP option specifying the Access Network 185 Domain Name, and a U-NAPTR resolution that uses the Access Network 186 Domain Name to obtain the name of the alert metadata server. 188 The second mechanism enables a client to discover an alert metadata 189 server with information about alerts relevant to a particular 190 location. This may be the client's own location, or some other 191 location of interest. This mechanism may be used either in cases 192 where the client's ISP does not provide explicit support for 193 emergency alerting, or in cases where the client is interested in 194 receiving alerts for some region that does not include the client's 195 current location. This mechanism makes use of the LoST protocol 196 [RFC5222], and its corresponding discovery mechanism [RFC5223]. 198 Client implementations SHOULD support both discovery using the Access 199 Network Domain Name (Section 3.1) and discovery based using LoST 200 (Section 3.2). Additionally, client implementations SHOULD support 201 out-of-band discovery by allowing a user to specify a static URI for 202 an appropriate alert metadata server. 204 3.1. Discovery using Access Network Domain Name 206 The mechanism presented here is based on the discovery procedure 207 described in RFC 5986 [RFC5986]. It relies on the DHCP option for 208 Access Network Domain Name, which is specified in RFC 5986 for both 209 DHCPv4 and DHCPv6. IP networks that support emergency alerting 210 SHOULD provide the Access Network Domain Name option to devices on 211 network that are configured via DHCP. This option provides to the 212 device a domain name that is suitable for service discovery within 213 the access network.. This domain is used as input to the U-NAPTR 214 resolution process for alert server discovery. 216 In addition to providing the Access Network Domain Name to devices 217 via DHCP, an IP network that supports emergency alerting SHOULD 218 provision DNS records to support a U-NAPTR lookup for AMP Server 219 discovery. U-NAPTR [RFC4848] is a Dynamic Delegation Discovery 220 Service (DDDS) profile that produces a URI (in this case, the URI for 221 the appropriate AMP alert server). Section 3.1.1 specifies the 222 format of the DNS NAPTR record used for this discovery, and Section 223 3.1,2 provides processing instructions for the client device 224 performing the discovery. 226 3.1.1. NAPTR Record Format 228 U-NAPTR resolution for an alert server takes a domain name as input 229 and produces a URI that identifies the alert server. This process 230 also requires an Application Service tag and an Application Protocol 231 tag, which differentiate NAPTR records for alert server discovery 232 from other records for that domain. Section 5.1 defines an 233 Application Service tag of "AMP", which is used to identify the AMP 234 alert server that is appropriate for use by devices in a given 235 domain. The Application Protocol tags "ws", and "wss" are used to 236 identify alert servers that support the WebSocket protocol and its 237 secure variant. The NAPTR records in the following example 238 demonstrate the use of the Application Service and Protocol tags. 239 Iterative NAPTR resolution is used to delegate responsibility for the 240 alert server from "zonea.example.net." and "zoneb.example.net." to 241 "outsource.example.com." 242 zonea.example.net. 243 ;; order pref flags 244 IN NAPTR 100 10 "" "AMP:wss" ( ; service 245 "" ; regex 246 outsource.example.com. ; replacement 247 ) 249 zoneb.example.net. 250 ;; order pref flags 251 IN NAPTR 100 10 "" "AMP:wss" ( ; service 252 "" ; regex 253 outsource.example.com. ; replacement 254 ) 256 outsource.example.com. 257 ;; order pref flags 258 IN NAPTR 100 10 "u" "AMP:wss" ( ; service 259 "!.*!wss://alerts.example.org:80/!" ; regex 260 . ; replacement 261 ) 262 Figure 1: Sample AMP NAPTR Records 264 U-NAPTR resolution might produce multiple results from each iteration 265 of the algorithm. Order and preference values in the NAPTR record 266 determine which value is chosen. A Device MAY attempt to use 267 alternative choices if the first choice is not successful. An WSS 268 URI for an alert server that is a product of U-NAPTR MUST be 269 authenticated using the domain name method described in Section 3.1 270 of RFC 6455 [RFC6455]. The domain name that is used in this 271 authentication is the one extracted from the URI, not the one that 272 was input to the U-NAPTR resolution process. 274 3.1.2. Client Processing 276 In order to discover an appropriate alert server, a client device 277 must first obtain a domain name for the local access network. The 278 client device first attempts to obtain configuration information via 279 DHCP. If the DHCP configuration contains the Access Network Domain 280 Name option, then the client uses the domain name in this option as 281 the domain name for the local access network. Once the client has 282 the domain name of the local access network, it uses this domain name 283 to make a U-NAPTR query [RFC4848] for the Application Service AMP in 284 this domain. 286 If the DHCP configuration does not contain the Access Network Domain 287 Name option, then the client MUST follow the process described in 288 [I-D.ietf-geopriv-res-gw-lis-discovery] to search the reverse DNS 289 tree for a U-NAPTR record based on the client's IP address. 291 3.2. Discovery using LoST 293 The mechanism presented here is based on the Location to Service 294 Translation protocol (LoST) [RFC5222]. This protocol enables a 295 client to query with an arbitrary location (either its own location 296 or an alternative location of interest) and obtain the URI for an 297 alert metadata server that is able to provide information for alerts 298 relevant to the given location. 300 3.2.1. LoST Server Discovery 302 In order to utilize LoST to discovery an alert metadata server, the 303 client must first obtain the address or URI of a LoST server. 304 Implementations supporting LoST-based discovery of alert metadata 305 servers MUST also support DHCP-based LoST discovery as specified in 306 RFC 5223 [RFC5223]. Implementations MAY provide an interface whereby 307 a user can directly configure a static LoST server URI or IP address, 308 but MUST prefer a discovered LoST server to a configured one. 310 3.2.2. Client Processing 312 To discover an alert metadata server for a given geography, a client 313 makes a LoST request. The client populates the 314 element of this request with the URN 315 "urn:service:alert-info", the URN specifying the alert metadata 316 service. The client populates the element of the request 317 with a location for which the client is interested in receiving 318 emergency alerts. (This may be the client's own location, or may be 319 an alternate location of interest to the client.) 321 4. AMP Protocol 323 The Alert Metadata Protocol (AMP) consists of a set of messages 324 encoded as JSON objects [RFC4627] exchanged over the WebSocket 325 protocol [[WebSocket]]. In this section we describe the format of 326 each AMP message type, and the overall flow of an AMP session. 328 4.1. Message Format 330 Each AMP message is a JSON object containing a "type" and other 331 fields that depend on the message type. An AMP object MUST contain 332 the following field: 334 "type": REQUIRED Token. The type of AMP message encoded in this 335 object. 337 This document defines four values of the "type" field, corresponding 338 to the four different alert types: 340 "advertisement": A message describing local alert servers and 341 authorities 343 "registration": A message registering client data with the server 345 "refer": A message referring the client to another AMP server 347 "alert": An emergency alert 349 Future documents may define additional message types. 350 Implementations MUST ignore any AMP message with an unknown type, or 351 any unknown field in an AMP message. 353 4.1.1. Advertisement 355 Advertisement messages are sent from servers to clients. These 356 messages allow servers to notify clients about local alert 357 authorities and local alert servers. This information enables the 358 client to determine whether future alerts are valid, regardless of 359 the protocol mechanism used to transport the alert. An advertisement 360 message can contain the following fields: 362 "token": OPTIONAL String. This field is an opaque string that the 363 server uses to identify the client on subsequent requests. 365 "contacts": REQUIRED Array of String. This field is an array of 366 strings, where each string contains a URI from which local alerts 367 may be sourced. This array MUST NOT have length zero. 369 "certs": OPTIONAL Array of String. This field is an array of 370 strings, where each string contains an X.509 certificate for a 371 local authority. Each certificate is encoded with DER and 372 base64url encoded [[BASE64]]. These certificates are used to 373 validate local alerts signed by the given alert authority. 375 "public_keys": OPTIONAL Array of String. This field is an array of 376 strings, where each string contains Subject Public Key Information 377 (SPKI) for a local authority, encoded in DER and base64url 378 encoded. These are the public keys used to validate alerts signed 379 by the given alert authority. 381 "hash_values": OPTIONAL Array of String. This field is an array of 382 hash values that are used in ESCAPE verification, base64url 383 encoded. 385 "ttl": REQUIRED Number. This field is a positive integer that 386 indicates the length of time (in seconds) for which this 387 advertisement is valid. If the client does not receive a new 388 advertisement message from the server before the ttl indicates 389 that the advertisement is stale, then the client should attempt to 390 obtain a new advertisement message by sending a registration 391 message to the server. 393 An advertisement message MUST contain either a "certs" field or a 394 "public_keys" field. 396 The "token" field MUST be present except when the server does not 397 maintain state for clients. If the server sets the "token" field, 398 then the values it uses MUST be chosen to minimize the possibility 399 that one client will be able to guess another's token, since that 400 would allow one client to change or delete another client's 401 registered state. One algorithm for generating these tokens would be 402 to compute the HMAC of another client identifier (e.g., an IP address 403 and timestamp) using a secret key known only to the AMP server. 405 4.1.2. Registration 407 Registration messages are sent from clients to servers. They are 408 used by the clients to register with a server in order to receive 409 future alerts of the proper type and format (e.g., language). The 410 same message is also used to update existing registration information 411 or to request deletion of existing registration information. Note 412 that for location information, the Registration makes use of the 413 PIDF-LO format, which is defined in [RFC4119]. Registration messages 414 contain the following fields: 416 "token": REQUIRED String. An opaque a string that identifies the 417 client. Once a client has received an advertisement message from 418 a server, it SHOULD copy the token from that message into all 419 future registration messages to that server, so that the server 420 can distinguish between new registrations and updates to existing 421 registrations. 423 "contacts": OPTIONAL Array of String. This field is an array of 424 strings, where each string contains a URI that can be used contact 425 the client. If this field is included, but the array is empty, 426 then the the server MUST delete any existing registration 427 information for this client. 429 "location": OPTIONAL String. This field is a string containing a 430 "geopriv" element from a PIDF-LO, base64url encoded. 432 "language": OPTIONAL String. This field is a string containing the 433 language in which the client wishes to receive alerts, in the 434 format defined by RFC 5646 [RFC5646]. 436 If a server receives a new registration message from a previously 437 registered client (i.e., a registration message containing a token 438 that the server has previously sent in an advertisement message), 439 then the server should replace the existing registration information 440 for that client with the information contained in the new 441 registration message. If the server receives a registration message 442 containing only the token field, then the server should delete any 443 existing registration information associated with this client. 445 4.1.3. Refer 447 Refer messages are sent from servers to clients. These messages 448 allow servers to notify clients of a different AMP server that the 449 client should contact. For example, if an AMP server receives a 450 registration message indicating a location outside its jurisdiction, 451 it might send a refer message that refers the client to an 452 appropriate server for the client's current location. A refer 453 message must contain the following fields: 455 "to": REQUIRED String. The URI of the AMP server to which the 456 client is being referred. 458 Upon receiving a Refer message, a client SHOULD send establish a new 459 AMP session with the AMP server indicated in the "to" field of the 460 refer message. 462 4.1.4. Alert 464 Alert messages are sent from servers to client. These messages are 465 one mechanism for distributing local alerts. (Other mechanisms for 466 transporting local alerts include LEAP [I-D.barnes-atoca-delivery].) 467 Alerts sent using an AMP alert message are encoded using ESCAPE 468 [I-D.barnes-atoca-escape], then base64url encoded. An Alert message 469 contains the following fields: 471 "alert_data": REQUIRED String. An ESCAPE-encoded, base64url-encoded 472 alert message. 474 The procedure for validating ESCAPE-encoded alert messages can be 475 found in [I-D.barnes-atoca-escape] 477 4.2. AMP Sessions 479 An AMP session is a WebSocket connection over which AMP messages are 480 conveyed. The first goal of an AMP session is to inform a client 481 about local alerting resources (alerting configuration information), 482 but the client may maintain a long-lived AMP session in order to 483 provide updated status (e.g., location or contact changes) as well as 484 to get updated configuration information over time. 486 The client initiates an AMP session by establishing a WebSocket 487 connection to the AMP server. The client sends the first message, 488 providing a Registration message with relevant information. 490 The AMP Server MUST respond with an Advertisement message containing 491 local alert information immediately upon the establishment of a 492 session. If the initial Registration contained a "token" value, then 493 the "token" field in the Advertisement MUST be either empty or equal 494 to the registered token value. 496 Once the initial handshake is complete, either side may send a 497 message at any time. When a message is received, the action taken 498 depends on the type of message: 500 o Client receives Refer: The client SHOULD close the current AMP 501 session and initiate a new AMP session with the server indicated 502 in the "to" field of the message. If the client received a token 503 in the first session, then it SHOULD include that token in the 504 initial Registration for the new session. 506 o Client receives Advertisement: The client MUST replace its local 507 alert configuration information with the contents of the 508 Advertisement. If the "token" field is present, then the client 509 MUST update its token. 511 o Client receives Alert: The client MUST decode the encoded 512 "alert_data" element and process the resulting ESCAPE message 513 according to the ESCAPE validation rules. If the alert is valid, 514 the client renders it to the user. 516 o Server receives Registration: The server MUST replace its current 517 state for the client with the state in the message. 519 * If the "token" field is present, the server MUST verify that it 520 matches a token that it has assigned in an Advertisement 521 message in this session; if not, then this message MUST be 522 ignored. 524 * If the Registration message contains only the "type" field, 525 then the server MUST delete any state associated with this 526 session. 528 * If the location of the client has moved out of the server's 529 coverage area, then the server MUST close the connection. If 530 the responsible AMP server for the client's new location is 531 known, then the server SHOULD send a Refer message before 532 closing the connection. 534 If either side receives a message sent in the incorrect direction, it 535 MUST ignore it. For the server, this includes Advertisement, Refer, 536 and Alert messages. For the client, Registration messages. 538 Servers SHOULD maintain information about AMP servers covering 539 neighboring jurisdictions and their respective coverage areas. That 540 way, the server can issue a Refer message to the client as soon as 541 the client reports that it has left the coverage area. This will 542 help ensure that the client always has up-to-date alerting 543 configuration information, without the client having to repeatedly 544 perform AMP discovery. 546 5. IANA Considerations 548 This document requires several registrations by IANA into existing 549 registries, and creates a new registry of AMP message codes. 551 [[ TODO: Register the URN: "urn:service:alert-info" ]] 553 [[ TODO: Register NAPTR service tag "AMP" and application protocols 554 "http", "https" ]] 556 [[ TODO: Register media type application/amp+json ]] 558 5.1. AMP Message Type Registry 560 IANA is requested to create a new registry of AMP Message Types. 561 This registry contains two fields, the name of the name of the 562 registered message type, and a specification pointer containing a 563 reference to the document that defines the registered message type. 565 IANA is requested to populate this new registry with the following 566 four entries: 568 Message Type Name Specification Pointer 569 +--------------------------------+--------------------------------+ 570 | Registration | draft-barnes-atoca-meta | 571 | Advertisement | draft-barnes-atoca-meta | 572 | Refer | draft-barnes-atoca-meta | 573 | Alert | draft-barnes-atoca-meta | 574 +--------------------------------+--------------------------------+ 576 6. Security Considerations 578 [Author's Note: The Security Considerations will be fleshed out in 579 more detail in the next version of this document.] 581 The AMP protocol contains contact and location information for a 582 device which for many devices will consist of private information 583 regarding the user of the device. Therefore, confidentiality 584 protection should be used when the registration request contains 585 private information. 587 The modification of AMP messages can cause client devices to accept 588 false alerts (in the case where the advertisement is modified) or to 589 receive alerts for the improper location (if the registration is 590 modified). Therefore, integrity protection should be applied to AMP 591 messages. 593 The AMP protocol runs over HTTP. Therefore, the use of HTTP over TLS 594 can provide confidentiality and integrity protection for AMP 595 messages. 597 Alert server discovery makes use of NAPTR. Standard security 598 considerations involving the use of NAPTR apply. DNSSEC SHOULD be 599 used to protect the DNS responses provided during the discovery 600 procedure. 602 7. Acknowledgements 604 The authors would like to thank Derrick Kong for help in creating the 605 JSON schema for the AMP protocol. 607 8. References 609 8.1. Normative References 611 [I-D.barnes-atoca-escape] 612 Barnes, R., "Encoding of Secure Common Alert Protocol 613 Entities (ESCAPE)", draft-barnes-atoca-escape-00 (work in 614 progress), October 2011. 616 [I-D.ietf-geopriv-res-gw-lis-discovery] 617 Thomson, M. and R. Bellis, "Location Information Server 618 (LIS) Discovery using IP address and Reverse DNS", 619 draft-ietf-geopriv-res-gw-lis-discovery-03 (work in 620 progress), March 2012. 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997. 625 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 626 Format", RFC 4119, December 2005. 628 [RFC4627] Crockford, D., "The application/json Media Type for 629 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 631 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 632 Encodings", RFC 4648, October 2006. 634 [RFC4848] Daigle, L., "Domain-Based Application Service Location 635 Using URIs and the Dynamic Delegation Discovery Service 636 (DDDS)", RFC 4848, April 2007. 638 [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. 639 Tschofenig, "LoST: A Location-to-Service Translation 640 Protocol", RFC 5222, August 2008. 642 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 643 Languages", BCP 47, RFC 5646, September 2009. 645 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 646 Location Information Server (LIS)", RFC 5986, 647 September 2010. 649 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 650 RFC 6455, December 2011. 652 8.2. Informative References 654 [I-D.barnes-atoca-delivery] 655 Barnes, R., "Lightweight Emergency Alerting Protocol 656 (LEAP)", draft-barnes-atoca-delivery-01 (work in 657 progress), October 2011. 659 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 660 Location-to-Service Translation (LoST) Servers Using the 661 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 662 August 2008. 664 Authors' Addresses 666 Matt Lepinski 667 BBN Technologies 668 10 Moulton St 669 Cambridge, MA 02138 670 US 672 Phone: +1 617 873 5939 673 Email: mlepinski@bbn.com 675 Karen Seo 676 BBN Technologes 677 10 Moulton St 678 Cambridge, MA 02138 679 US 681 Phone: +1 617 873 3152 682 Email: kseo@bbn.com 684 Richard Barnes 685 BBN Technologies 686 9861 Broken Land Parkway 687 Columbia, MD 21046 688 US 690 Phone: +1 410 290 6169 691 Email: rbarnes@bbn.com