RE: [Geopriv] Geopriv L7 LCP: New Requirement

Date: Sat Mar 10 2007 - 15:44:14 EST

Hi Hannes,

Indeed, the scenario I had in mind did not involve LIS-to-LIS in a DSL environment. It is the mobile access to the Internet scenario (3G cell phones / PDAs, PC cards, etc). The deployment I know involves only one entity as both the Internet Service Provider and the (mobile) Access Service Provider, therefore only one LIS is needed. Of course, the LIS-to-LIS issues would apply to deployments where those two providers would be different organizations (I don't know if such deployments actually exist).

In this mobile environment, the ability to specify how quickly a response is needed seems useful. Note that this makes more sense from an OBO perspective as well as if the mobile device itself tries to acquire its location just in time for an emergency call, for example.


-----Message d'origine-----
De : Hannes Tschofenig []
Envoyé : 10 mars 2007 15:00
À : Grenier, Jerome (6002687)
Cc :;;;
Objet : Re: [Geopriv] Geopriv L7 LCP: New Requirement

Hi Jerome, wrote:
> I agree with Barbara and would also add :
> - ability to request geo and/or civic location

Barbara previously said that geo-location does not make sense in the DSL
I guess you are pointing to a different environment. The question is
only: Is the LIS-to-LIS communication needed there as well?

> The "ability to specify how quickly a response is needed" would also be really helpful to us.
I don't think that this is useful for this particular application.

> Having a BCP (one or more) that recommends a syntax to express various identifier types for common protocols like SIP/PRES and HTTP would be great!

> Jérôme
> -----Message d'origine-----
> De : Stark, Barbara []
> Envoyé : 16 février 2007 10:05
> À : Andrew Newton
> Cc :; Otmar Lendl
> Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement
> I hate to break ranks, but if we could get the user part figured out
> (and I do think we would need some standardization, even if it's just a
> BCP), I kind of like this proposed solution. It has a certain simplicity
> to it.
> Since we've been pushing for these LISs to support LbyR, anyway, and
> this is really just LbyR, I don't see it as being a different protocol,
> yet again. This is a protocol we'd expect to be supported by a LIS in
> any case. The only change is that the URI may require careful parsing by
> the queried LIS, and the querier LIS needs to support LbyR queries in
> both directions.
> When I look at the functions in HELD (and RELO has a subset of these),
> and think through which of those functions would I really need for
> LIS-LIS or OBO, I come up with:
> - ability to request reference -- not needed, since, as pointed out,
> I've already got a perfectly good non-expiring reference; OBO querier or
> LIS doesn't need to ask for references to hand off to others, it should
> create its own references for that, as appropriate [aside: a
> non-expiring reference and a "LCP" are rather equal in the privacy
> debate from the OBO/LIS-LIS perspective.]
> - ability to assert location -- not needed for OBO or LIS-LIS; only an
> end device should be able to do this, if even that is allowed
> - ability to provide rules/profile for privacy -- not needed for OBO or
> LIS-LIS; only the device should be able to do this
> - ability to sign location -- if this is part of PIDF-LO, then this is
> independent of request mechanism
> - ability to request that location be signed -- I think we can assume
> that the location should be signed if it can be signed
> - ability to specify how quickly a response is needed -- this would be
> useful, but it may be possible to design around the issue
> - have I missed anything?
> Supporting URI formats other than SIP (e.g., HTTP) would still need to
> be worked. But that format would be common to all LbyR usages.
> This in no way removes the requirement for a device-to-LIS "LCP". I
> haven't read that into the suggestion at all.
> So, I think this idea warrants consideration.
> Barbara
> -----Original Message-----
> From: Andrew Newton []
> Sent: Thursday, February 15, 2007 3:51 PM
> To: Stark, Barbara
> Cc:; Otmar Lendl
> Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement
> On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote:
>> What is difficult, is figuring out a standard format for a URI user
>> part that would allow for all the variations in combinations of IDs
>> that exist, so that a standard format could be defined that would
>> cover all interconnection models. Section 8 of the NENA Location TID
>> ( provides 5
>> different examples of interconnection models, and the IDs that would
>> need to be used in each of these cases. In this document, scenario 1
>> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3
>> uses
>> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP
>> tunnel ID (source and destination) and PPPoE session ID. These are
>> just 5 possible examples, and should not be considered exhaustive.
>> Interconnection models are still evolving.
> Well, that's easily solved with a BCP for formulating URIs based on the
> ID. You don't need a new protocol or to conflate the LCP protocol with
> this functionality.
> -andy
> *****
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
> _______________________________________________
> Geopriv mailing list
> _______________________________________________
> Geopriv mailing list

Geopriv mailing list
Received on Sat, 10 Mar 2007 15:44:14 -0500

This archive was generated by hypermail 2.1.8 : Sat Mar 10 2007 - 15:42:13 EST