Re: [Ecrit] Comments on the Location Hiding Requirements document

Hi Andres,

thanks for the comments and sorry for the long delay.

Andres Kütt wrote:
> Hi,
>
>     I have some comments as to the document at
> http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-location-hiding-requi
> rements-00.txt
>
> - 1.2. I don't think it is accurate to try to point out reasons why ISP/IAP
> would like to hide location information. The server load is just one aspect,
> but most probably they would be too greedy to give out valuable information
> for free. 
>   
Yep. I guess we should add something like.
"
In some other cases IAPs and ISPs may not want to make location 
information available without the ability to charge for it. This is a 
pure business decision.
"
> - REQ-C. That's a strange requirement. In case the call goes through VSP
> infrastructure they know (in case they trust LoST) that the URI is a genuine
> one and control the termination process. In case the call does not go
> through a VSP, there is really no way of knowing where the call ends up at.
> Or I don't understand the point of the requirement
>   
Here is the requirement:
"
Req-C: The VSP MUST be able to validate that a call purported to be an 
emergency call is being routed to a bona fide URI, which is denoted by 
being a URI in LoST for the designated emergency service.
"

This is a valid requirement and we had recently some discussions on the 
mailing list about along with a separate Internet draft, see
http://tools.ietf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt
Note that the requirement is more generic and not only applicable to 
"location hiding" but also important there.

In short, a VSP receives a call that is marked as an emergency call. 
This call would bypass many call handling steps (including authorization 
and charging).
Without additional steps the VSP cannot be sure that the call is indeed 
an emergency call or just a call to an arbitrary other entity.

> - Req-1. I would rather say that a relationship with IAP (the people who set
> up a rogue wifi AP) can not be assumed but a relationship with ISP could be
> feasible (although highly underireable) under certain circumstances. For
> example, it might be OK to state that emergency calls with that phone only
> work in a particular country where deals with a couple of major players
> could give sufficient coverage
>   
Here is the requirement:
"
   Req-1:  A business or trust relationship between an ISP and a VSP
      MUST NOT be assumed.
"

I believe we can assume that there is a relationship between the IAP and 
the ISP. Since the ISP is more important for the protocol operations we 
focus on it.

In some circumstances it is quite possible that the ISP and the VSP have 
a relationship. That's great. We cannot require for it to work 
everywhere that such a relationship exists. I believe that this is very 
important from an architectural point of view.

> - Thank you for Req-5, it's really important for folks like Skype
>   
With this requirement we align the solution better into the rest of the 
architecture.
For some location hiding solution approaches this works.

Here is the bad news: When it comes to unauthenticated emergency 
services this does not work anymore. See
http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-unauthenticated-access-00.txt

> - Req-9 is irrelevant as any operation before the call adds latency and it
> depends on the implementation whether or not that particular deduction adds
> significiant latency or not. I would rather say that the solution MUST seek
> to minimize the call setup time
>   
This requirement was created out of the strawman proposals we have seen. 
Some performed a trial-and-error alike approach.
A number of us believe that this is not a good thing.

> - Aren't Req-10 and Req-11 the same? If I have the PSAP/ESRP URL, don't I
> also have the dial string?
>   
Req10 and Req11 are related. In the base architecture we would like to 
allow an end host to determine the PSAP URI and the emergency service 
number ahead of time. We still want to maintain this functionality. This 
is essentially what these two requirements say.

> - Req-12 is ambiquous. What is minimal impact? In terms of performance,
> resource requirements, development, code complexity or what? UAs need to be
> updated anyway and it is unlikely that any solution drives any resource
> requirements through the roof. And when that happens, it's the problem of
> the UA vendor, not this standards body, I think.
>   
Are you right. This is a bit fuzzy. We see this location hiding 
functionality as an extension to the base architecture. Now, when the 
solution for location hiding is totally different than the rest of the 
emergency services story then we believe there is a problem. Hence, we 
would like to minimize the "impact" that is caused by the enhancements 
for the location hiding procedures. We would like also like to limit 
impacts to entities that benefit from this business decision.

Does that make sense to you?

> - Req-14. The same as REQ-C. The VSP needs to be able to trust the LoST
> service anyway 
>   
You are right. We should delete Req-14.

> - Req-15. What has it to do with locations? We already said that the calls
> might not be SIP calls which implies some sort of a proxy and the fact that
> the calls do not always originate directly from the UA. Which makes the
> issue of having or not having yet another proxy on the call's path
> irreleva
> nt
>   
Here is the requirement:

"
   Req-15:  Calls may reach a PSTN gateway, rather than the PSAP
      directly.
"

I am not sure anymore why this requirement is there.

> - Req-16. This is how Req-9 should be worded
>
>
>   
I added Req-16 to Req-9 since it further clarifies the performance issue.

Ciao
Hannes

> Yours,
> Andres Kütt
>
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>   

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit