[Geopriv] Review of draft-thomson-geopriv-held-capabilities-03

[Hannes Tschofenig <[e-mail]>]

I read through 
http://tools.ietf.org/html/draft-thomson-geopriv-held-capabilities-03

This work is important since it describes how to align the GEOPRIV work 
on HELD with the
OMA work with SUPL

A few comments:

* The document is at some places a bit difficult to understand (probably 
because of some of the
selected terms). I would even argue that the document title is 
misleading. Obviously, one has to
provide an capability exchange -- already the basic HELD document should 
contain an
extensibility story. The main aspect, however, in this document is not 
about the capability exchange
but rather about the fact that the LIS contacts the Target in certain 
cases.

* A previous version of the document showed how the interworking with 
Secure User Plane
Location (SUPL) works. I considered it to be a useful text.Why was it 
removed?

* With the first occurrence you should spell out GNSS as Global 
Navigation Satellite Systems.

* I would use complete XML examples rather than snippets. It is fine to 
omit the HTTP part.

* Section 4.1 indicates a limitation of the proposed mechanism when the 
communication
from the LIS is initiated using HTTP. The LIS needs to initiate a 
protocol interaction
towards the end host. Obviously, one can easily imagine environments 
where this
communication establishment might fail (e.g., due to NATs, firewalls, etc.)

I am also not quite sure what the following paragraph actually means:

   The capabilities described in this document both rely on the Device
   providing a URL.  The LIS is able to dereference this URL in order to
   retrieve information from the device.  The "url" element is included
   by the Device to indicate where (and how) the information is
   retrieved.

I believe that the document relies on the fact that the LIS has to have 
the address of the
Target in order to contact it. The above paragraph is a bit hard to 
understand without a
specific example. I assume that this would be the specific XML element 
we are
talking about:

  <url>held://192.0.2.55:46743/gnss/</url>

One could imagine that the LIS uses the SIP URI instead of the HTTP-based
URI of the end point.

* Section 4.2 talks about how URIs/URNs are used to indicate the 
registration of
the capability. No guidelines are provided what is required to request 
new URNs
for IETF related documents.

* Section 5 defines a capability that allows the LIS to retrieve 
location information
stored at the Target. Hence, when location information is needed from 
the Target
and requested from the LIS then the LIS would ask the Target to get it.

I an easily imagine how this works with a sip,sips, and pres URI. For 
HTTP the
above-mentioned drawbacks exist.

I would add a few examples to this section to illustrate better how the 
entire
procedure works. I would add the HELD message exchange between the
Target and the LIS (using the capability extension). Then, I would add
a request that comes from outside and then the LIS uses the URI to get 
in touch
with the Target.Then, the LIS executes the necessary procedures to 
retrieve the
location information from the Target. I can imagine that this is a quite 
complicated
procedure when you think about a mechanism that always works.

In some sense it would have been interesting to have the functionality of
http://tools.ietf.org/html/draft-schulzrinne-geopriv-locationref-00
since it solves a couple of things in a nice way.

* "Location Measurement Capability"

The responseTime parameter may appear in four different contexts:
 -- this document (in relationship with the measurement draft; for the 
request from
     the LIS to the Target)
 -- HELD base document (for the interaction with the LIS)
 -- Dereferencing protocol (from the Location Recipient to the LIS).
 -- HELD base document together with the identity extension (for LIS2LIS 
interaction)

I wonder whether there isn't a chance for making a few simplifications.
At this point in time I do not have good suggestions.

I some sense one could argue that the Target just runs a LIS and hence the
mechanisms should be similar to LIS-to-LIS.

* Security

The draft says:

   When the LIS contacts the Device, the Device SHOULD authenticate the
   LIS using the same credentials provided by the LIS after discovery
   (see [I-D.thomson-geopriv-lis-discovery]).  This ensures that other
   entities are not able to retrieve location information or
   measurements from the Device.  Requiring client authentication on a
   TLS connection and then matching this authentication to the server
   authentication provided by the LIS can achieve this.

I think that the reference to the LIS discovery procedure in this
paragraph is wrong. I think it should rather point to context
document with regard to the usage of the ID element.

Ciao
Hannes



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