[Geopriv] Re: Review of draft-busin-geopriv-location-qos-req-01

[Salvatore Loreto <[e-mail]>]

Hi Hannes,

thanks for your thorough review and useful comments.

see our answers in line

ciao
Sal

On Sat, 2007-11-24 at 14:29 +0100, Hannes Tschofenig wrote:
> Hi Salvatore, Aeke, Yufeng, Miran,
> 
> thanks for the draft update and for considering feedback provided earlier.
> 
> I read through  draft-busin-geopriv-location-qos-req-01 again and have a 
> couple
> of comments.
> 
> 
> -- Technical
> 
>    The resulting Location Information is conveyed in existing location
>    formats wrapped in GEOPRIV privacy extensions to the Presence
>    Information Document Format (PIDF-LO) [RFC4119].
> 
> 
> [hannes] I guess you need to say more than that.
> Reading through the document I got the impression that you would want to
> extend the LCP and the LDP to carry the location QoS parameters in the
> request and then you want a PIDF-LO back that may contain additional
> information. For example, for the response time in the request there will
> not be a change in the PIDF-LO itself (expect for the method field since
> a different location determination technique was used, for example).


[Sal]  yes you are correct, our idea is to extend the LCP and the LDP to
carry the location QoS parameters in the request.
However, in the meanwhile, we don't see the necessity to modify PIDF-LO
itself, as the QoS achieved can be induced from the existing
information. For example, the age can be induced with timestamp, and the
accuracy can be induced from the uncertainty area (described with
geometry object).

> 
> 
> ### Accuracy:
> 
> You list two parameters for accuracy:
>    o  horizontal accuracy
>    o  vertical accuracy
> 
> The term "accuracy" has provided a lot of confusion in the past.
> Are you sure you mean accuracy or rather confidence. See the discussion in
> http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-uncertainty-00.txt
> regarding this topic.


[Sal]  
"accuracy", "uncertainty area" and "level of confidence" are relevant
concepts. 

Our intention is to use "accuracy" to describe the required level from
the application perspective, so that proper position determination
technology can be chosen by the location server. 
"uncertainty" and "confidence" is more suitable to described achieved
level (for example if a circle is returned in a PIDF-LO, it refers to
the uncertainty area),  however it's not so easy to describe the
required level with "uncertainty" and "confidence",  
how to describe the uncertainty area before the actual location is
retrieved? 
We can not simply include the "confidence" in the request as well, for
example, we can not just require "confidence over 95%" in the request
for an kid tracking application,  an answer with location information
that states "child is in Sweeden" fulfill the requirement of 95%
confidence, but possibly useless.


> 
> ### Response Time:
> 
> As an example, is the functionality in Section 6.1. of
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-03.txt
> what you have in mind?


[SAL] Well, a similar meaning. In mentioned draft it is defined as the
time that Device is prepared to wait for a response, while we defined it
as the time on Location Server in which it has to (or should) send a
response. 
The reason why we use this later definition is because we assume that
Location Server (or LIS in HELD case) cannot estimate how long will the
response travel through the network to the recipient (or Device).

> 
> 
> ### QoS class
> 
> To me this seems to correspond to the functionality listed in Section
> 6.2.1. of
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-03.txt
> regarding the "exact" attribute


[Sal]: Yes, it has similar functionality, but it's used to complement
different parameter.
It is referring only to the degree of adherence of location Type
parameter (geodetic, civic, any). 
We propose the QoS class to define the degree of adherence of horizontal
and vertical accuracy, response time, and age parameters.

> 
> ### Age
> 
> Regarding "age" we currently have only the following functionality defined:
> See Section 4.2 of
> http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-context-01.txt
> This section defines the concept of snapshot URIs, i.e., when the Target 
> (or an entity
> on his/her behalf) requests a location URI then it may express 
> additional constraints.
> In this case it means that the location URI reveals only the location of 
> the Target
> at the time when the location URI was created.
> 
> Reading through that part of the
> draft-winterbottom-geopriv-held-context-01.txt document I realized that 
> it wasn't
> described in such a way that one could use it with the LDP as well. This 
> is certainly
> not nice.

[Sal]  
"age" is used to limit the freshness of the location information
included in the response message, can be express like "Provide me the
current or last known location of the target if the known location
information is not older than ..." (as long as other QoS defined are
met)

> 
> I do wonder, however, what values for age would be reasonable. 
> Currently, we
> essentially only have two states, namely:
> a) Provide me the location of the Target at the time
> when the location URI was created.
> b) Provide me the current location of the Target.
> 
> You seem to desire more functionality. Could you be a bit more specific 
> of what you
> would like to see?
> 
> When the response is sent then it includes a timestamp field. This 
> timestamp in
> the PIDF-LO indicates when the PIDF-LO document was created. Is this 
> indication
> good enough for you?

[Sal] Yes


> 
> 
> 
> -- Editorial
> 
> * Replace all LPC with LCP in the document
> * Replace all LPD with LDP in the document
> 
> 
> FROM:
> 
>    Location QoS is described with a set of location QoS parameters
>    (i.e., positioning accuracy, location response time, etc.) and
> 
> TO:
>    Location QoS is described with a set of location QoS parameters
>    (e.g., positioning accuracy, location response time) and
> 
> [hannes]
> Delete the heading for Section 1.1.  Location QoS Information benefits
>    corresponding values.
> 
> 
>    1.  The recipient will not receive (and pay for) Location Information
>        that it is useless to him.  For example, the parent seeking his
>        children; if parent is unable to specify what accuracy it needs,
>        it may receive Location Information that states "child is in
>        somewhere in the circle area of 200 km in radius".  This
>        information is clearly quite useless for the parent.
>        Nevertheless, the recipient (parent) will probably have to pay
>        for this information.
> 
> [hannes]
> I suggest that you do not speak about payment. This turned out to be a 
> quite
> controversial topic.



[Sal]: what about the following paragraph reformulation?

   1.  The recipient will not receive Location Information
       that it is useless to him.  For example, the parent seeking his
       children; if parent is unable to specify what accuracy it needs,
       it may receive Location Information that states "child is in
       somewhere in the circle area of 200 km in radius".  This
       information is clearly quite useless for the parent.

> 
> [hannes]
> Combine Section 2.  Requirements Terminology,
> 3.  Terminology and 3.1.  Terms into one section.

[Sal]: OK we'll do in the next revision.

> 
> 
> 6.  Security Considerations
> 
>    Privacy and security considerations related to Location Information
>    are discussed in detail in [RFC3693].
>     
> [hannes] I would refer to the LCP, LDP and the PIDF-LO document with regard
> to the security considerations. Not to the GEOPRIV requirements document.

[Sal]: Ok, we can add references here to these documents instead (but
not to the PIDF-LO because we do not propose any extension to it – as
said several times before).

> 
> 
>    1.2)  The Location QoS Information MAY be optional.  This means that
>       a Location QoS Information MAY not be present in a LCP or DLP
>       request.
>    1.3)  Some of the Location QoS Information MAY be defined as
>       "extensions".  This means that the syntax or semantics of these
>       QoS Information is not fully defined in the basic Location QoS
>       Information definition, but their use may be limited to one or
>       more of the using protocols.
> 
> I think you should merge these two requirements into one.
> You are essentially saying that
> 
> "
> The Location QoS Information MUST be defined as an optional extension to
> LCP, LDP, and PIDF-LO.

[Sal]: we'll simply remove requirement 1.3

> "
> 
>    1.4)  The Location QoS Information MUST be extensible, allowing the
>       definition of new parameters or attributes.
> 
> I am not sure what you mean by that. LCP, LDP, PIDF-LO are extensible
> XML protocols or XML containers. What extension do you have in mind?
> 
[Sal] again, we don't want QoS in PIDF-LO.  
Initially, we thought that Location QoS Information can be carried by
any geopriv compliant “using protocol” (that does not have to be
extensible). 
Extensions that we have in mind were related i.e. to additional future
QoS parameters.


> 
>    1.1)  Geopriv MUST specify Location QoS Information, both in syntax
>       and semantics, that SHOULD be insert in the LCP and LDP request;
>       the Location QoS information MUST be supported and understood by
>       the Location Recipient and the Location Server.
> 
> It is not entirely correct to say GEOPRIV here since the requirements 
> refer to a
> specific protocol. Hence, it would be useful to list the protocol that 
> needs to
> have the extension defined. You may add this information to Req. 2.
> 
> Since the Location QoS Information is supposed to be an optional 
> extension one
> cannot mandate that it is understood by the Location Recipient and the
> Location Server.


[Sal]: this is maybe misinterpreted. 
The presence of the Location QoS Information is optional not the
extension – meaning, if Location QoS Information is not present in the
request, the Location Server may return Location Information with any
quality. 
If Location QoS Information is present, the Location Server must know
what this means and act accordingly. 
If Location Server does not understand this information it should return
an error indication. 
Maybe this is not so clear in the draft so we should add these sentences
to the Requirements chapter. 

>  
> 
> Ciao
> Hannes
> 



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