|
|
3GPP approaches this in a different way - one which (I think) we could
parallel, as shown in the following diagrams:
Proposal:
- Define a new function which handles location dereferencing and
supports lost queries (this seems to me to be somewhat similar to an LRF
in 3GPP, since an LRF goes and gets loc + routing).
- LoST doesn't need to change, (except maybe in the validation bits -
which I still don't understand).
- run by the Access Network (therefore Access Network has controls)
+------+ +------+
| LS | | LoST |
| | | |
| | | |
+------+ +------+
\ /
\ LCP (n/c) / LoST Protocol (n/c)
\ /
+------+
| ULS | New, URI-Loc-Server - logically in Access
Network
| |
| |
+------+
/
/
/
+------+ +------+
| UA | | P1 |
| |-----------| |
| | | |
+------+ +------+
1. Endpoint accessed model
+------+ +------+
| LS | | LoST |
| | | |
| | | |
+------+ +------+
\ /
\ LCP (n/c) / LoST Protocol (n/c)
\ /
+------+
| ULS | New, URI-Loc-Server - logically in Access
Network
| |
| |
+------+
\
\
\
+------+ +------+
| UA | | P1 |
| |-----------| |
| | | |
+------+ +------+
2. Proxy accessed model
Summary:
Neither of these scenarios preclude LbyV direct UA or Proxy interaction,
if desirable, and (in my mind) don't impact (much) existing protocols.
-roger marshall.
>-----Original Message-----
>From: Richard Barnes [mailto:rbarnes@xxxxxxx]
>Sent: Friday, April 13, 2007 9:45 AM
>To: Rosen, Brian
>Cc: geopriv@xxxxxxxx; ecrit@xxxxxxxx
>Subject: Re: [Ecrit] Not-so-grand compromise on how to do
>endpoint centricLCP without giving away the store
>
>Brian,
>
>I think that you're right that provision of location by
>reference is a use case we need to support.
>
>URI validation will be useful in either case (LbyR or LbyV),
>and it seems like a natural extension to make to LoST:
>Validating that a given URI is a PSAP URI is like a reverse
>DNS lookup. Normal DNS queries map
>names->addresses (A+ records); reverse DNS queries map addresses to
>names (*PTR records). Likewise, LoST queries map locations (+service
>URNs) to URIs; a "reverse LoST" query could map a URI to a
>service area and a service URN. There's probably even simpler
>approaches, maybe via some form of NAPTR or ENUM lookup.
>
>As far as getting the endpoint the results of a LoST query based on an
>LbyR: Your suggestion is good, but it has the problem that
>the access network doesn't really know what to fill in for the
><service/> element of the LoST query. It could request all of
>the services available, but that would require a second LoST request.
>
>I would suggest that a more elegant solution (and one that
>deals better with the "unknown <service/>" problem) would be
>to extend LoST to handle location by reference. It wouldn't
>be a complicated change to LoST, just another location
>profile. Realizing that this has been discussed in the past,
>I scanned through the archive and found two main arguments
>against LoST doing LbyR:
>
>1. Dereference access control
>In order to do the LoST lookup, a LoST server would have to be
>allowed to dereference the location reference. Given that
>most of the LoST infrastructure (e.g. the trees) is pretty
>static, it doesn't seem difficult to provide authentication
>credentials for LoST servers and require that they be able to
>dereference (just like PSAPs).
>
>2. Extra time/complication
>It's correct that it would not be feasible for every LoST
>server involved in an LbyR-based query to dereference the
>location reference.
>However, this can be avoided if the resolver doing the
>recursive queries is allowed to do a dereference, since it can
>then just include the location by value in subsequent queries.
> This may cover most cases, e.g., if a local LoST resolver is
>provided by the access network (as is often the case with DNS).
>
>There's a lot of overlap between LoST/LbyR and what you
>propose. If the access network provides a resolver, then the
>two are essentially the same, except that if LoST/LbyR is
>used, then the client sends an extra query. However,
>extending LoST seems to maintain a better separation of the
>location configuration and mapping functions.
>
>Humbly submitted,
>--Richard
>
>
>
>Rosen, Brian wrote:
>> In the Emergency Services SDO Coordination workshop, a familiar
>> discussion took place: how does location get provided for emergency
>> calls? The real issue is revenue. Access networks have location.
>> They may be willing to (or may be regulated to be required
>to) provide
>> location for emergency calls. However, they are not willing to give
>> it away for free for other uses. The issue with that is how we
>> support calling networks that don't have relationships with access
>> networks, i.e. the Skype situation. How is location provided such
>> that a Skype emergency call can be placed, but the access
>network can
>> restrict what else may be done with the location it provides?
>>
>> We have been wrapped around the axle on this for, dare I say, years.
>>
>> So, I think Barbara Stark first described this, and it needs some
>> work, but suppose that, as an option, an access network could supply:
>>
>> 1. A reference to location
>>
>> 2. The results of a LoST query on the location value (viz, PSAP URI
>> and local dialstring)
>>
>> With this, an endpoint could recognize an emergency call and start
>> routing it to the right PSAP. The LIS would agree to
>dereference for
>> PSAPs, but could restrict other uses of location.
>>
>> Hannes points out that we need one more thing: the calling
>network has
>> to be able to validate that the PSAP URI really is a PSAP
>URI so that
>> charging (emergency calls generally are free) is protected.
>We need a
>> mechanism for them to do that.
>>
>> Perhaps we include in the LoST return a country code for a
>query with
>> a geo. We add a new operation to LoST that takes a service,
>a country
>> code and a PSAP URI and returns yes/no validation ("Yes,
>that URI is a
>> valid URI for that service in that country").
>>
>> What would we need to do to make this happen?
>>
>> We need extensions to LCPs or some new protocol that returns an LbyR
>> and the LoST results. I wonder if this is just more HELD work.
>>
>> We need the PSAP URI validation.
>>
>> Again, this is optional. The access network may well give
>up an LbyV.
>> It may give up an LbyR that it will dereference for the
>endpoint. The
>> access network may have a relationship with the calling network such
>> that the endpoint need not be involved.
>>
>> The PSAP URI validation is actually useful without this idea,
>> especially when location is an LbyR. Instead of having to have the
>> calling network dereference, and then do a LoST query to
>validate, it
>> can just do this PSAP URI validation.
>>
>> Would this solve our problem? Would access carriers concerned about
>> revenue issues with "giving away" location to it's subscribers be
>> willing to provide LbyR dereferenceable by PSAPs (again remembering
>> that the access network are local to the PSAPs) as well as
>LoST query
>> services to their endpoints? Would this address the concerns raised
>> by Deutsche Telecom on this issue?
>>
>> Let me be very clear that I think this is an ugly solution. I think
>> that everyone will be much better off if endpoints knew where they
>> were, and apps could take advantage of that. I think we'll
>get there.
>> I think tying location configuration with the LoST query is a bad
>> idea. I think using LbyR for emergency calls is a bad idea.
>>
>> But I can live with it.
>>
>> Brian
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@xxxxxxxx
>> https://www1.ietf.org/mailman/listinfo/ecrit
>>
>>
>
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@xxxxxxxx
>https://www1.ietf.org/mailman/listinfo/ecrit
>
The information contained in this message may be privileged and/or
confidential. If you are not the intended recipient, or responsible for
delivering this message to the intended recipient, any review, forwarding,
dissemination, distribution or copying of this communication or any
attachment(s) is strictly prohibited. If you have received this message in
error, please so notify the sender immediately, and delete it and all
attachments from your computer and network.
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|