RE: [Geopriv] New Version Notificationfordraft-busin-geopriv-location-qos-req-00

From: Åke Busin ^lt;ake.busin@ericsson.com>
Date: Wed Nov 14 2007 - 02:26:29 EST

Martin, Lynn & all,

As also stated I earlier reply this draft intends to define requirements for an object the should be carried in a request for location information, sorry for not being clear on this. It is true the requirement describe a subset of the QoS element in MLP. These where chosen as they represent a stable and widely deployed set of QoS parameters in LBS.

Regarding the need and the permission to specify a requested QoS we need to bear in mind that there are and will be a wide range of users of location information. The discussion seems a bit stuck on a irresponsible user that request location 'for fun' and at no cost for the user. This draft is focused on the need of fairly complex applications that utilize location and where the need on e.g. Accuracy and latency are quite dymanic. The assumption is also that the Location Server do apply different positioning technologies depending on the requested QoS.

BR
Åke

-----Original Message-----
From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
Sent: den 14 november 2007 00:32
To: Moore, Lyn E; Winterbottom, James; Salvatore Loreto; geopriv@ietf.org
Cc: Miran Mosmondor; Åke Busin; Yufeng Jin
Subject: RE: [Geopriv] New Version Notificationfordraft-busin-geopriv-location-qos-req-00

Hi Lyn,

I think that this is going a little too far into the land of assumptions. I have to disagree with your point on QoS. We have to expect a wide range of users of location information. Currently, the primary users are actually specialist location services developers who most certainly know what they want and are cognizant of limitations.

Existing LBS systems already have the QoS capabilities described in the draft. I'm well familiar with the implementation of these sorts of functions; they are less onerous than it seems on first impressions.

Also note that these requirements almost directly describe the eqop element of MLP [1]. Functional parity with that specification is not a bad idea. I had similar goals for HELD [2], but other drafts were needed first [3].

So, for the authors of this document, can we please have some better explanation of what your intentions are? I'm afraid that the draft isn't clear enough on this point.

In particular, please clarify whether or not you see a Location Quality of Service Information Object as a part of a Location Object (as an indication of quality) or as a request object in some protocol. Personally, I see these as protocol parameters, but I can't make a judgment on the object since it isn't clear exactly how it would be used.

Cheers,
Martin

[1] <http://www.openmobilealliance.org/release_program/mls_v1_1.html>

[2] From a design perspective, these parameters were considered for inclusion in HELD, but we decided to limit the set of parameters to one: response time. That turned out to be controversial enough!
    The HELD design is consistent with the approach used in more recent LBS specifications. That is, the response time is the only binding parameter (hence the desire to get it in the base specification). Extra parameters like horizontal accuracy are more like guidelines; the server should attempt to meet them, but it shouldn't fail to produce a result if it doesn't. Instead, it indicates whether or not the target QoS parameter was met and the client is able to decide if it will accept the result. This would invalidate the QoS class of service parameter.

[3] <http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty>

> -----Original Message-----
> From: Moore, Lyn E [mailto:Lyn.Moore@team.telstra.com]
> Sent: Wednesday, 14 November 2007 9:14 AM
> To: Winterbottom, James; Salvatore Loreto; geopriv@ietf.org
> Cc: miran.mosmondor@ericsson.com; ake.busin@ericsson.com;
> yufeng.jin@ericsson.com
> Subject: RE: [Geopriv] New Version Notificationfordraft-busin-geopriv-
> location-qos-req-00
>
> Hello All
>
> I agree with James' comment on the accuracy and timing. Please
> explain...
>
> Everyone will want the most accurate and the quickest response when
> given the right to specify; regardless of whether it is necessary or
> not. Has anyone given any thought to how this would be achieved ?
> For most carriers providing LBS, this could involve multiple
> positioning technologies on multiple access networks with hundreds of
> different applications all requesting different levels of QoS. This
> is basically unmanageable, and I would doubt any carrier would
> implement it unless it became a regulatory requirement.
>
> Carriers providing LBS already have this information. Yes, it could
> be incorporated into the response for emergency calling and/or if the
> user has access to multiple positioning technologies and wishes to
> choose one. However, I believe it is the LBS provider who is in the
> best position to decide what degree of accuracy and timeliness is
> required for an LBS application. Again, this will be dependent on
> what positioning technologies are available to the user.
>
> Regards
> Lyn
>
>
> -----Original Message-----
> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> Sent: Wednesday, 14 November 2007 6:28 AM
> To: Salvatore Loreto; geopriv@ietf.org
> Cc: miran.mosmondor@ericsson.com; ake.busin@ericsson.com;
> yufeng.jin@ericsson.com
> Subject: RE: [Geopriv] New Version Notification
> fordraft-busin-geopriv-location-qos-req-00
>
> Hi Guys,
>
> Just a cursory read, but these values are being positioned as location
> request parameters to be included in a resulting PIDF-LO. Some of
> these parameters are already provided in HELD as part of the location
> request, others, such as horizontal accuracy for example and explicit
> in any geodetic response.
>
> Perhaps you can explain a little better why I would want to request a
> specific horizontal accuracy within a specific time inside a PIDF-LO?
>
> Cheers
> James
>
>
>
> > -----Original Message-----
> > From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com]
> > Sent: Tuesday, 13 November 2007 11:57 PM
> > To: geopriv@ietf.org
> > Cc: miran.mosmondor@ericsson.com; ake.busin@ericsson.com;
> > yufeng.jin@ericsson.com
> > Subject: [Geopriv] New Version Notification for draft-busin-geopriv-
> > location-qos-req-00
> >
> > we just submitted a requirement draft for a Location Quality of
> Service
> > (QoS) Information Object:
> >
> > http://tools.ietf.org/wg/geopriv/draft-busin-geopriv-location-qos-re
> > q-
> > 00.txt
> >
> > Comments and feedback appreciated.
> >
> > Salvatore Loreto
> >
> >
> > On Mon, 2007-11-12 at 04:03 -0500, IETF I-D Submission Tool wrote:
> > > A new version of I-D, draft-busin-geopriv-location-qos-req-00.txt
> has
> > been successfuly submitted by Salvatore Loreto and posted to the
> > IETF repository.
> > >
> > > Filename: draft-busin-geopriv-location-qos-req
> > > Revision: 00
> > > Title: Requirements for a Location Quality of Service
> (QoS)
> > Information Object
> > > Creation_date: 2007-11-11
> > > WG ID: Independent Submission
> > > Number_of_pages: 9
> > >
> > > Abstract:
> > > This document describes requirements for Location Quality of
> > > Service
> > > (QoS) Information Object. The Location QoS Information Object is
> > > used for expressing the geographic location QoS information in
> > > terms
>
> > > of specifying the required or desired level of quality, accuracy,
> > > response time, and age of requested Location Information. The
> > > resulting Location Information is conveyed in existing location
> > > formats wrapped in GEOPRIV privacy extensions to the Presence
> > > Information Document Format (PIDF-LO) [RFC4119].
> > >
> > >
> > >
> > > The IETF Secretariat.
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv
>
> ----------------------------------------------------------------------
> --
> ------------------------
> 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
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Wed, 14 Nov 2007 08:26:29 +0100

This archive was generated by hypermail 2.1.8 : Wed Nov 14 2007 - 02:26:44 EST