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

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

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 25 Nov 2007 17:25:31 -0600

Thanks for the review Hannes,

I'll use your comments when writing the next version.  There are obviously a few (read: great many) things that need to be thought over, discussed and resolved.

Expanded examples seem to be high on your list.  I'll put the effort in for next time.

M

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Sunday, 25 November 2007 7:00 AM
> To: GEOPRIV
> Cc: Winterbottom, James; Thomson, Martin
> Subject: Review of draft-thomson-geopriv-held-capabilities-03
> 
> I read through

The name is an artifact of the document's evolution.  I missed the -00 draft cutoff, so a rename was out of the question this time.  I'll aim for a rename in the next version.

> Location (SUPL) works. I considered it to be a useful text.Why was it

Interworking with SUPL remains an option, however, for the purposes of the IETF architecture, GNSS can be solved by far simpler means.  Measurements can be conveyed using the measurements draft [draft-thomson-held-measurements] and assistance data using the GRIP protocol, as defined by a UNSW project [http://osgrs.sourceforge.net/].

This architecture is far simpler than SUPL, or more strictly, the subset that was in the original draft.  Also, we found that SUPL makes assumptions about a closed network architecture that don't apply here.

In other words, using ULP was a nice idea while nothing else adequate existed.  Now that we have better tools, the disadvantages outweighed the advantages.

> Navigation Satellite Systems.

Oops, my bad.

> * I would use complete XML examples rather than snippets. It is fine to

Can do.

> communication establishment might fail (e.g., due to NATs, firewalls,

Indeed, but the draft points out that these limitations could be acceptable.  Given the unique position of the LIS, I believe that the limitations of HTTP are less likely to get in the way.  For instance, the LIS is probably as close, or closer, to the Device than any SIP proxy would be; UPnP can punch though a single NAT/firewall easily enough; etc...
 
>   <url>held://192.0.2.55:46743/gnss/</url>

I'll certainly work on expanding the examples.  This is an obvious candidate.

> One could imagine that the LIS uses the SIP URI instead of the HTTP-based
 
Indeed - the callback problem is less of a problem for SIP.  I didn't want to get into that too deeply, since the semantics for SIP aren't as clearly defined and I didn't want to be the one to have to define them.

> for IETF related documents.

Would a reference to RFC 3688 address your concern?  I'm making something of assumption here, but I didn't think it was too much of a stretch.
 
> procedure when you think about a mechanism that always works.

A great deal of modern software seems to manage without too much trouble.  I'll draw a few pictures up and expand the examples.

> since it solves a couple of things in a nice way.

Yes, these are the semantics relating to SIP that would need to be defined.
 
> At this point in time I do not have good suggestions.

The good thing about responseTime is that it has the same meaning in all contexts.  A BCP might be in order, but I'd suggest that we'd want to get a bit more experience under our collective belts before we move on that one.
 
> mechanisms should be similar to LIS-to-LIS.

That seems sensible.  It is similar in essence, but not identical.  I'll try to find some points that I can either copy or reference.

> document with regard to the usage of the ID element.

That's something I didn't think of - the context ID could be used.  Thanks.  I'll do that.

> Hannes

------------------------------------------------------------------------------------------------
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv