Subject: RE: [GEOPRIV] draft-winterbottom-location-uri-01

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 21 Feb 2006 23:37:18 -0600

John,

It is clear from the lack of constructive feedback in your response that you do not regard by-reference favorably.

I have replied inline.

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Tuesday, 21 February 2006 7:44 AM
> To: Winterbottom, James
> Cc: [email-masked]
> Subject: Re: [GEOPRIV] draft-winterbottom-location-uri-01
> 
> A few comments on this draft:
> 
> On Jan 31, 2006, at 11:19 AM, Winterbottom, James wrote:
> 
> > An update to the Location Reference draft is available.
> >
> 
> section 1
> 
>     This document is intended to provide a guide to making a choice
>     between the two approaches, as well as providing some additional
>     information on providing LI by-reference.
> 
> It is not clear that a choice is required.  It may be that location
> by-reference has a different set of conditions under which it is
> useful.  Section 4 appears to identify a situation where by-value is
> better.
> 

Evidently, you have already made your own choice.

I could probably reword this to be a little more explicit, maybe something like: "This document provides an analysis of the advantages and disadvantages of the two approaches, so that the approach that is most appropriate for a given scenario can be selected."

> section 3
> 
> The claim that by-reference provides useful decoupling is not
> substantiated.

Yes it is.  Section 3 lists three advantages of this decoupling.

> A (hypothetical) presence subscription could provide
> locations as well as references.

Correct.  But I am beginning to suspect that we are talking about subtly different things when we talk about by-reference.  That might explain some of my later confusion.

> The location format similarly is
> independent of an additional de-referencing operation required by the
> proposal.  The presumption that Location Servers should translate
> between civic and geographic formats is a mistake because it could
> obscure which is the original and most precise format.  Errors in
> locating an address that are obvious to users of popular mapping web
> services should be avoided by the simple expedient of providing the
> best known location.  Location users can employ whatever degree of
> effort to get the level of precision in the translation appropriate to
> the application.

The presumption of translation is all yours.  At no point do we talk about translation between formats.  You assume that translation must occur, and do not entertain the possibility that both formats could be available to an acceptable level of precision.

In any case, the talk of format goes beyond the choice of civic vs. geodetic.  If a by-value approach is taken, all aspects of choice are taken from the recipient.  For instance, in geodetic includes CRS and uncertainty.

> section 4
> 
>     Using Location URIs places the control over when location is
>     generated with the LR.  Again, in a time-critical application this
>     also means that the LR may be forced to wait for location generation
>     to occur.
> 
> By-reference is neither necessary nor sufficient for the requester to
> control when location generation occurs.  A location server could incur
> the cost of a new generation when a request by-value occurs just as
> well, and a location server could de-reference without invoking a new
> location generation process.

The first part of this argument makes no sense to me.  I suspect it has something to do with the definition of "location server" and "by-value" that you are using.

As to sufficiency, I can see the case where you think the LR does not control when location is generated.  The LS responds to a request with a previously determined result that has been cached.  This isn't really a problem, more likely the LR would consider this an unexpected bonus.  However, all it takes is a flag in a request that indicates "please generate me a fresh location" in the request and the LR is granted control.

> section 4.1
> 
> Delegating responsibility from the host to a server in the network does
> appear to be the largest implication of by-reference.  It is worth
> considering whether this direction of shifting responsibility is
> consistent with the Internet model.  Moore's law, with its implied
> favor for ubiquitous rather than centralized computing, is expected to
> continue for another 10 years, based on technology in the pipeline.
> This is no time to abandon the guiding principle of the Internet that
> difficult decisions are best left to hosts at the edge of the network.

This would be a valid argument if processing capacity is the only factor involved.

> section 4.2
> 
> The implication that by-reference protects location values from threats
> of "open medium" is vacuous.  Before location is useful, the reference
> must be de-referenced to a value.  The requester then has the location
> (value) and can do anything it wants with it beyond the reach of
> whatever policy enforcement is in the location server.

Do you consider it necessary to follow up such a strong statement with asinine justification?  The LS is constrained to give LI to legitimate LRs only.  The LR has to be invested with some degree of trust that they will respect the privacy of the Target.  Bad judgment in constructing authorization policies has to be out of scope.

> section 5
> 
> The premise that references would be sufficiently stable where hosts
> are mobile is unjustifiable outside of legacy (pre-Internet) networks
> such as cellular phone service.  There is no reason to think that
> mobile Internet hosts would have their locations tracked inside the
> network.  
 
What has tracking got to do with having a stable reference?  The argument is relatively straightforward: A reference does not include location information, therefore it does not have to change when location changes.

> The best authority for a mobile host's location is the mobile
> host with GPS available and getting cheaper, and with Galileo coming
> online to overcome some of GPS's limitations.

(This is not the first time I have seen this statement, or something similar.  I am yet to see justification for the use of the unqualified use of "best".  Also, the implication that all mobile devices will have dual mode GPS and Galileo, seems a bit of a stretch.  In any case, if GPS were the ultimate location technology, then I doubt we would be seeing so many alternatives in the cellular world, even when those technologies are sometimes more costly and less precise.)

> section 6
> 
> No security advantages of by-reference over by-value are claimed, but
> fraudulent location information is considered.  It remains unclear what
> the threat is, and it appears that misrepresenting the validity of a
> reference is as problematic as that of the location value.

The Security Considerations section is for identifying potential security pitfalls and to document ways to address or mitigate those pitfalls.  Considerations related to by-value have been dealt with in some detail in other documents, so it was considered appropriate to discuss the potential problems of by-reference location.

> Summary: it is unclear that all the complexity and work of by-reference
> is justified by the ability to pass references through untrusted
> intermediaries.  The value of passing references through untrusted
> intermediaries is also unclear.

This summary is a conclusion about the by-value/by-reference argument.  Clearly you prefer by-value.  I'm not sure what exactly this is supposed to mean for the document.  If you mean to say that the document does not sufficiently clearly describe advantages and disadvantages, then please provide more specific instances and maybe we can address those.
------------------------------------------------------------------------------------------------
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