RE: [Ecrit] LoST

["Dawson, Martin" <[e-mail]>]

Hi Hannes,

The pidf-lo-profile spec, as far as I know, is inclusive of the shapes
defined for 3G. This makes it a comprehensive set as far existing LCS
infrastructure is concerned (I'm using LCS in its existing 3GPP context
here - not as a simile for LIS). This makes it the safest set to require
LoST support for. I really don't think there's any point in trying to
analyse the current, or anticipate the future, status-quo other than
that. Technology is emerging all over the place.

I agree with Henning; it's not necessary to require the LoST server to
actually utilize the shapes - that's an internal procedure. It's only
the external semantics that I'm concerned about as far as compatibility
issues go.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[e-mail]] 
Sent: Wednesday, 11 July 2007 8:59 PM
To: Dawson, Martin
Cc: Winterbottom, James; ECRIT
Subject: Re: [Ecrit] LoST

Hi Martin,

the question of the shape support is a question of deployment
environments.

For (most) WLANs / DSL / PacketCable environments civic location is 
probably the best choice. There are certainly some WLANs (moving train, 
bus, plane, ship, etc.) where civic location information does not make a

lot of sense but there a lot depends on the way how the WLAN is 
connected to another network.

For Wimax environment it depends on whether you talk about the work in 
the Wimax Forum or about the deployment of IEEE 802.16/802.16e networks 
in general. For the Wimax Forum no decision has been made with regard to

the usage of specific protocols, as far as I know. For IEEE 802.16 again

civic location is g good choice since it is essentially a replacement 
for DSL access. With IEEE 802.16e I could imagine that location hiding 
is again an important property for them.

For 3GPP / 3GPP we are talking about an environment where location 
hiding is probably most appropriate (when it comes to the information 
that is made available to the end host). That's what we learned in 
previous discussions.

For GPS usage at the end host only you are certainly right that circles 
& ellipse is a good choice. The big question is here:
* is it a big issue to translate them to a point
* does it introduce big error rates
Please also note that we are talking about emergency call routing in the

context of LoST and not about dispatch. To approximate a circle with a 
radius of 3 meters with a point might not be a big problem.

Does this classification make sense to you?

This raises a related question: What location shapes would you introduce

to LoST now that really require to be there (and where it cannot wait a 
little longer)?

Ciao
Hannes

Dawson, Martin wrote:
> Hi again,
>
> Certainly - let the group decide... just casting my vote/opinion.
>
> I don't know why it matters how many GPS devices use SUPL... I'm just
> saying that a LIS will return a geo-shape for whatever reason. It may
> not even use GPS; it might be serving a WiMAX access and be using
signal
> timing and base station location to determine the location/shape. The
> device doesn't know or care. The point is that if the LIS is using the
> PIDF-LO profile requirements to select a shape to provide, the device
> might end up with one that the LoST server doesn't support unless LoST
> is specified as also supporting at least these shapes.
>
> If the question was just btw - I'd have to say that most GPS devices
> don't use SUPL... I think most GPS devices are autonomous at this
stage.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Hannes Tschofenig [mailto:[e-mail]] 
> Sent: Wednesday, 11 July 2007 7:55 PM
> To: Dawson, Martin
> Cc: Winterbottom, James; ECRIT
> Subject: Re: [Ecrit] LoST
>
> Hi Martin,
>
> Dawson, Martin wrote:
>   
>> Thanks Hannes,
>>
>> Yes, I'm suggesting that since the profile spec is about to go RFC,
>>     
> that
>   
>> the LoST spec might just as well reference it so we have a consistent
>> ecology of specs. I think that having a subsequent spec make the
>>     
> profile
>   
>> mandatory would only be an issue if it came after LoST was
>>     
> implemented.
>   
>> On the other hand, if we assume it will happen before LoST is
>> implemented, then why not just include the requirement now.
>>   
>>     
> I would like to let the group decide.
>
>   
>> With respect to GPS - a LIS (LCS, whatever) could utilize any
suitable
>> protocol, including SUPL, to do GPS interactions with the client - it
>> still casts the result as a PIDF-LO in the response. I'm not really
>> thinking of the situation where the device does a GPS fix or gets it
>> from some other non-PIDF-LO source. In that case, I'd certainly agree
>> that the device may as well transcode it into the basic form. I'm not
>> really concerned about that situation.
>>
>>   
>>     
> I know about this feature in SUPL.
> Still, do most GPS devices today use SUPL?
>
>
> Ciao
> Hannes
>
>   
>> Cheers,
>> Martin
>>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[e-mail]] 
>> Sent: Wednesday, 11 July 2007 7:33 PM
>> To: Dawson, Martin
>> Cc: Winterbottom, James; ECRIT
>> Subject: Re: [Ecrit] LoST
>>
>> Hi Martin,
>>
>> Dawson, Martin wrote:
>>   
>>     
>>> Hi Hannes,
>>>
>>> This seems a bit bogged down in the here and now... A LIS for almost
>>>     
>>>       
>> any
>>   
>>     
>>> access technology, with or without GPS, could produce a geo-shape as
>>>       
> a
>   
>>> consequence of the location-determination technique it employs. What
>>> 3GPP may be thinking now doesn't seem particularly pertinent.
>>>   
>>>     
>>>       
>> True. A LCS (this is the correct terminology now) can indeed produce
a
>>     
>
>   
>> PIDF-LO with the Geo-Shapes format.
>>
>> When you use a GPS receiver today (and probably for a long time) then
>>     
> it
>   
>> does not produce a format in XML format since there is just no LCP 
>> involved.
>>
>>   
>>     
>>> There's already a pdif-lo-profile draft ([sic] is the spelling ever
>>> going to get corrected btw or is a title immutable?) that states
what
>>> shapes should be used and defines what the LIS clients can expect to
>>> receive.
>>>   
>>>     
>>>       
>> We decided not to change the file name. When the document gets
>>     
> published
>   
>> as RFC then the filename does not matter anway.
>> Btw, we recognized the wrong spelling with version -04 or so.
>>
>>   
>>     
>>> While I accept that a LoST implementor could add support for that
>>> profile, as long as it is optional to do so, the client cannot be
>>>       
> sure
>   
>>> that anything other than a point will be supported.
>>>     
>>>       
>> A new document can also say that the new location profile is
mandatory
>>     
>
>   
>> to implement. Do you think that will be a problem?
>>
>>   
>>     
>>>  This adds the dual
>>> issue of making the client always convert to a point form and/or
>>> eliminating the prospect of LoST servers being able to do more
>>> sophisticated routing based on weighted coverage by uncertainty.
>>>
>>> Rather than invite the compatibility issue at a later date, wouldn't
>>>     
>>>       
>> it
>>   
>>     
>>> be more prudent just to add the requirement now?
>>>   
>>>     
>>>       
>> No doubt that we could add an additional location profile right now.
>>
>> I am just repeating what we agreed earlier in the working group on
>>     
> this 
>   
>> particular issue. If the working group now thinks that this is a
>>     
> problem
>   
>> then we should re-consider it. I just want to open-up previously
>>     
> closed 
>   
>> or postponed issues too quickly.
>>
>>
>> Ciao
>> Hannes
>>
>>   
>>     
>>> Cheers,
>>> Martin
>>>
>>> -----Original Message-----
>>> From: Hannes Tschofenig [mailto:[e-mail]] 
>>> Sent: Wednesday, 11 July 2007 6:55 PM
>>> To: Winterbottom, James
>>> Cc: ECRIT
>>> Subject: Re: [Ecrit] LoST
>>>
>>> Hi James,
>>>
>>> Winterbottom, James wrote:
>>>   
>>>     
>>>       
>>>> Hi Hannes,
>>>>
>>>> That makes perfect sense.
>>>>
>>>> The issue that I am most concerned about is the limitation in the
>>>>     
>>>>       
>>>>         
>>> shape
>>>   
>>>     
>>>       
>>>> representation in the basic location profile. As it currently
stands
>>>>       
>>>>         
>> I
>>   
>>     
>>>> cannot use standard GPS related shapes, my end-point has to
>>>>         
> interpret
>   
>>>> location and put into a profile. This is incompatible with a large
>>>> number of solutions deployed today on which many deployments will
be
>>>> based, at least initially. I strongly urge this WG to reconsider
>>>>         
> this
>   
>>>> restriction and include circle, and ellipse at a minimum.
>>>>   
>>>>     
>>>>       
>>>>         
>>> Some time back we also discussed this issue and the conclusion was
>>>       
> the
>   
>>>     
>>>       
>>   
>>     
>>> following:
>>> * Let us build a mechanism in there to have a mechanism to extend
the
>>>       
>
>   
>>> location shapes.
>>> * Let us specify simple location shapes first.
>>>
>>> I know that there is this limitation with geodetic shapes and a
>>>     
>>>       
>> separate
>>   
>>     
>>> location profile would be needed to address GPS and the cellular
>>>     
>>>       
>> world.
>>   
>>     
>>> On the cellular aspect we also had a discussion with the 3GPP. There

>>> they are currently not using LoST at the end point since they are 
>>> focusing on a different architecture (see 
>>>
>>>     
>>>       
>
http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview-
>   
>>   
>>     
>>> 00). 
>>> Even if they would use LoST at the end point they most likely want
to
>>>       
>
>   
>>> hide the location information of the end point or to make use of 
>>> information like cell ids (as recorded in the issue tracker a while
>>>     
>>>       
>> ago:
>>   
>>     
>>> http://www.tschofenig.priv.at:8080/lost/issue16).
>>>
>>> Now, everything boils down to the question of GPS. Since GPS
produces
>>>       
>
>   
>>> data in a format that is not PIDF-LO alike we can already assume
that
>>>       
>
>   
>>> the end host has to understand the format. It can now encode it in 
>>> different ways. In previous discussions a couple of us wanted to add
>>>       
> a
>   
>>>     
>>>       
>>   
>>     
>>> polygon as a location profile to the LoST document since it would
>>>       
> also
>   
>>>     
>>>       
>>   
>>     
>>> address the location hiding requirement. Since this issue came also
>>>       
> up
>   
>>>     
>>>       
>>   
>>     
>>> in the location hiding context we postpone this topic entirely.
>>>
>>> Hence, it is up to us to come up with a location profile that
>>>       
> supports
>   
>>> * a circle
>>> * an ellipse
>>> * a polygon,
>>> * a combination of the above
>>> * cell-ids
>>> if we think there is a need todo so.
>>>
>>> Ciao
>>> Hannes
>>>
>>>   
>>>     
>>>       
>>>> Cheers
>>>> James
>>>>
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> -----Original Message-----
>>>>> From: Hannes Tschofenig [mailto:[e-mail]]
>>>>> Sent: Wednesday, 11 July 2007 4:58 PM
>>>>> To: Winterbottom, James
>>>>> Cc: ECRIT
>>>>> Subject: Re: [Ecrit] LoST
>>>>>
>>>>> Hi James,
>>>>>
>>>>> let me pick a concrete example: LoST server discovery.
>>>>> Currently, we have specified the usage of DHCP and DNS. Only the
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> former
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> allows to discover the LoST server in the access network. I am,
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>> however,
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> aware of the work on HELD discovery, see
>>>>>
>>>>>         
>>>>>           
>> http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery-
>>   
>>     
>>>>> 01.txt,
>>>>> that aims to discover a HELD server in the access network using
DNS
>>>>> mechanisms.
>>>>>
>>>>> Now, even though the current LoST draft does not describe how to
>>>>> discover a LoST server using DNS in the access network that can be
>>>>> extended later when the above document is generalized (which I
>>>>>           
> think
>   
>>>>> would be a good idea).
>>>>>
>>>>> Does that make sense to you?
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>> Winterbottom, James wrote:
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>>>> Hi Hannes,
>>>>>>
>>>>>> What exactly do you mean by postponed?
>>>>>>
>>>>>> Cheers
>>>>>> James
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>       
>>>>>>         
>>>>>>           
>>>>>>             
>>>>>>> -----Original Message-----
>>>>>>> From: Hannes Tschofenig [mailto:[e-mail]]
>>>>>>> Sent: Wednesday, 11 July 2007 5:58 AM
>>>>>>> To: ECRIT
>>>>>>> Subject: [Ecrit] LoST
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> during the WGLC we have received a number of comments. Then, we
>>>>>>>
>>>>>>>         
>>>>>>>           
>>>>>>>             
>>>>>>>               
>>>>>> delayed
>>>>>>
>>>>>>       
>>>>>>         
>>>>>>           
>>>>>>             
>>>>>>> the completion of the work because of the location hiding
>>>>>>>         
>>>>>>>           
>>>>>>>             
>>>>>>>               
>>>> discussions.
>>>>   
>>>>     
>>>>       
>>>>         
>>>>>>> Now, you can find the latest version of the document at:
>>>>>>>
>>>>>>>
>>>>>>>         
>>>>>>>           
>>>>>>>             
>>>>>>>               
>
http://www.tschofenig.com/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los
>   
>>   
>>     
>>>   
>>>     
>>>       
>>>>   
>>>>     
>>>>       
>>>>         
>>>>>> t-
>>>>>>
>>>>>>       
>>>>>>         
>>>>>>           
>>>>>>             
>>>>>>> 06.txt
>>>>>>>
>>>>>>> We have also updated the DHCP-based LoST discovery draft (based
>>>>>>>               
> on
>   
>>>>>>>         
>>>>>>>           
>>>>>>>             
>>>>>>>               
>>>> the
>>>>   
>>>>     
>>>>       
>>>>         
>>>>>>> comments we received from the DHC working group). The document
>>>>>>>               
> can
>   
>>>>>>>         
>>>>>>>           
>>>>>>>             
>>>>>>>               
>>>> be
>>>>   
>>>>     
>>>>       
>>>>         
>>>>>>> found here:
>>>>>>>
>>>>>>>
>>>>>>>         
>>>>>>>           
>>>>>>>             
>>>>>>>               
>
http://www.tschofenig.com/svn/draft-tschofenig-dhc-lost-discovery/draft-
>   
>>   
>>     
>>>   
>>>     
>>>       
>>>>   
>>>>     
>>>>       
>>>>         
>>>>>>> ietf-ecrit-dhc-lost-discovery-02.txt
>>>>>>>
>>>>>>> Now, here is the unfortunate news: It seems that we did not
>>>>>>>               
> submit
>   
>>>>>>>         
>>>>>>>           
>>>>>>>             
>>>>>>>               
>>>> the
>>>>   
>>>>     
>>>>       
>>>>         
>>>>>>> LoST draft :-(
>>>>>>> Everyone was assuming that someone else is going to submit it.
>>>>>>>
>>>>>>> Ciao
>>>>>>> Hannes
>>>>>>>
>>>>>>> PS: James has recently sent a number of comments. Some of them
>>>>>>>               
> got
>   
>>>>>>> reflected in the document (namely the editorial onces). Others
>>>>>>>               
> got
>   
>>>>>>> intentionally postponed since we discussed them already in the
>>>>>>>         
>>>>>>>           
>>>>>>>             
>>>>>>>               
>>>> past.
>>>>   
>>>>     
>>>>       
>>>>         
>>>>>>> _______________________________________________
>>>>>>> Ecrit mailing list
>>>>>>> [e-mail]
>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>>>>>
>>>>>>>         
>>>>>>>           
>>>>>>>             
>>>>>>>               
>>>>>>       
>>>>>>         
>>>>>>           
>>>>>>             
>
------------------------------------------------------------------------
>   
>>   
>>     
>>>   
>>>     
>>>       
>>>>   
>>>>     
>>>>       
>>>>         
>>>>> ------------------------
>>>>>     
>>>>>       
>>>>>         
>>>>>           
>>>>>> 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]
>>>>>>
>>>>>>
>>>>>>       
>>>>>>         
>>>>>>           
>>>>>>             
>>>>     
>>>>       
>>>>         
>
------------------------------------------------------------------------
>   
>>   
>>     
>>> ------------------------
>>>   
>>>     
>>>       
>>>> 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]
>>>>
>>>>   
>>>>     
>>>>       
>>>>         
>>> _______________________________________________
>>> Ecrit mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/ecrit
>>>
>>>
>>>     
>>>       
>
------------------------------------------------------------------------
>   
>> ------------------------
>>   
>>     
>>> 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]
>>>
>>>   
>>>     
>>>       
>>
>>     
>
------------------------------------------------------------------------
> ------------------------
>   
>> 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]
>>
>>   
>>     
>
>
>
------------------------------------------------------------------------
------------------------
> 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]
>
>   


------------------------------------------------------------------------------------------------
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]


_______________________________________________
Ecrit mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ecrit