Network Working Group                                          R. Barnes
Internet-Draft                                          BBN Technologies
Intended status: Informational                                  B. Aboba
Expires: April 21, 2011                            Microsoft Corporation
                                                             J. Peterson
                                                           NeuStar, Inc.
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                        October 18, 2010


    Policy Considerations for Emergency Calling using Voice over IP
                      draft-barnes-ecrit-policy-00

Abstract

   The provision of emergency calling services (e.g., 911, 112) has been
   a critical component in the regulation of telecommunications
   networks.  The technical architectures used by modern Voice-over-IP
   (VoIP) systems mean that if telecommunications regulators wish to
   extend emergency calling requirements to VoIP, it will likely be
   necessary to reconsider the ways in which such requirements are
   applied, both in terms of what specific mandates are imposed and
   which entities are subject to them.  This document dicusses the
   fundamental technical requirements for emergency services, how these
   requirements can be met within the framework of VoIP, and how these
   solutions approaches create possibilities and limitations for
   regulatory involvement.

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 April 21, 2011.

Copyright Notice




Barnes, et al.           Expires April 21, 2011                 [Page 1]


Internet-Draft        Policy Considerations for ES          October 2010


   Copyright (c) 2010 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
   (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
   2.  Fundamental Assumptions  . . . . . . . . . . . . . . . . . . .  4
   3.  VoIP Architecture  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Obligations  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  End Hosts  . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  ISP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  VSP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.4.  PSAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  Geolocation  . . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  Call Routing . . . . . . . . . . . . . . . . . . . . . . . 12
     5.3.  PSAP Reachability  . . . . . . . . . . . . . . . . . . . . 12
     5.4.  Regulatory Implications  . . . . . . . . . . . . . . . . . 12
   6.  Outlook  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

















Barnes, et al.           Expires April 21, 2011                 [Page 2]


Internet-Draft        Policy Considerations for ES          October 2010


1.  Introduction

   For several decades, emergency calling has been a critical function
   of telecommunications networks.  Starting in the 1960s, capabilities
   were created in many places around the world to allow any user of a
   telephone to reach emergency services simply by dialing a short
   string of digits (e.g., 9-1-1 in the US or 1-1-2 in Europe).
   Different countries have implemented these functions in their own
   ways, but basic emergency calling services are available throughout
   most of the world today.  Particuarly the introduction of automatic
   caller location, essentially for quickly and accurately dispatching
   first responders, was a painful and long process that is still
   ongoing in different parts of the world, particularly when
   considering location information with better accuracy.

   At the same time, an ever increasing amount of the voice traffic in
   the world is being carried via Voice-over-IP services.  Just as with
   other services, the transition to VoIP entails a transition from a
   circuit-based model of calling to a packet-based one.  Instead of a
   call having a dedicated channel over which signals are transmitted,
   in VoIP, voice signals are divided into small packets and sent
   through the Internet (with each packet traveling independently).
   From the underlying network point of view a VoIP call appears like
   any other application running over the Internet, rather than a core
   function of the network.  As we will discuss in more detail below,
   the fact that VoIP is an application makes it siginificantly more
   flexible than existing PSTN communications facilities, but by the
   same token, VoIP systems cannot take advantage of certain fixed
   properties of the PSTN, making it much more of a challenge to
   implement emergency services.

   So the situation is challenging: On the one hand, PSTN systems around
   the world are being transitioned over to VoIP systems, but on the
   other hand, the structure of VoIP systems makes them incompatible
   with the way emergency services are provided today.  In their attempt
   to enhance voice over IP with emergency services the technical
   community has designed a system for enabling VoIP emergency calling.
   Different organizations considered different deployment approaches
   known as the ECRIT architecture.  Even though the required
   technologies have already been defined the successful deployment of
   VoIP emergency services will require sharing of responsibilities by
   multiple players in the Internet ecosystem.  There is thus a need to
   re-think emergency calling regulation to take into account the
   structural differences between VoIP and traditional voice services
   and to consider the re-align of responsibilities in this multi-
   stakeholder eco-system.

   In this document, we review some fundamental properties of emergency



Barnes, et al.           Expires April 21, 2011                 [Page 3]


Internet-Draft        Policy Considerations for ES          October 2010


   calling systems and VoIP systems, and discuss how these two concepts
   come into conflict.  We then present approaches for resolving these
   conflicts, and some thoughts on the role that telecommunications
   regulation and policy can play in fostering the deployment of VoIP
   emergency services.


2.  Fundamental Assumptions

   The basic goal of an emergency calling service is to connect the
   caller with an emergency response center that can help with his
   emergency situation.  (These response centers are traditionally known
   as Public Safety Answering Points, or PSAPs.)  A responder's ability
   to help is typically limited to a certain geographical region for a
   specific service (such as police, fire, ambulance), either because of
   legal constraints (e.g., jurisdictional boundaries), because of
   organization structure and work split or simply because of the
   physical constraints on how fast a responder can travel to the scene
   of an emergency.  These structures and responsibilities change but in
   a much slower pace than technology.  So emergency calling is
   fundamentally a question of ensuring that a PSAP is reached that is
   responsible for the geographical area the emergency caller is
   currently located iin order to dispatch first responders.

   There are thus three fundamental functional requirements for a
   successful emergency call (whether over the PSTN, VoIP, or any other
   technology):

   1.  An entity routing the call must have access to information about
       the caller's location.
   2.  The same call-routing entity must know where to route the call.
   3.  The same call-routing entity must be able to forward a call to a
       PSAP.

   The challenge in enabling emerency calling using a given
   communications system is thus to determine how each of these steps is
   accomplished within that system.  In fixed-line PSTN networks, all
   three requirements were essentially met by virtue of wiring: Customer
   lines are connected to local switching centers, and switching centers
   typically cover areas that are served by a single PSAP, so any
   emergency call that arrives at a switching center can be routed to a
   dedicated line to the PSAP.  (In reality, the situation is somewhat
   more complex, but we summarize here for simplicity.)

   The advent of cellular systems forced a degree of separation among
   these functions, since the caller's location was not known in
   advance.  In order to provide emergency calling, cellular networks
   had to deploy specific capabilities to locate their subscribers, and



Barnes, et al.           Expires April 21, 2011                 [Page 4]


Internet-Draft        Policy Considerations for ES          October 2010


   upgrade switches that handle emergency calls so that they can query
   those capabilities and route calls based on the subsequent location.
   Even in this case, however, the routing function can be fairly
   static, because a particular cellular network only covers a specific
   geographic area.


3.  VoIP Architecture

   The IP-based emergency services access architectures differentiate a
   few components that have different responsibilities for offering the
   complete end-to-end functionality.  These roles are:
   o  Internet Service Provider (ISP)
   o  Voice Service Provider (VSP), or in a more generic form
      Application Service Provider (ASP)
   o  Emergency Service Provider (that operates a PSAP) and vendors of
      equipment for those.
   o  End Device

   Note that multiple roles be provided by a single organisation.

   [Editor's Note: Should we provide a short description of each of the
   roles?




























Barnes, et al.           Expires April 21, 2011                 [Page 5]


Internet-Draft        Policy Considerations for ES          October 2010


                  +--------------------+
                  |                    |
                  | Emergency Network  |
                  | Infrastructure     |
                  |                    |
                  | +----------+       |
                  | | PSAP     |       |
                  | |          |       |
                  | +----------+       |
                  +------^-------------+   (d)
                         +-----------------------------+
                                                       |
   +--------------+                              +-----+--------+
   |              |              ----            |     |        |
   | ISP          |          ///-    -\\\        |     | VSP    |
   |              |         /            \\      |     |        |
   | +----------+ |        |  Distributed |      | +---+------+ |
   | | LIS      | |       |   Mapping      |<--->| | Routing  | |
   | |          | |       |   Database     | (b) | | Entity   | |
   | +----------+ |        |              |      | +----------+ |
   |    ^         |         \            //      |     ^        |
   |    |         |          \\\-    -///        |     |        |
   |    |         |              ----            |     |        |
   +----+---------+  (b)          ^              +-----+--------+
        |   +---------------------+                    |
        |   |                       (c)                 |
        |   |   +--------------------------------------+
    (a) |   |   |
        v   v   v
      +-----------+
      | End       |
      | Host      |
      +-----------+

        Figure 1: Stakeholders in the Emergency Services Eco-System

      The references to interfaces (a), (b), (c), and (d) will be used
      in Section 4.

   The emergency call interaction on a high level takes place as
   follows: the user enters an emergency services number (or potentially
   an emergency dial string).  The end device recognises the entered
   sequence of digits as an emergency call attempt and determines
   whether location information is available locally (as part of the GPS
   module, for example).  If no location information is available
   locally then various protocol extensions have been defined that allow
   the end host to obtain location information from a Location
   Information Server in the ISPs network.  Then, the call setup



Barnes, et al.           Expires April 21, 2011                 [Page 6]


Internet-Draft        Policy Considerations for ES          October 2010


   procedure using SIP is started towards the users VSP/ASP.  The VSP/
   ASP needs to make a route decision to determine where the call needs
   to be forwarded to.  Often, this decision is based on a combination
   of the callers location information as well as other policy aspects
   (such as time-of-day, workload of a specific PSAP).

   When considering IP-access to emergency services, one should consider
   the following categories and the challenges they induce:
   Fixed Access:  From a user point of view this scenario is
      characterised by a stationary usage of a computer, such as a
      desktop PC at someones home.  Typically, these devices are often
      not equipped with a GPS receiver or, because of the indoor usage,
      these do not work very well or not at all.  Information about the
      callers location can therefore come from manual configuration
      (which may be useful in cases where the location of the device
      indeed rarely changes or the user is careful in keeping the
      reported location accurate) or from the ISPs network since the
      attachment point is known to the operators network infrastructure.
   Nomadic Access:  Nomadic access is characterised in movement patterns
      that correspond to regular laptop usage where users switch
      location from time to time (e.g. go to work, use their laptop at
      the university or in a coffee shop, and at home).  In this
      scenario it is not realistic to assume that users update their
      location manually due to the frequent change.  The usage of GPS
      may be possible even though network operator presented location
      would be preferred since users will typically use their device
      indoors where GPS does not work well.
   Mobile Access:  This scenario is an enhancement of the previously
      presented nomadic access with the assumption that users roam while
      having their communication ongoing.  In this scenario, devices,
      such as smart phones, are often equipped with GPS receivers and
      make the location determination process more accurate.  Manually
      entered location is in this scenario not possible.

   Note: This is a simplified view on networking from the users point of
   view.  As network architectures become more sophisticated the
   boundaries between these scenarios get more fuzzy.  As an example,
   one may consider a traveller using a laptop with wireless LAN (as he
   uses at home) in a train connected.  The network infrastructure in
   the train is connected via a cellular infrastructure to the Internet.
   This example blurs nomadic access and mobile access.  Consider
   another example where a teenager uses his high-performance laptop for
   gaming and sometimes uses it at home as a replacement for the desktop
   PC and sometimes at some LAN parties to compete with other games.
   From software program point of view these cases are very hard to
   differentiate since in all cases the end device is uses WLAN
   technology to communicate with the network.  Hence, it is left to the
   user to 'switch' between usage environments, which introduce problems



Barnes, et al.           Expires April 21, 2011                 [Page 7]


Internet-Draft        Policy Considerations for ES          October 2010


   when software developers make too restrictive assumptions about the
   environment where their devices will later be used or about the users
   awareness of the necessary configuration changes.  Ideally, users
   should not need to configure their devices to prepare for the case of
   an emergency call.  For the unlikely case of an emergency users
   should not be required to ever configure their device - zero
   configuration is the goal.

   From user-experience point of view the overall process of
   establishing an emergency call begins someone dialling an emergency
   dial string.  The exact sequence of digits depends on the
   infrastructure the device is connected to.  While 1-1-2 became the
   emergency services number for Europe and 9-1-1 the emergency number
   for the US many countries still provide additional emergency numbers
   mostly for historical reasons.  Furthermore, many large enterprises,
   university, and hotels prefix the emergency numbers with additional
   digits, such as 0-112.

   An important part of emergency handling is in the logic of delivering
   emergency calls to the appropriate PSAP.  With devices that may be
   used with different VSPs/ASPs and in cases where there is no
   relationship between the ISP and the VSP/ASP the automatic routing
   decision becomes more complex.  Consider the following example where
   user Bob travels to from Sweden to Spain and wants to use their
   device to trigger an emergency real-time text interaction.  Since Bob
   is using a real-time text provider in Sweden the messages are routed
   to the Swedish operator.  Based on the provided location the Swedish
   operator notices that a PSAP in Spain has to be involved and, for
   example, initiates a conference bridge with Bob, a relay provider in
   Sweden serving as a language translator, and the PSAP operator in
   Spain.  In order for the Swedish ASP/VSP or the Swedish PSAP to
   involve the appropriate Spanish PSAP their contact information needs
   to be available, and information about their responsibility (i.e. for
   which region they are responsible and which emergency service
   function they provide) needs to be published.

   A protocol, called Location to Service Translation (LoST), has been
   defined to map a location together with a symbolic representation of
   the emergency service requested to a specific PSAP contact address
   (PSAP URI).  Note that the returned PSAP URI does not necessary need
   to be the contact information of the final PSAP but rather it will
   route the call closer to one.

   Location information is needed by emergency services for three
   reasons: routing the call to the right PSAP, dispatching first
   responders (e.g. policemen), and determining the right emergency
   service dial strings.  It is clear that the location has to be
   automatic for the first and third application, but experience has



Barnes, et al.           Expires April 21, 2011                 [Page 8]


Internet-Draft        Policy Considerations for ES          October 2010


   shown that automated, highly-accurate location information is vital
   to dispatching as well, rather than relying on the caller to report
   his or her location to the call taker.  This increases accuracy and
   avoids dispatch delays when the caller is unable to provide location
   information due to language barriers, lack of familiarity with his or
   her surroundings, stress, physical or mental impairment.  Location
   information for emergency purposes comes in two representations:
   geo(detic), i.e., longitude and latitude, and civic, i.e., street
   addresses similar to postal addresses.  Particularly for indoor
   location, vertical information (floors) is very useful.  Civic
   locations are most useful for fixed Internet access, including
   wireless hot spots, and are often preferable for specifying indoor
   locations, while geodetic location is frequently used for cell
   phones.  However, with the advent of femto, and pico cells, civic
   location is both possible and probably preferable since accurate
   geodetic information can be very hard to acquire indoors.

   Before location can be put into a protocol for delivery and utilised
   it first needs to be determined.  Location information can be entered
   by a user ("manual configuration"), measured by the end host, can be
   delivered to the end system by some protocol or measured by a third
   party.  The actual process of location determination is largely
   outside the scope of the REACH-112 project but manual configuration,
   GPS usage, and the usage of location servers is relevant.  Many VoIP
   deployments allow their users to manually enter location information
   for later usage with emergency services.  Typically, the users enter
   their home address into a web-based form and this data would then be
   used for emergency service call routing and also delivered to PSAP
   operators.  This mechanism is primarily suitable for users utilising
   fixed network deployments (such as Cable and DSL networks) rather
   than cellular networks where the current users location changes
   continuously.  For nomadic users this approach already becomes very
   cumbersome for end users.  While this mechanism clearly has
   limitations it is still a useful approach in absence of other
   techniques.  For devices like laptops and in particular mobile phones
   the usage of GPS is a promising technique that is able to provide
   highly accuracy.  While it has also has limitations (for example when
   used indoor) and may need a fair amount of time to provide the
   initial location fix it is a promising technique.  The requirements
   for location accuracy differ between routing and dispatch.  For call
   routing, city or even county-level accuracy is often sufficient,
   depending on how large the PSAP service areas are, while first
   responders benefit greatly when they can pinpoint the caller to a
   particular building or, better yet, apartment or office for indoor
   locations, and an outdoor area of at most a few hundred meters
   outdoors.  This avoids having to search multiple buildings, e.g., for
   medical emergencies.




Barnes, et al.           Expires April 21, 2011                 [Page 9]


Internet-Draft        Policy Considerations for ES          October 2010


   For a realiable emergency services infrastructure utilizing the
   location information provided by ISPs is important, largely for
   dispatch purposes since the accuracy is sufficiently high to allow
   first responders to locate the person in need for help.


4.  Obligations

   In this section we discuss how the responsibilities for deployment
   need to be shared based on the architectural illustration from
   Figure 1.  Note that this narration focuses on the final stage of
   deployment and do not discuss the transition architecture, in which
   some implementation responsibilities can be re-arranged, with an
   impact on the overall functionality offered by the emergency services
   architecture.  A few variations were introduced to handle the
   transition from the current system to a fully developed ECRIT
   architecture.

4.1.  End Hosts

   An end host, through its VoIP application, has three main
   responsibilities: it has to attempt to obtain its own location,
   determine the URI of the appropriate PSAP for that location, and
   recognize when the user places an emergency call by examining the
   dial string.  The end host operating system may assist in determining
   the device location.  The protocol interaction for location
   configuration is indicated as interface (a) in Figure 1 and a number
   of location configuration protocols have been developed to provide
   this capability.

   A VoIP application needs to have the ability to detect the emergency
   call, to obtain (potentially only locally available) location
   information, and to make it available to the VSP during call setup.

4.2.  ISP

   The ISP has to make location information available to the end point
   via one or more of the location configuration protocols.  In order to
   route an emergency call correctly to a PSAP, an ISP may initially
   disclose the approximate location for routing to the end point and
   more precise location information later, when emergency personnel is
   dispatched by the PSAP operator.  The functionality required by the
   IETF emergency services architecture is restricted to the disclosure
   of a relatively small amount of location information, as discussed in
   [I-D.ietf-ecrit-location-hiding-req] and in
   [I-D.ietf-ecrit-rough-loc].

   The ISP may also operate a (caching) LoST server to improve the



Barnes, et al.           Expires April 21, 2011                [Page 10]


Internet-Draft        Policy Considerations for ES          October 2010


   robustness and the reliability of the architecture.  This lowers the
   roundtrip time for contacting a LoST server and the caches are most
   likely to hold the mappings of the area where the emergency caller is
   currently located.

   In case ISPs allow Internet traffic to traverse their network the
   signaling and media protocols used for emergency calls function
   without problems.  Today, there are no legal requirements to offer
   prioritization of emergency calls over IP-based networks.  While the
   standardization community has developed a range of Quality of Service
   signaling protocols their (widespread) deployment still remains to
   happen.

4.3.  VSP

   SIP does not mandate that call setup requests need to traverse SIP
   proxies, i.e., SIP messages can be sent directly to the user agent.
   Thus, even for emergency services it is possible to use SIP without
   the involvement of a VSP.  However, in terms of deployment, it is
   highly likely that a VSP will be used.  If a caller uses a VSP, this
   VSP often forces all calls, emergency or not, to traverse an outbound
   proxy or session border controller (SBC) operated by the VSP.  If
   some end devices are unable to perform a LoST lookup, VSP can provide
   the necessary functions as a back-up solution.  If the VSP uses a
   signaling or media protocol that is not supported by the PSAP, it
   needs to translate the signaling or media flows.

   VSPs can assist the PSAP by providing identity assurance for
   emergency calls and thus helping to prosecute prank callers.
   However, the link between the subscriber information and the real-
   world person making the call is weak.  In many cases, VSPs have, at
   best, only the credit card data for their customers and some of these
   customers may use gift cards or other anonymous means of payment.

4.4.  PSAP

   When emergency calling has been fully converted to Internet
   protocols, PSAPs must accept calls from any VSP, as shown in
   interface (d) of Figure 1.  Since calls may come from all sources,
   PSAPs must develop mechanisms to reduce the number of malicious
   calls, particularly calls containing intentionally false location
   information.  Assuring the reliability of location information
   remains challenging, particularly as more and more devices are
   equipped Global Navigation Satellite Systems (GNSS) receivers,
   including GPS and Galileo, allowing them to determine their own
   location.  However, it may be possible in some cases to the veracity
   of the location information provided by an end-point by comparing it
   against infrastructure-provided location information, e.g., LIS



Barnes, et al.           Expires April 21, 2011                [Page 11]


Internet-Draft        Policy Considerations for ES          October 2010


   determined location.


5.  Requirements

   [[ TBD: We need to add a bit of wording here in this section to your
   notes.  I think that this section should also talk about the
   distribution of responsibilities among the stake holders and motivate
   why they want to do this.  Then, we have no requirement yet for
   multi-media emergency calls, which would be good to have.]]

5.1.  Geolocation

   [[ -- Location -- Basic requirement: Get location information to a
   call-routing entity -- Endpoint or VoIP service -- ... but probably
   the endpoint (security reasons) -- State of the art today -- Carrier
   location functions; inaccessible to end devices -- "World in a DB"
   functions; low-fidelity -- GPS; frequently fails -- Commercial
   direction is not moving quickly away from these stovepipes -- GEOPRIV
   model provides bridges, but not much uptake -- Also provides a
   location interface for PSAPs, e.g. as NENA has defined ]]

5.2.  Call Routing

   [[ -- Call routing -- Need a pubic, open DB with a standard query
   interface -- Source of the data needs to be local emergency
   authorities => Need for local authorities to coordinate to create
   LoST DB(s) ]]

5.3.  PSAP Reachability

   [[ -- PSAP reachability -- Basic requirement: Internet connectivity,
   SIP reachability -- Gatways as a transition step -- Security
   questions; ref to ESInet concepts ]]

5.4.  Regulatory Implications

   [[ -- Roles government can play -- Who can be the targets of
   regulation? -- Localized (yes): PSAPs, ISPs, vertically-integrated
   VoIP -- Non-localized (no): Application-only VoIP, application-only
   location providers -- Enabling location: -- Several networks that
   provide E911 are also ISPs -- Require them to open up ALI or
   equivalents to endpoint, PSAP access -- How to enable NG911 without
   giving away the store: rough-loc -- Encourage ISPs in general to
   enable location services for customers -- Call routing: -- Coordinate
   the development of a national LoST infrastructure -- Formalize LoST
   as a national standard call-routing interface -- Encourage ISPs to
   support LoST discovery -- PSAP reachability: -- Support PSAP upgrades



Barnes, et al.           Expires April 21, 2011                [Page 12]


Internet-Draft        Policy Considerations for ES          October 2010


   and gateways -- Encourage VoIP vendors to integrate emergency calling
   into products -- E.g., support open-source location, LoST components
   ]]


6.  Outlook

   In most countries, national and sometimes regional telecommunications
   regulators have a strong influence on how emergency services are
   provided; such as who pays for them and what obligations the various
   parties have.  Regulation is, however, still at an early stage: in
   most countries current requirements only demand manual update of
   location information by the VoIP user.  The ability to obtain
   location information automatically is, however, crucial for reliable
   emergency service operation, and required for nomadic and mobile
   devices.  (Nomadic devices remain in one place during a communication
   session, but are moved frequently from place top place.  Laptops with
   WiFi interfaces are currently the most common nomadic device.)

   Regulators have traditionally focused on the national or, at most,
   the European level, and the international nature of the Internet
   poses new challenges.  For example, mobile devices are now routinely
   used beyond their country of purchase and, unlike traditional
   cellular phones, need to support emergency calling functionality.  It
   appears likely that different countries will deploy IP-based
   emergency services over different time horizons, so that a traveler
   may be surprised to find that she cannot call for emergency
   assistance outside their home country.

   The separation between Internet access and application providers on
   the Internet is one of the most important differences to existing
   circuit switched telephony networks.  A side effect of this
   separation is the increased speed of innovation at the application
   layer and the number of new communication mechanisms is steadily
   increasing.  Many emergency service organizations have recognized
   this trend and advocated for the use of new communication mechanisms,
   including video, real-time text, and instant messaging, to offer
   improved emergency calling support for citizens.  Again, this
   requires regulators to re-think the distribution of responsibilities,
   funding and liability.

   Many communication systems in use today lack accountability, i.e., it
   is difficult or impossible to trace malicious activities back to the
   persons who caused it.  This is not a completely new problem, as pay
   phones and prepaid cell phones have long offered mischief makers the
   opportunity to place hoax calls, but the weak user registration
   procedures, the lack of deployed end-to-end identity mechanisms, and
   the ease of providing fake location information increases the attack



Barnes, et al.           Expires April 21, 2011                [Page 13]


Internet-Draft        Policy Considerations for ES          October 2010


   surface at PSAPs.  Attackers also got more sophisticated over time
   and Botnets to generate a large volume of automated emergency calls
   to exhaust PSAP resources, including call takers and first
   responders, is not science fiction.


7.  Security Considerations

   [TODO]


8.  IANA Considerations

   This document has no actions for the IANA.


9.  Informative References

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

   [I-D.ietf-ecrit-location-hiding-req]
              Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and
              A. Kuett, "Location Hiding: Problem Statement and
              Requirements", draft-ietf-ecrit-location-hiding-req-04
              (work in progress), February 2010.

   [I-D.ietf-ecrit-rough-loc]
              Barnes, R. and M. Lepinski, "Using Imprecise Location for
              Emergency Context Resolution",
              draft-ietf-ecrit-rough-loc-03 (work in progress),
              August 2010.


Authors' Addresses

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

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







Barnes, et al.           Expires April 21, 2011                [Page 14]


Internet-Draft        Policy Considerations for ES          October 2010


   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   Email: bernarda@microsoft.com


   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St Suite 570
   Concord, CA  94520
   US

   Email: jon.peterson@neustar.biz


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at
























Barnes, et al.           Expires April 21, 2011                [Page 15]