|
|
Hi James,
Winterbottom, James wrote:
Hi Hannes,
The concern I have is that GPS is not only cellular.
I know that GPS has nothing todo with cellular systems.
I haven't said that.
It is being used in WiFI and will be used from the get go in WiMAX.
The only profiles that will be mandatory to support are those in the
basic LoST specification, so the decision is generally unacceptable from
a deployment perspective.
You can also define extensions that a mandatory to implement in another
document.
I don't agree with the assessment below either.
With with point in particular?
I can easily see that LIS could provide a PIDF-LO to me that I have
provided satellite pseudo-ranges for.
Let's assume the GPS that is being used today. There is no PIDF-LO in use.
So again I remain unconvinced by
this debate. It is far simpler to interpret the ellipse and circle types
than a polygon, and to be frank from an end-point or measure location
perspective far more likely to be provided.
That's fine since we don't have a polygon in the LoST document either.
Ciao
Hanes
-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx]
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.com: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:Hannes.Tschofenig@xxxxxxx]
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:Hannes.Tschofenig@xxxxxxx]
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
Ecrit@xxxxxxxx
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]
_______________________________________________
Ecrit mailing list
Ecrit@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ecrit
|
|