Internet DRAFT - draft-barnes-atoca-meta

draft-barnes-atoca-meta






ATOCA                                                        M. Lepinski
Internet-Draft                                          BBN Technologies
Intended status: Informational                                    K. Seo
Expires: January 16, 2013                                BBN Technologes
                                                               R. Barnes
                                                        BBN Technologies
                                                           July 15, 2012


                     Alert Metadata Protocol (AMP)
                     draft-barnes-atoca-meta-03.txt

Abstract

   This document specifies a set of mechanisms that devices on an IP
   network can use to discover an alert metadata server able to provide
   information about local emergency alert services.  Additionally, this
   document provides a protocol that devices on an IP network can use to
   retrieve local information from an alert metadata server about
   sources of emergency alerts and register contact information for
   receipt of alerts.

   Please send feedback to the atoca@ietf.org mailing list.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 16, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Lepinski, et al.        Expires January 16, 2013                [Page 1]

Internet-Draft                     AMP                         July 2012


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Open Questions . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Server Discovery . . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Discovery using Access Network Domain Name . . . . . . . .  5
       3.1.1.  NAPTR Record Format  . . . . . . . . . . . . . . . . .  6
       3.1.2.  Client Processing  . . . . . . . . . . . . . . . . . .  7
     3.2.  Discovery using LoST . . . . . . . . . . . . . . . . . . .  7
       3.2.1.  LoST Server Discovery  . . . . . . . . . . . . . . . .  7
       3.2.2.  Client Processing  . . . . . . . . . . . . . . . . . .  7
   4.  AMP Protocol . . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Message Format . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  Advertisement  . . . . . . . . . . . . . . . . . . . .  8
       4.1.2.  Registration . . . . . . . . . . . . . . . . . . . . .  9
       4.1.3.  Refer  . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.1.4.  Alert  . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  AMP Sessions . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  AMP Message Type Registry  . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15















Lepinski, et al.        Expires January 16, 2013                [Page 2]

Internet-Draft                     AMP                         July 2012


1.  Introduction

   In order for clients to securely receive alerts, both endpoints and
   servers may need a certain amount of configuration.  Clients need to
   know the identities of trusted alerting authorities so that they can
   reject false alerts.  In some environments, servers need to gather
   location and contact information for end clients to support alert
   targeting and delivery, for example client location, language
   preferences, or device capabilities.

   In this context, alert delivery proceeds in three phases.  First, a
   client device connects to a network where alerts are provided and
   discovers a local alert metadata server.  Second, the device
   discovers an alert metadata server, downloads information about local
   alert servers, and (optionally) registers some information about
   itself.  Third, an alert server delivers an alert to the client.
   These roles are illustrated in Figure 1.  This document addresses the
   first two phases (discovery and configuration), and provides one
   possible channel for alert delivery.
                              +-------------------+
                              |   AMP Discovery   |
          +-(1) AMP Srv. URI--| (DHCP, DNS, LoST) |
          |                   +-------------------+
          |
          |
          |
          |
          V
   +--------+                 +-------------------+
   |  AMP   |--(2) AMP Reg.-->|        AMP        |
   | Client |<-(2) AMP Adv.---|       Server      |
   +--------+                 +-------------------+
          ^
          |
          |
          |
          |
          |                   +-------------------+
          +-(3) Alert Msg.----|   Alert Server    |
                              +-------------------+

                     Figure 1: AMP alert configuration

   This document addresses this problem in two parts.  First, we
   describe the process by which a client discovers an AMP server for a
   local network or for a location of interest.  Second, we define a
   simple protocol that the client can use to interact with the server
   to download metadata, register state, and receive alerts.



Lepinski, et al.        Expires January 16, 2013                [Page 3]

Internet-Draft                     AMP                         July 2012


1.1.  Open Questions

   The current version of this draft specifies transport security (i.e.,
   TLS) as the only mechanism for providing security for AMP messages.
   However, this document could also specify as an option the use the
   mechanisms defined by of the JOSE working group to provide object
   security for the JSON bodies on a per-message basis (independent of
   the underlying transport).

   The current version of this draft specifies only a WebSocket
   transport for AMP messages.  However, as an alternative this document
   could also specify an option to use HTTP as a transport for AMP
   messages.


2.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The following entities are important in the AMP protocol:

   Client:  An end-user device interested in receiving alerts.  The
      device may be connected to a local network in the area covered by
      alerts, or may be remote.

   Alert Metadata Server:  A server that maintains information about
      clients and information about how alerts are delivered within some
      scope (e.g., within a jurisdiction).

   Alert Server:  A server that delivers emergency alerts to clients.

   Alerting Authority:  An entity that is authorized to originate alerts
      in a given context (e.g., a jurisdiction)

   In a given deployment, the Alert Metadata Server and the Alert Server
   may be the same server, but this is not necessarily the case.


3.  Server Discovery

   In this section we describe two mechanisms for clients to discover
   alert metadata servers.  The first mechanism enables a client to rely
   upon its ISP or access network to provide a reference to an
   appropriate alert metadata server.  Many alerting scenarios are local
   (e.g., natural disasters) and ISPs are often well-positioned to
   gather information on their local environment.  Therefore, it can be



Lepinski, et al.        Expires January 16, 2013                [Page 4]

Internet-Draft                     AMP                         July 2012


   useful for an ISP to provide information about local alerting
   resources to clients.  Likewise, clients should be able to discover
   information advertised by their local networks.  This first
   mechanism, is based on the discovery procedure described in RFC 5986
   [RFC5986].  It relies on a DHCP option specifying the Access Network
   Domain Name, and a U-NAPTR resolution that uses the Access Network
   Domain Name to obtain the name of the alert metadata server.

   The second mechanism enables a client to discover an alert metadata
   server with information about alerts relevant to a particular
   location.  This may be the client's own location, or some other
   location of interest.  This mechanism may be used either in cases
   where the client's ISP does not provide explicit support for
   emergency alerting, or in cases where the client is interested in
   receiving alerts for some region that does not include the client's
   current location.  This mechanism makes use of the LoST protocol
   [RFC5222], and its corresponding discovery mechanism [RFC5223].

   Client implementations SHOULD support both discovery using the Access
   Network Domain Name (Section 3.1) and discovery based using LoST
   (Section 3.2).  Additionally, client implementations SHOULD support
   out-of-band discovery by allowing a user to specify a static URI for
   an appropriate alert metadata server.

3.1.  Discovery using Access Network Domain Name

   The mechanism presented here is based on the discovery procedure
   described in RFC 5986 [RFC5986].  It relies on the DHCP option for
   Access Network Domain Name, which is specified in RFC 5986 for both
   DHCPv4 and DHCPv6.  IP networks that support emergency alerting
   SHOULD provide the Access Network Domain Name option to devices on
   network that are configured via DHCP.  This option provides to the
   device a domain name that is suitable for service discovery within
   the access network..  This domain is used as input to the U-NAPTR
   resolution process for alert server discovery.

   In addition to providing the Access Network Domain Name to devices
   via DHCP, an IP network that supports emergency alerting SHOULD
   provision DNS records to support a U-NAPTR lookup for AMP Server
   discovery.  U-NAPTR [RFC4848] is a Dynamic Delegation Discovery
   Service (DDDS) profile that produces a URI (in this case, the URI for
   the appropriate AMP alert server).  Section 3.1.1 specifies the
   format of the DNS NAPTR record used for this discovery, and Section
   3.1,2 provides processing instructions for the client device
   performing the discovery.






Lepinski, et al.        Expires January 16, 2013                [Page 5]

Internet-Draft                     AMP                         July 2012


3.1.1.  NAPTR Record Format

   U-NAPTR resolution for an alert server takes a domain name as input
   and produces a URI that identifies the alert server.  This process
   also requires an Application Service tag and an Application Protocol
   tag, which differentiate NAPTR records for alert server discovery
   from other records for that domain.  Section 5.1 defines an
   Application Service tag of "AMP", which is used to identify the AMP
   alert server that is appropriate for use by devices in a given
   domain.  The Application Protocol tags "ws", and "wss" are used to
   identify alert servers that support the WebSocket protocol and its
   secure variant.  The NAPTR records in the following example
   demonstrate the use of the Application Service and Protocol tags.
   Iterative NAPTR resolution is used to delegate responsibility for the
   alert server from "zonea.example.net." and "zoneb.example.net." to
   "outsource.example.com."
   zonea.example.net.
   ;;       order pref flags
   IN NAPTR 100   10   ""  "AMP:wss" (            ; service
       ""                                          ; regex
       outsource.example.com.                      ; replacement
       )

   zoneb.example.net.
   ;;       order pref flags
   IN NAPTR 100   10   ""  "AMP:wss" (            ; service
       ""                                          ; regex
       outsource.example.com.                      ; replacement
       )

   outsource.example.com.
   ;;       order pref flags
   IN NAPTR 100   10   "u"  "AMP:wss" (            ; service
       "!.*!wss://alerts.example.org:80/!"          ; regex
       .                                            ; replacement
       )
   Figure 1: Sample AMP NAPTR Records

   U-NAPTR resolution might produce multiple results from each iteration
   of the algorithm.  Order and preference values in the NAPTR record
   determine which value is chosen.  A Device MAY attempt to use
   alternative choices if the first choice is not successful.  An WSS
   URI for an alert server that is a product of U-NAPTR MUST be
   authenticated using the domain name method described in Section 3.1
   of RFC 6455 [RFC6455].  The domain name that is used in this
   authentication is the one extracted from the URI, not the one that
   was input to the U-NAPTR resolution process.




Lepinski, et al.        Expires January 16, 2013                [Page 6]

Internet-Draft                     AMP                         July 2012


3.1.2.  Client Processing

   In order to discover an appropriate alert server, a client device
   must first obtain a domain name for the local access network.  The
   client device first attempts to obtain configuration information via
   DHCP.  If the DHCP configuration contains the Access Network Domain
   Name option, then the client uses the domain name in this option as
   the domain name for the local access network.  Once the client has
   the domain name of the local access network, it uses this domain name
   to make a U-NAPTR query [RFC4848] for the Application Service AMP in
   this domain.

   If the DHCP configuration does not contain the Access Network Domain
   Name option, then the client MUST follow the process described in
   [I-D.ietf-geopriv-res-gw-lis-discovery] to search the reverse DNS
   tree for a U-NAPTR record based on the client's IP address.

3.2.  Discovery using LoST

   The mechanism presented here is based on the Location to Service
   Translation protocol (LoST) [RFC5222].  This protocol enables a
   client to query with an arbitrary location (either its own location
   or an alternative location of interest) and obtain the URI for an
   alert metadata server that is able to provide information for alerts
   relevant to the given location.

3.2.1.  LoST Server Discovery

   In order to utilize LoST to discovery an alert metadata server, the
   client must first obtain the address or URI of a LoST server.
   Implementations supporting LoST-based discovery of alert metadata
   servers MUST also support DHCP-based LoST discovery as specified in
   RFC 5223 [RFC5223].  Implementations MAY provide an interface whereby
   a user can directly configure a static LoST server URI or IP address,
   but MUST prefer a discovered LoST server to a configured one.

3.2.2.  Client Processing

   To discover an alert metadata server for a given geography, a client
   makes a LoST <findservice> request.  The client populates the
   <service> element of this request with the URN
   "urn:service:alert-info", the URN specifying the alert metadata
   service.  The client populates the <location> element of the request
   with a location for which the client is interested in receiving
   emergency alerts.  (This may be the client's own location, or may be
   an alternate location of interest to the client.)





Lepinski, et al.        Expires January 16, 2013                [Page 7]

Internet-Draft                     AMP                         July 2012


4.  AMP Protocol

   The Alert Metadata Protocol (AMP) consists of a set of messages
   encoded as JSON objects [RFC4627] exchanged over the WebSocket
   protocol [[WebSocket]].  In this section we describe the format of
   each AMP message type, and the overall flow of an AMP session.

4.1.  Message Format

   Each AMP message is a JSON object containing a "type" and other
   fields that depend on the message type.  An AMP object MUST contain
   the following field:

   "type":  REQUIRED Token.  The type of AMP message encoded in this
      object.

   This document defines four values of the "type" field, corresponding
   to the four different alert types:

   "advertisement":  A message describing local alert servers and
      authorities

   "registration":  A message registering client data with the server

   "refer":  A message referring the client to another AMP server

   "alert":  An emergency alert

   Future documents may define additional message types.
   Implementations MUST ignore any AMP message with an unknown type, or
   any unknown field in an AMP message.

4.1.1.  Advertisement

   Advertisement messages are sent from servers to clients.  These
   messages allow servers to notify clients about local alert
   authorities and local alert servers.  This information enables the
   client to determine whether future alerts are valid, regardless of
   the protocol mechanism used to transport the alert.  An advertisement
   message can contain the following fields:

   "token":  OPTIONAL String.  This field is an opaque string that the
      server uses to identify the client on subsequent requests.

   "contacts":  REQUIRED Array of String.  This field is an array of
      strings, where each string contains a URI from which local alerts
      may be sourced.  This array MUST NOT have length zero.




Lepinski, et al.        Expires January 16, 2013                [Page 8]

Internet-Draft                     AMP                         July 2012


   "certs":  OPTIONAL Array of String.  This field is an array of
      strings, where each string contains an X.509 certificate for a
      local authority.  Each certificate is encoded with DER and
      base64url encoded [[BASE64]].  These certificates are used to
      validate local alerts signed by the given alert authority.

   "public_keys":  OPTIONAL Array of String.  This field is an array of
      strings, where each string contains Subject Public Key Information
      (SPKI) for a local authority, encoded in DER and base64url
      encoded.  These are the public keys used to validate alerts signed
      by the given alert authority.

   "hash_values":  OPTIONAL Array of String.  This field is an array of
      hash values that are used in ESCAPE verification, base64url
      encoded.

   "ttl":  REQUIRED Number.  This field is a positive integer that
      indicates the length of time (in seconds) for which this
      advertisement is valid.  If the client does not receive a new
      advertisement message from the server before the ttl indicates
      that the advertisement is stale, then the client should attempt to
      obtain a new advertisement message by sending a registration
      message to the server.

   An advertisement message MUST contain either a "certs" field or a
   "public_keys" field.

   The "token" field MUST be present except when the server does not
   maintain state for clients.  If the server sets the "token" field,
   then the values it uses MUST be chosen to minimize the possibility
   that one client will be able to guess another's token, since that
   would allow one client to change or delete another client's
   registered state.  One algorithm for generating these tokens would be
   to compute the HMAC of another client identifier (e.g., an IP address
   and timestamp) using a secret key known only to the AMP server.

4.1.2.  Registration

   Registration messages are sent from clients to servers.  They are
   used by the clients to register with a server in order to receive
   future alerts of the proper type and format (e.g., language).  The
   same message is also used to update existing registration information
   or to request deletion of existing registration information.  Note
   that for location information, the Registration makes use of the
   PIDF-LO format, which is defined in [RFC4119].  Registration messages
   contain the following fields:





Lepinski, et al.        Expires January 16, 2013                [Page 9]

Internet-Draft                     AMP                         July 2012


   "token":  REQUIRED String.  An opaque a string that identifies the
      client.  Once a client has received an advertisement message from
      a server, it SHOULD copy the token from that message into all
      future registration messages to that server, so that the server
      can distinguish between new registrations and updates to existing
      registrations.

   "contacts":  OPTIONAL Array of String.  This field is an array of
      strings, where each string contains a URI that can be used contact
      the client.  If this field is included, but the array is empty,
      then the the server MUST delete any existing registration
      information for this client.

   "location":  OPTIONAL String.  This field is a string containing a
      "geopriv" element from a PIDF-LO, base64url encoded.

   "language":  OPTIONAL String.  This field is a string containing the
      language in which the client wishes to receive alerts, in the
      format defined by RFC 5646 [RFC5646].

   If a server receives a new registration message from a previously
   registered client (i.e., a registration message containing a token
   that the server has previously sent in an advertisement message),
   then the server should replace the existing registration information
   for that client with the information contained in the new
   registration message.  If the server receives a registration message
   containing only the token field, then the server should delete any
   existing registration information associated with this client.

4.1.3.  Refer

   Refer messages are sent from servers to clients.  These messages
   allow servers to notify clients of a different AMP server that the
   client should contact.  For example, if an AMP server receives a
   registration message indicating a location outside its jurisdiction,
   it might send a refer message that refers the client to an
   appropriate server for the client's current location.  A refer
   message must contain the following fields:

   "to":  REQUIRED String.  The URI of the AMP server to which the
      client is being referred.

   Upon receiving a Refer message, a client SHOULD send establish a new
   AMP session with the AMP server indicated in the "to" field of the
   refer message.






Lepinski, et al.        Expires January 16, 2013               [Page 10]

Internet-Draft                     AMP                         July 2012


4.1.4.  Alert

   Alert messages are sent from servers to client.  These messages are
   one mechanism for distributing local alerts.  (Other mechanisms for
   transporting local alerts include LEAP [I-D.barnes-atoca-delivery].)
   Alerts sent using an AMP alert message are encoded using ESCAPE
   [I-D.barnes-atoca-escape], then base64url encoded.  An Alert message
   contains the following fields:

   "alert_data":  REQUIRED String.  An ESCAPE-encoded, base64url-encoded
      alert message.

   The procedure for validating ESCAPE-encoded alert messages can be
   found in [I-D.barnes-atoca-escape]

4.2.  AMP Sessions

   An AMP session is a WebSocket connection over which AMP messages are
   conveyed.  The first goal of an AMP session is to inform a client
   about local alerting resources (alerting configuration information),
   but the client may maintain a long-lived AMP session in order to
   provide updated status (e.g., location or contact changes) as well as
   to get updated configuration information over time.

   The client initiates an AMP session by establishing a WebSocket
   connection to the AMP server.  The client sends the first message,
   providing a Registration message with relevant information.

   The AMP Server MUST respond with an Advertisement message containing
   local alert information immediately upon the establishment of a
   session.  If the initial Registration contained a "token" value, then
   the "token" field in the Advertisement MUST be either empty or equal
   to the registered token value.

   Once the initial handshake is complete, either side may send a
   message at any time.  When a message is received, the action taken
   depends on the type of message:

   o  Client receives Refer: The client SHOULD close the current AMP
      session and initiate a new AMP session with the server indicated
      in the "to" field of the message.  If the client received a token
      in the first session, then it SHOULD include that token in the
      initial Registration for the new session.

   o  Client receives Advertisement: The client MUST replace its local
      alert configuration information with the contents of the
      Advertisement.  If the "token" field is present, then the client
      MUST update its token.



Lepinski, et al.        Expires January 16, 2013               [Page 11]

Internet-Draft                     AMP                         July 2012


   o  Client receives Alert: The client MUST decode the encoded
      "alert_data" element and process the resulting ESCAPE message
      according to the ESCAPE validation rules.  If the alert is valid,
      the client renders it to the user.

   o  Server receives Registration: The server MUST replace its current
      state for the client with the state in the message.

      *  If the "token" field is present, the server MUST verify that it
         matches a token that it has assigned in an Advertisement
         message in this session; if not, then this message MUST be
         ignored.

      *  If the Registration message contains only the "type" field,
         then the server MUST delete any state associated with this
         session.

      *  If the location of the client has moved out of the server's
         coverage area, then the server MUST close the connection.  If
         the responsible AMP server for the client's new location is
         known, then the server SHOULD send a Refer message before
         closing the connection.

   If either side receives a message sent in the incorrect direction, it
   MUST ignore it.  For the server, this includes Advertisement, Refer,
   and Alert messages.  For the client, Registration messages.

   Servers SHOULD maintain information about AMP servers covering
   neighboring jurisdictions and their respective coverage areas.  That
   way, the server can issue a Refer message to the client as soon as
   the client reports that it has left the coverage area.  This will
   help ensure that the client always has up-to-date alerting
   configuration information, without the client having to repeatedly
   perform AMP discovery.


5.  IANA Considerations

   This document requires several registrations by IANA into existing
   registries, and creates a new registry of AMP message codes.

   [[ TODO: Register the URN: "urn:service:alert-info" ]]

   [[ TODO: Register NAPTR service tag "AMP" and application protocols
   "http", "https" ]]

   [[ TODO: Register media type application/amp+json ]]




Lepinski, et al.        Expires January 16, 2013               [Page 12]

Internet-Draft                     AMP                         July 2012


5.1.  AMP Message Type Registry

   IANA is requested to create a new registry of AMP Message Types.
   This registry contains two fields, the name of the name of the
   registered message type, and a specification pointer containing a
   reference to the document that defines the registered message type.

   IANA is requested to populate this new registry with the following
   four entries:

       Message Type Name                 Specification Pointer
   +--------------------------------+--------------------------------+
   |   Registration                 |   draft-barnes-atoca-meta      |
   |   Advertisement                |   draft-barnes-atoca-meta      |
   |   Refer                        |   draft-barnes-atoca-meta      |
   |   Alert                        |   draft-barnes-atoca-meta      |
   +--------------------------------+--------------------------------+


6.  Security Considerations

   [Author's Note: The Security Considerations will be fleshed out in
   more detail in the next version of this document.]

   The AMP protocol contains contact and location information for a
   device which for many devices will consist of private information
   regarding the user of the device.  Therefore, confidentiality
   protection should be used when the registration request contains
   private information.

   The modification of AMP messages can cause client devices to accept
   false alerts (in the case where the advertisement is modified) or to
   receive alerts for the improper location (if the registration is
   modified).  Therefore, integrity protection should be applied to AMP
   messages.

   The AMP protocol runs over HTTP.  Therefore, the use of HTTP over TLS
   can provide confidentiality and integrity protection for AMP
   messages.

   Alert server discovery makes use of NAPTR.  Standard security
   considerations involving the use of NAPTR apply.  DNSSEC SHOULD be
   used to protect the DNS responses provided during the discovery
   procedure.







Lepinski, et al.        Expires January 16, 2013               [Page 13]

Internet-Draft                     AMP                         July 2012


7.  Acknowledgements

   The authors would like to thank Derrick Kong for help in creating the
   JSON schema for the AMP protocol.


8.  References

8.1.  Normative References

   [I-D.barnes-atoca-escape]
              Barnes, R., "Encoding of Secure Common Alert Protocol
              Entities (ESCAPE)", draft-barnes-atoca-escape-00 (work in
              progress), October 2011.

   [I-D.ietf-geopriv-res-gw-lis-discovery]
              Thomson, M. and R. Bellis, "Location Information Server
              (LIS) Discovery using IP address and Reverse DNS",
              draft-ietf-geopriv-res-gw-lis-discovery-03 (work in
              progress), March 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

   [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC4848]  Daigle, L., "Domain-Based Application Service Location
              Using URIs and the Dynamic Delegation Discovery Service
              (DDDS)", RFC 4848, April 2007.

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, August 2008.

   [RFC5646]  Phillips, A. and M. Davis, "Tags for Identifying
              Languages", BCP 47, RFC 5646, September 2009.

   [RFC5986]  Thomson, M. and J. Winterbottom, "Discovering the Local
              Location Information Server (LIS)", RFC 5986,
              September 2010.




Lepinski, et al.        Expires January 16, 2013               [Page 14]

Internet-Draft                     AMP                         July 2012


   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, December 2011.

8.2.  Informative References

   [I-D.barnes-atoca-delivery]
              Barnes, R., "Lightweight Emergency Alerting Protocol
              (LEAP)", draft-barnes-atoca-delivery-01 (work in
              progress), October 2011.

   [RFC5223]  Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering
              Location-to-Service Translation (LoST) Servers Using the
              Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
              August 2008.


Authors' Addresses

   Matt Lepinski
   BBN Technologies
   10 Moulton St
   Cambridge, MA  02138
   US

   Phone: +1 617 873 5939
   Email: mlepinski@bbn.com


   Karen Seo
   BBN Technologes
   10 Moulton St
   Cambridge, MA  02138
   US

   Phone: +1 617 873 3152
   Email: kseo@bbn.com


   Richard Barnes
   BBN Technologies
   9861 Broken Land Parkway
   Columbia, MD  21046
   US

   Phone: +1 410 290 6169
   Email: rbarnes@bbn.com





Lepinski, et al.        Expires January 16, 2013               [Page 15]