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

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:Hannes.Tschofenig@gmx.net]
> 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
> 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.

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.

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

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.

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

Oops, my bad.

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

Can do.

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

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

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

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
> URI of the end point.

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.

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

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.

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

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

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

Yes, these are the semantics relating to SIP that would need to be defined.

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

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.

> I some sense one could argue that the Target just runs a LIS and hence the
> 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.

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

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

> Ciao
> 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]