Subject: [Geopriv] Comments on draft-barnes-geopriv-lo-sec-05 (part 2: Section 3)

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 12 Mar 2009 00:58:26 -0500

Author conglomerate,

...continuation from review part 1.

==Review highlights

The concept that a LG decides to become an LS by distributing location information is a useful one.  One that is undermined by the fact that LR only appears in the end - but there is no way to determine that any particular "end" is final.  It would be better to keep the LR role where it was previously - as any entity that receives location information.  That way, the LR can similarly decide to become an LS.

==Details

Section 3.

The positioning protocol in this diagram is not necessary to discussion on privacy.  After all, it's only an optional part of the process - there might be no protocol involved.  See previous discussion.

Section 3.1

The Location Generator might be responsible for generating the bulk of a location object, but it can't complete the object unless a Rule Maker advises it on usage rules.

It would help to re-iterate here that the taxonomy focuses on methods that determine the location of a Device (referred to hereafter as Target) more so than the location of a person.

Section 3.1.1

Network-based: I don't know who the second-party is, so using "third-party" might be confusing.  Perhaps you are just referring to a Location Generator that is separate to the Target Device.

It might be worth noting that many network-based methods rely to some extent on the Device.  Not all do, but some require that the Device hold up its end by providing signal strength measurements or timing information of its own.  

Assistance is not just information that enables the computation of location based on measurements (notice lack of hyphen).  Assistance also enables the generation of measurements.  This is an important part of device-assisted A-GNSS, for instance.

s/In fixed networks/In wired networks/ - c.f. fixed wireless

s/provides the assistance server with data such as pseudo-ranges/provides the Location Generator with measurement results/ - I'll let you sort of the consequences of that bad edit

There are a few missing definitions: pseudo-ranges is probably not a good term to use in any case, GNSS measurements is more appropriate since the measurement includes a mite more than code phase measurements.  I tend to use pseudo-range when I'm being lazy ;)

s/ end of the protocol/ end of the protocol interaction/

New definitions (is this a bad idea?)

Rules Protocol: I don't think that the Rule Maker ever need provide a Location Generator with rules.  The RM is only interested if the LG decides to become an LS.  Same comment on the new definition of Conveyance Protocol.

Section 3.1.2

Please remove ", or they will transmit the location to the first LS in the Geopriv process".  They become the first LS when they decide to distribute LI.

This section is the first to use 2119 text in this document.  It came as a surprise to me, and it's probably unnecessary.  Certainly that first MUST doesn't work and it could be removed without ill effect.

When introducing the "privacy-preserving default rules" (good name) it would help to highlight the most basic privacy-preserving rule: don't disclose.  You miss a prime opportunity to call this out.  The LCP policy is really only an exception to that rule.

The following note is put in as a throwaway, but it's actually quite important:

   (Note that as for other Location Servers, the decision
   as to which Rule Makers are authorized is a matter of local policy.)

i.e. "The decision as to which Rule Makers are authorized to provide a Location Server with rules is a matter for local policy."

The following statement shouldn't be necessary - the LG can't act as an LS without a Rule Maker providing it with other than the default rules.  The fact that a positioning protocol needs good privacy considerations is important, but I don't think that this actually solves the problem.

   Where possible, Positioning Protocols SHOULD enable the Target to
   convey Rules to the LG.

Therefore, the sentence following this isn't really necessary.

Call out a new section for Location Configuration Protocols and your discussion of the LCP policy.  This continues on from positioning protocols, but it really belongs with the conveyance discussion.  Having these under 3.1.2 meant that I missed this on my first skim through.  This could really be moved.

Based on the rest of the text, I'm not sure that Positioning protocols transport Location Objects.  They might transport location information, but without Rule Maker involvement, this isn't a real Location Object.

Section 3.2

I don't think that the distinction made between LSi and LSa is necessary.  And, being unnecessary, it is more harmful than otherwise.  A Location Server _MUST_(!) be authorized to distribute location information by a Rule Maker.  That's all there is - how it gets that authorization might be interesting, but not worth a new categorization.

Section 3.2.1

"Retransmit location accurate within 100 meters" might be wrongly interpreted as a quality constraint.  It also uses the word accurate in relation to a quantified value - something I like to wrap people on the knuckles for doing.  Try: "Retransmit location with accuracy no better than 100 meters uncertainty"

Please remove the "first three recipients" example - this is a contentious item that will continue to attract discussion that you don't want to burden this document.

Regarding:

   Location Servers may (might) also receive Rules governing location retention, 
   such as:

Usage rules are the subset of privacy rules that apply to the Location Server in its Location Recipient role.  If you were to retain the previous model, this wouldn't be special.

I don't think that there is a need to label "local rules" and "forwarded rules".  I'd frame this discussion differently.  The rules provided to an LR stipulate how location information is used.  A subset of these are the rules that stipulate how the LR can act as an LS.  A further subset of those rules stipulate how the LS forms the LO it sends to LRs, including the rules that are put in the LO.  These rules that are included in the LO provide an LR with an automatically authorized Rule Maker - the entity that sent them the location information.

A nice consequence of the above is that virtually every LS in the system is able to operate without a rules protocol.  The LG that acts as an LS can use the LCP policy.  The Target that acts as an LS also assumes the RM role.  Any LR that decides to act as LS can use the rules provided in the LO it received.

The following doesn't say how anyone determines the difference between LR and LS.

   and whether or not the Target's location may be
   retransmitted ("Retransmission").  (The latter rule will never grant
   an LR the permission to retransmit, since by definition an LR is a
   final end point for a Target's location, but an LS that receives a LO
   may be granted this permission.)  

I'm going to just say that that statement is just wrong.

Section 3.2.2 s/MUST be/are/

Section 3.2.3

In compositing rules from multiple Rule Makers, I've recently noted that in common policy there is no way to override a rule granting access from a Rule Maker with "higher authorization".  If any Rule Maker grants access to information, there is no way for another to deny that, or provide lesser access to that information.  This is due to the absence of prohibition-type rules.  A note on this point might be pertinent since you discuss overriding of rules.  Common policy operates on the Union principle by default.  The intersection rule implies chaining of the different rulesets, which is actually quite difficult with common policy.

An LSi has no need for any rule combination, I think that you have a typo in the last paragraph.

This section needs a bit more consideration.

Section 3.2.4 don't make RECOMMENDATIONS for implementations.

s/Coveyance/Conveyance/

Section 3.3.1

I think it sensible to assume that if an LR receives a Location Object, then no rules should prevent that immediate use and disposal.  Checking the rules should only be necessary if the LR wants to do something else.  Storage in any way (including for derived information) requires checking retention rules.  Retransmission means that the LR becomes an LS and Section 3.2 applies.  I don't think that this section needs to be much more complicated than that.

...to be continued...

Cheers,
Martin

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