ecrit@ietf.org
[Top] [All Lists]

Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint

Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store
From: Henning Schulzrinne
Date: Sat, 14 Apr 2007 16:55:57 -0400

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).


Unfortunately, every resolver and forest guide would have to dereference. Resolvers and forest guides will be operated by numerous entities, including companies. There is no trust relationship between the Columbia LoST resolver (VSP, in my case) and the access provider. If any resolver can get the location information, you might as well hand it out to the client to begin with. Saves you the extra effort.

Thus, this is a non-starter.

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).

In many cases, the LoST resolver will be provided by the VSP, including non-traditional VSPs. Are you suggesting we restrict the LoST architecture to cater to this particular need?

I thought we agreed that the business practices of some ISPs should not burden the rest of the infrastructure?



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


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

<Prev in Thread] Current Thread [Next in Thread>