Subject: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 17 Feb 2015 17:45:49 +0100

Hi Chairs,

what are the planned next steps for the " A Routing Request Extension
for the HELD Protocol" document?

Content-wise this is a fairly simple document and I am wondering whether
the WGLC could be issued sooner rather than later?

Ciao
Hannes

---

From: Roger Marshall <[email-masked]>
Date: Thu, 19 Feb 2015 16:48:05 +0000

Hannes:
Before predicting chair actions for this -00 draft, it would be good to see some comments on the list.  What is the level of interest for this draft?

I'll start with my own (as private wg member) comments:

C1. Suggest expanding the Introduction, since Abstract is essentially word-for-word as the Introduction.  
C2. Section 3, consider rewording the following text:

Change from:
In many cases the LIS already knows the destination PSAP address for any given location.  In [RFC6881] for example, the LIS validates all
   civic locations using a location validation procedure.  This procedure is the same as a routing request and so the LIS has the
   resulting the PSAP routing information.  In other cases, the LIS knows the correct PSAP for a given location at provisioning time, or
   the access network might always route to the same emergency provider.  Irrespective of the way in which the LIS learns the PSAP address for
   a location, the LIS will, in a great many cases, have this information.

Change to:
In many cases, the LIS already knows the destination PSAP route URI for a given location.  In [RFC6881] for example, the LIS validates 
civic locations using a location validation procedure based on the LoST protocol [RFC5222].  This procedure is similar to a routing request 
procedure using the LoST protocol and also provides the LIS with the same resultant PSAP routing information.  In other cases, the LIS 
knows the correct PSAP for a given location at provisioning time, or the access network might always route to the same emergency provider.  
Irrespective of the way in which the LIS learns the PSAP route URI for a location, the LIS may, in many cases, already have this information.

C3. Section 3 & throughout, consider qualifying "PSAP address" to be more specific - something like PSAP URI, PSAP routing URI, etc.  (as used above)

C4. Section 4, s/device/end device/g (where applicable)

C5. Section 4, When the text states,

"
A LIS that does not understand the routing request element ignores it and returns location as normal."

Question, has there been consideration of an error message returned for this case (or other cases)?  If so, what is the impact of providing an error message(s).

C6. Section 4, Please clarify use of "mapping element" in paragraph 5.

C7. Section 5, s/<xs:complextContent>/<xs:complexContent>/1

-roger marshall.

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, February 17, 2015 8:46 AM
To: [email-masked]
Subject: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00

Hi Chairs,

what are the planned next steps for the " A Routing Request Extension for the HELD Protocol" document?

Content-wise this is a fairly simple document and I am wondering whether the WGLC could be issued sooner rather than later?

Ciao
Hannes

---

From: Roger Marshall <[email-masked]>
Date: Thu, 19 Feb 2015 22:02:53 +0000

In addition to the more editorial/technical comments provided (inline, below), I'd like to include some more general comments based on my reading of this initial draft.

1. This approach of modifying HELD into something more than for location use seeks to find a way to solve a domain/privacy data issue.  Not really a messaging issue.

2. This draft makes the point that LoST servers and forest guides are not yet available, and yet justifies this HELD protocol extension by the fact that the LIS would already have access to a LoST server for validation purposes!  This argument is circular.

3. There is no mention of all the other information that LoST returns.  What does the LIS do with this other information?  To make the LIS the center of focus for routing requires additional policy rule processing.  The result of all this seems to be to turn a LIS into a NENA i3 ESRP+PRF or 3GPP LRF, something standards don't need to do.

4.  Existing deployed systems don't really follow either architectural model contained in the draft, but are slowly moving in one or the other of those directions.  Just as it would be better for emergency services to NOT standardize each of the many transitional variants in the field, neither should this variant be standardized, as it will only dilute the fundamental models that are shown.

5.  Doesn't the desire to standardize an extension to HELD to additionally carry routing URIs stray from the original design intent of HELD?  It is named "HTTP Emergency Location Delivery".  Why not use a standard ESRP or LRF function to query location and routing within the carrier's private domain, then egress the call with location/location URI intact?
 
-roger marshall.

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: Thursday, February 19, 2015 8:48 AM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00

Hannes:

Change from:

Change to:
In many cases, the LIS already knows the destination PSAP route URI for a given location.  In [RFC6881] for example, the LIS validates civic locations using a location validation procedure based on the LoST protocol [RFC5222].  This procedure is similar to a routing request procedure using the LoST protocol and also provides the LIS with the same resultant PSAP routing information.  In other cases, the LIS knows the correct PSAP for a given location at provisioning time, or the access network might always route to the same emergency provider.  
Irrespective of the way in which the LIS learns the PSAP route URI for a location, the LIS may, in many cases, already have this information.

"

-roger marshall.

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, February 17, 2015 8:46 AM
To: [email-masked]
Subject: [Ecrit] Next steps for draft-ietf-ecrit-held-routing-00

Hi Chairs,

Ciao
Hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: James Winterbottom <[email-masked]>
Date: Fri, 20 Feb 2015 09:22:41 +1100

I will respond in more detail later, but from the initial reading below there seems to be a misunderstanding as to where the draft is applicable. I also disagree with some of the assertions below.

I will look to see where some of the misunderstanding might be better clarified.

Sent from my iPhone

> On 20 Feb 2015, at 9:02 am, Roger Marshall <[email-masked]> wrote:
>

---

From: James Winterbottom <[email-masked]>
Date: Fri, 20 Feb 2015 18:09:06 +1100

Okay, let’s start with this one. Please inline.

> 1. This approach of modifying HELD into something more than for location use seeks to find a way to solve a domain/privacy data issue.  Not really a messaging issue.

[AJW] I think it is a messaging issue, in that it can reduce the number of messages required, and, if used in specific ways it can contain what elements in the call path have access to the actual physical location of the device. I will look this section over again and see if I can make it clearer. 

> 2. This draft makes the point that LoST servers and forest guides are not yet available, and yet justifies this HELD protocol extension by the fact that the LIS would already have access to a LoST…
[AJW] Not really. Access networks as you know can expand a large number of areas, and ESInets do not need to be big, and nor do they have to provide unveiled access to their internal ECRFs. As a consequence an ANP may have access into an ESINet, but that does not mean that all transient devices attached their network have this same access. In this case, the argument is not circular, it means they can provide a single interface the devices attached to the network and still validate locations against a local emergency authority. 

> 3. There is no mention of all the other information that LoST returns.  What does the LIS do with this other information?  To make the LIS the center of focus for routing requires additional policy…

[AJW]  HUH???? The role the LIS here is to provide the address of the ECSP (in ETSI speak), which is analogous to the ESRP in i3, that is all. PRF is a totally different function and currently outside the scope of ECRIT. The LRF is a core node, not an access node, and it may or may not use LoST but it absolutely tied into the emergency call path and remains their for the duration. This is not doing that, any more than a LoST server is doing that.

> 4.  Existing deployed systems don't really follow either architectural model contained in the draft, but are slowly moving in one or the other of those directions.  Just as it would be better for e…
[AJW] I am not sure what you mean by existing deployed systems and architectural model directions? 

> 5.  Doesn't the desire to standardize an extension to HELD to additionally carry routing URIs stray from the original design intent of HELD?  It is named "HTTP Emergency Location Delivery".  Why no…
[AJW] HELD is HTTP-Enabled Location Delivery, emergency is just one application. The purpose of the routing information is get the call to the ESRP, so I am not sure what you are getting at here. The LRF is a two step approach and requires a core-node associated with the voice and access network and uses information about both order to make its decision. I will make it more clear that there is no explicit trust or ownership arrangement required between the VSP and ANP. This should avoid any confusion.

Cheers
James

---

From: James Winterbottom <[email-masked]>
Date: Fri, 20 Feb 2015 18:15:39 +1100

Comments inline.

Thanks for the comments

> On 20 Feb 2015, at 3:48 am, Roger Marshall <[email-masked]> wrote:
> 
> Hannes:
[AJW] Agreed, I will look at the introduction.

> Irrespective of the way in which the LIS learns the PSAP route URI for a location, the LIS may, in many cases, already have this information.
[AJW] Sure.

> C3. Section 3 & throughout, consider qualifying "PSAP address" to be more specific - something like PSAP URI, PSAP routing URI, etc.  (as used above)
[AJW] Sure.

> C4. Section 4, s/device/end device/g (where applicable)
[AJW] Sure.

> Question, has there been consideration of an error message returned for this case (or other cases)?  If so, what is the impact of providing an error message(s).
[AJW] I don’t think an error is warranted here, not returning anything is fine. If the user requests it but doesn’t get anything then they try other methods. I think an error just complicates things. 

> C6. Section 4, Please clarify use of "mapping element" in paragraph 5.
[AJW] I will look at this. Randy has already suggested some changes in this area in relation to service request types.

> C7. Section 5, s/<xs:complextContent>/<xs:complexContent>/1
[AJW] I will take a look.