RE: [Ecrit] LoST

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

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.

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.

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

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.priv.at/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]


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