RE: [Geopriv] Geopriv L7 LCP: New Requirement

From: Dawson, Martin ^lt;>
Date: Sat Mar 10 2007 - 22:08:40 EST

Using civic for routing may work in the US where the MSAG is part of the legacy infrastructure. In other jurisdictions that I have spoken with, they would hate to have to develop this just for routing calls. As such a nominal geo associated with fixed wireline access points is also a requirement. Hence the need to be able to get both forms if possible. There is plenty of demand for a response time parameter and it is in the NENA requirements. It has a very valid application in doing location technology arbitration in wireless location measurement - it is used already in 2G and 3G location determination. There is nothing in IP Location that removes this requirement - your opinion not withstanding being valid as your opinion. Cheers, Martin -----Original Message----- From: Hannes Tschofenig [] Sent: Sunday, 11 March 2007 7:00 AM To: Cc:;;; Subject: 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 environment. 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! > > Ciao Hanes > 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 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2]

Geopriv mailing list
Received on Sat, 10 Mar 2007 21:08:40 -0600

This archive was generated by hypermail 2.1.8 : Sat Mar 10 2007 - 22:06:26 EST