--- 1/draft-ietf-ecrit-held-routing-04.txt	2016-02-09 03:15:43.126074413 -0800
+++ 2/draft-ietf-ecrit-held-routing-05.txt	2016-02-09 03:15:43.158075218 -0800
@@ -1,51 +1,54 @@
 
 ECRIT                                                    J. Winterbottom
 Internet-Draft                               Winterb Consulting Services
-Updates: RFC6881, RFC5985 (if approved)                    H. Tschofenig
+Updates: 6881, 5985 (if approved)                          H. Tschofenig
 Intended status: Standards Track
-Expires: June 11, 2016                                          L. Liess
+Expires: August 12, 2016                                        L. Liess
                                                         Deutsche Telekom
-                                                        December 9, 2015
+                                                        February 9, 2016
 
            A Routing Request Extension for the HELD Protocol
-                  draft-ietf-ecrit-held-routing-04.txt
+                  draft-ietf-ecrit-held-routing-05.txt
 
 Abstract
 
    For cases where location servers have access to emergency routing
    information they are able to return routing information with the
    location information if the location request includes a request for
    the desired routing information.  This document specifies an
-   extension to the HELD protocol, updating [RFC5985], to support this
-   funciton.
+   extension to the HELD protocol that updates RFC5985, to support this
+   funciton.  Allowing location and routing information to be acquired
+   in a single request response exchange updates RFC6881, as current
+   location acquisition and route determination procedures are separate
+   operations.
 
 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 June 11, 2016.
+   This Internet-Draft will expire on August 12, 2016.
 
 Copyright Notice
 
-   Copyright (c) 2015 IETF Trust and the persons identified as the
+   Copyright (c) 2016 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
@@ -53,21 +56,21 @@
 
 Table of Contents
 
    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
    2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
    3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
      3.1.  LoST Reuse Considerations . . . . . . . . . . . . . . . .   6
    4.  Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . .   6
    5.  Modification to Phone BCP . . . . . . . . . . . . . . . . . .   7
    6.  HELD Schema Extension . . . . . . . . . . . . . . . . . . . .   8
-   7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
    8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12
    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
    10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
      10.1.  URN sub-namespace registration for
             'urn:ietf:params:xml:ns:geopriv:held:ri' . . . . . . . .  13
      10.2.  XML Schema Registration  . . . . . . . . . . . . . . . .  13
    11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
    12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
      12.1.  Normative References . . . . . . . . . . . . . . . . . .  14
      12.2.  Informative References . . . . . . . . . . . . . . . . .  14
@@ -99,20 +102,22 @@
    document are to be interpreted as described in [RFC2119].
 
    The terms Location Information Server (LIS), Emergency Services
    Routing Proxy (ESRP), Voice Service Provider (VSP) and Public Safety
    Answering Point (PSAP) are used as defined in [RFC6443].
 
    The term "Access Network Provider" is used as defined in [RFC5687]
    and incompasses both the Internet Access Provider (IAP) and Internet
    Service Provider (ISP).
 
+   The term "Forest Guide" is used as defined in [RFC5582].
+
 3.  Motivation
 
    The Internet emergency calling architecture specified in [RFC6881]
    describes two main models for emergency call processing.  The first
    is a device-centric model, where a device obtains location
    information using a location configuration protocol, such as HELD
    [RFC5985], and then proceeds to determine the address of the next hop
    closer to the local PSAP using LoST [RFC5222].  Figure 1 shows this
    model in a simplified form.
 
@@ -264,57 +269,58 @@
    specified service URN, MUST follow the URN traversal rules defined in
    [RFC5031].
 
    A LIS that receives a request for emergency routing information that
    it understands MUST return the correct emergency routing information
    if it has or is able to acquire the routing information for the
    location of the target device.
 
    The routing information in the location response consists of a
    service element identified by a service name.  The service name is a
-   urn and might contain a general emergency service urn such as
-   urn:service:sos or might contain a specific service urn depending on
+   URN and might contain a general emergency service URN such as
+   urn:service:sos or might contain a specific service URN depending on
    what was requested and what the LIS is able to provide.  A list of
    one or more service destinations is provided for the service name.
    Each destination is expressed as a URI and each URI scheme should
    only appear once in this list.  The routing URIs are intended to be
    used at the time they are received.  To avoid any risks of using
    stale routing URIs the values MUST NOT be cached by the receiving
    entity.
 
 5.  Modification to Phone BCP
 
    This section describes the normative updates to Phone BCP [RFC6881].
 
    It is important for devices and intermediaries to take all steps
    possible to ensure that emergency calls are routed to the correct
-   PSAPS.  In absence of global forest guides or local LoST servers and
-   the possibility that the local network may be configured with PSAP
-   address information, this specification updates Phone BCP [RFC6881].
-   The update requires devices and intermediaries using the HELD
-   protocol to always include the HELD routing extension.  If the LIS is
-   configured with the routing information it can provide it, if it is
-   not then the device or intermediary tries LoST to acquire the PSAP
-   URI.
+   PSAP.  An alternative to providing routing information via global
+   forest guides or local LoST servers is for local networks to
+   configure the PSAP address information in the network location
+   server.  This specification updates Phone BCP [RFC6881] to provide
+   this option.  The update requires devices and intermediaries using
+   the HELD protocol to always include the HELD routing extension.  If
+   the LIS is configured with the routing information it can provide it,
+   if it is not then the device or intermediary tries LoST to acquire
+   the PSAP URI.
 
    Section 6.5 of [RFC6881] defines "End System Location Configuration".
    Requirement ED-23/INT-18/SP-14 is updated when HELD is used as the
    LCP such that "the request MUST include the requestRoutingInformation
    element".  The remainder of the requirement remains unchanged.
 
-   This document adds a new requirement to section 7 of [RFC6881].
+   This document adds a new requirement to Section 7 of [RFC6881].
 
    "ED-51a : Endpoints MUST support the HELD requestRoutingInformation
    element and be able and be able to interpret and use any routing
    information returned in the locationResponse."
 
-   This document adds two new requirements to section 8 of [RFC6881].
+   This document adds two new requirements to Section 8 of [RFC6881].
 
    "ED-52a : Endpoints that acquire routing information in a HELD
    locationResponse SHOULD use this routing information but MAY perform
    a LoST findService request if they have a location value."
 
    "ED-52b : Endpoints that acquire routing information in a HELD
    locationResponse with a defaultRoute attribute of true MUST perform a
    LoST findService request if they have a location value.  If a route
    is provided by the LoST server then this route MUST be used,
    otherwise the routing information provided in the HELD response
@@ -384,25 +392,25 @@
 
    <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
                     responseTime="emergencyRouting">
 
            <requestRoutingInformation
                xmlns="urn:ietf:params:xml:ns:geopriv:held:ri"/>
 
            <flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow"
                  layer4="tcp" layer3="ipv4">
               <src>
-                 <address>192.168.1.1</address>
+         <address>192.0.2.12</address>
                  <port>1024</port>
               </src>
               <dst>
-                 <address>10.0.0.1</address>
+         <address>192.0.2.195</address>
                  <port>80</port>
               </dst>
            </flow>
    </locationRequest>
 
                     Figure 3: Example Location Request.
 
    Figure 4 illustrates the <locationResponse> message containing two
    location URIs: a HTTPS and a SIP URI.  Additionally, the response
    contains routing information.
@@ -449,40 +457,40 @@
          </service>
       </routingInformation>
 
    </locationResponse>
 
    Figure 5: Example Location Response with default routing information
 
 8.  Privacy Considerations
 
    This document makes no changes that require privacy considerations
-   beyond those already described in [RFC5687].  It does however extend
+   beyond those already described in [RFC5985].  It does however extend
    those described in [RFC6155].
 
-   [RFC5687] describes the issues surrounding Layer 7 location
-   configuration protocols, which this document makes no specific
-   changes to.
+   [RFC5985] describes the privacy considerations surrounding the HELD
+   location configuration protocol, and this document makes no specific
+   changes to these considerations.
 
    [RFC6155] extends HELD beyond a simple location configuration
    protocol (LCP) by enabling authorized third-parties to acquire
    location information and describes the issues in Section 4.  The HELD
    Routing extension supports returning URIs that represent specific
    services operating in the Target's vicinity.  This represents
    additional information about the Target, as a consequence it is
    recommended that this option only be used when the LIS returns a
    location URI, not a location value.
 
 9.  Security Considerations
 
    This document imposes no additional security considerations beyond
-   those already described in [RFC5687] and [RFC6155].
+   those already described in [RFC5985] and [RFC6155].
 
 10.  IANA Considerations
 
 10.1.  URN sub-namespace registration for
        'urn:ietf:params:xml:ns:geopriv:held:ri'
 
    This document calls for IANA to register a new XML namespace, as per
    the guidelines in [RFC3688].
 
    URI:  urn:ietf:params:xml:ns:geopriv:held:ri
@@ -562,20 +570,24 @@
    [RFC5031]  Schulzrinne, H., "A Uniform Resource Name (URN) for
               Emergency and Other Well-Known Services", RFC 5031,
               DOI 10.17487/RFC5031, January 2008,
               <http://www.rfc-editor.org/info/rfc5031>.
 
    [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
               Tschofenig, "LoST: A Location-to-Service Translation
               Protocol", RFC 5222, DOI 10.17487/RFC5222, August 2008,
               <http://www.rfc-editor.org/info/rfc5222>.
 
+   [RFC5582]  Schulzrinne, H., "Location-to-URL Mapping Architecture and
+              Framework", RFC 5582, DOI 10.17487/RFC5582, September
+              2009, <http://www.rfc-editor.org/info/rfc5582>.
+
    [RFC5687]  Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
               Location Configuration Protocol: Problem Statement and
               Requirements", RFC 5687, DOI 10.17487/RFC5687, March 2010,
               <http://www.rfc-editor.org/info/rfc5687>.
 
    [RFC5986]  Thomson, M. and J. Winterbottom, "Discovering the Local
               Location Information Server (LIS)", RFC 5986,
               DOI 10.17487/RFC5986, September 2010,
               <http://www.rfc-editor.org/info/rfc5986>.