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

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 24 Nov 2007 14:29:19 +0100

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

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

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

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

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

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?

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

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

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.

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

   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?

   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.

Ciao
Hannes

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

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 30 Nov 2007 15:01:12 +0200

Hi Hannes,

thanks for your thorough review and useful comments.

see our answers in line

ciao
Sal

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

> http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-uncertainty-00.txt

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

> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-03.txt

[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).

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

> described in such a way that one could use it with the LDP as well. This 

[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)

> the PIDF-LO indicates when the PIDF-LO document was created. Is this 

[Sal] Yes

> I suggest that you do not speak about payment. This turned out to be a 

[Sal]: what about the following paragraph reformulation?

   1.  The recipient will not receive Location Information

> 3.  Terminology and 3.1.  Terms into one section.

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

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

> The Location QoS Information MUST be defined as an optional extension to

[Sal]: we'll simply remove requirement 1.3

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

> cannot mandate that it is understood by the Location Recipient and the

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