Using Device-Provided Location-Related Measurements in Location Configuration Protocols
draft-ietf-geopriv-held-measurements-09

Thanks for addressing all my questions and comments!

Thanks for addressing my DISCUSS and COMMENT

Adrian:  I regret that we have not devised a way for a device to determine its location without giving away its location.

we have, (gps/loran/glonas/gnss). 

unidirectional flows of information in general don't reveal much about the receiver .

using the network has a certain convenience factor, notwitstanding the commercial incentives for doing so.

I think there's enough discusses that cover any concerns I do have to ballot this as no objection on the basis that they will be responded to, to someone's satisfaction.

4: The example in section 4 shows a "lm:measurements" element, and many examples in section 5 show a "measurements" element, but the text in 4.1 talks about a "measurement" element, and I only find a "measurement" element example in section 4.3. Which one is section 4.1 (and 4.1.1, 4.2, 4.2.1, and 4.3) intending to talk about?

4.1.1:

   The "time" attribute is optional...  However, time SHOULD
   be provided whenever possible.

I think your uppercasing is reversed. The "time" attribute is, as far as I can tell, OPTIONAL, in that it is not required for interoperation, but it should (or perhaps "is helpful to") be provided whenever possible.

4.1.2:

   A Device can use this attribute to prevent the LIS
   from retaining measurement data or limit the time that a LIS retains
   this information.
   [...]
   The LIS MUST NOT keep location-related measurement data beyond the
   time indicated in the "expires" attribute.

Is this a privacy requirement or is there some other reason why a device would want to "prevent" retention? Making expires mean something other than simple validity and making it a hard requirement to dispose of the data seems to indicate something is going on here that is unstated. If it's a privacy requirement, instead of putting the MUST here, just put a forward pointer to section 6.

This geopriv draft did not disappoint! My usual paranoid reaction of "oh my ... really" and "wow ... just think about the privacy issues" was topped by Stephen's reaction ... so what he said plus these nitty-nits:  

s1: r/otherwise/other metric ?

s4.1.1: r/The "time" attribute is optional
         /The "time" attribute is OPTIONAL
  Actually this happens in a lot of places in the draft.  Should the schema requirements match the text requirements?

s4.1.2: What's the requirement for support of the time attribute?
        Should the same statement about multiple measurement(s) be copied here too because expiry time is linked to measurement(s)?

s4.2: over a period of time redundant?: more than once over a period
    of time

s4.2: Is a very large value 100 or 10000000?  Maybe just say:

    If omitted, this value can be assumed to be a
    large enough so that the RMS error is an indication of the
    standard deviation of the sample set.

s5.4: Should WiMAX be listed here?

I'm a No Objection, but agree with Barry's Discuss on 7.1.5. 

My comments follow. In general, I thought this document was fairly easy to follow given the breadth of networking and location measurement technologies being discussed, and wanted to note that the security considerations section reflected a lot of work.

In 3.  Location-Related Measurements in LCPs

   Use of location-related measurement data is at the discretion of the
   LIS, but the "method" parameter in the Presence Information Data
   Format - Location Object (PIDF-LO) [RFC4119] SHOULD be adjusted to
   reflect the method used.

Could you help me understand why this is an RFC 2119 SHOULD?

On the same page, in this text:

   Location-related measurement data need not be provided exclusively by
   Devices.  A third party location requester can request location
   information using measurement data, if they are able and authorized.

I'm somewhat confused because of a "requester/they" mismatch, so I'm not sure what noun "they" refers to, but I'm also confused by "can do foo if they are able". I'm not sure what "are able" means in this context.

In 4.1.1.  Time of Measurement

   The "time" attribute is attached to the root "measurement" element.
   If it is necessary to provide multiple sets of measurement data with
   different times, multiple "measurement" elements SHOULD be provided.

I am curious why this is a SHOULD, but I'm more curious if it's obvious how you provide multiple sets of measurement data from different times without providing multiple "measurement" elements. What did I miss?

I have the same questions about this text in 4.2.1.  Time RMS Error

   The "timeError" attribute does not apply where multiple samples of a
   measurement are taken over time.  If multiple samples are taken, each
   SHOULD be included in a different "measurement" element.

In 5.  Location-Related Measurement Data Types

   All included measurement data definitions allow for arbitrary
   extension in the corresponding schema.  As new parameters that are
   applicable to location determination are added, these can be added as
   new XML elements in a unique namespace. 

I'm reading this "as parameters are added, these can be added". I'm pretty sure you're saying more than that. Perhaps "as new parameters are added in foo, they can also be added as new XML elements"? If so, including "in foo" would be helpful to newer readers.

In 5.3.  802.11 WLAN Measurements

   regclass:  The regulatory domain and class.  The "country" attribute
      optionally includes the applicable two character country
      identifier (dot11CountryString), which can be followed by an 'O',
      'I' or 'X'.  The element text content includes the value of the
      regulatory class: an 8-bit integer in decimal form.

if you could include an expansion of "o"/"I"/"X", and for a bonus include a reference, that would be lovely.

In 5.3.1.  Wifi Measurement Requests

   Two elements are defined for requesting WiFi measurements in a
   measurement request:

   type:  The "type" element identifies the desired type (or types that
      are requested.

is it obvious from the specification what the requester will get if the desired type(s) are not available? Something not desired, or nothing, or ...

In 5.4.  Cellular Measurements

   MCC and MNC are provided as digit sequences; a leading zero in an MCC
   or MNC is significant.  All other values are decimal integers.

We've had some extended discussions recently about numeric strings with a leading zero being assumed to be octal, and the broader IETF community is not of one mind on whether that's true or not. Based on those conversations, it might be helpful to add "... and the digit sequences must not be interpreted as octal integers".

In 5.5.3.  Per-Satellite Measurement Data

   codephase:  The observed code phase for the satellite signal,
      measured in milliseconds.  This is converted the system-specific
      value of chips or wavelengths into a system independent value.

The last sentence in this definition seems to be garbled.

In 7.1.4.  Measurement Replay

   For properties of a network, time-invariance is often directly as a
   result of the practicalities of operating the network.  Limiting the
   changes to a network ensures greater consistency of service.  A
   largely static network also greatly simplifies the data management
   tasks involved with providing a location service.

I happen to agree with this - and I managed a group that administered a network for three years, so that's based on my own experience - but I'm not sure why this is a security consideration. Is it actionable? Other than recognizing that "if you change stuff less, you'll screw stuff up less", how does a network operator respond to this reasonable observation?

In 7.1.4.  Measurement Replay

   Requesting additional supporting observations can reduce the size of
   the region over which location information can be altered by an
   attacker, or increase trust in the result, but each additional has a
   cost.  

This sentence is garbled, or a word is missing, or ...

In 7.2.4.  Attribution

   Including an authenticated identity for all sources of measurement
   data is presents a number of technical and operational challenges.

This sentence is garbled.

In 10.  Acknowledgements

   Thanks go to Simon Cox for his comments relating to terminology that
   have helped ensure that this document is aligns with ongoing work in
   the Open Geospatial Consortium (OGC).

I think "is aligns with" is just an editorial problem, but mention it during IESG evaluation because I don't know that.

I didn't check these comments against -09, they may
have been taked into account (or not:-)

- 4 IPR declarations and we start our 70 pages with "A
method is described" ... that gives me patent-cringe (sorry
for the snark;-)

- section 2: "Location-related measurement data does not
identify a Device" - that is too absolute, such data
certainly can identify a Device and a user (even if it
changes over time).

- section 3, 2nd last para: there are privacy issues even
without 3rd parties.

- section 3, last para: s/security/security and privacy/

- 4.1.1: last sentence - is that SHOULD correct? What do I
do if I'm not abiding by the SHOULD? e.g. can I put in 2
timestamps in one measurement element? If not, then isn't
that a MUST?

- 4.1.2: How do I know if an expires means which of these
things and how do they really differ? I can't see how a LIS
can programatically know that.

- 4.2 & 4.2.1: Don't you need to say how to calculate the
RMS error? Won't coders do different things otherwise?

- 5.4, typo: s/cellar/cellular/ nice typo if you consider
how serial killers in movies might make use of this
protocol though:-)

- 5.5.1, I wondered why there are no initial registrations
for e.g. Russian or Chinese GNSS systems. Not objecting but
I'm curious. 

- 7.1.5, 1st sentence is broken, not sure what's meant

This is a style nit; feel free to ignore, but consider this text:

   In the HELD protocol, the inclusion of a measurement request in an
   error response with a code of "locationUnknown" indicates that the
   LIS believes that providing the indicated measurements would increase
   the likelihood of a subsequent request being successful.

Of course, the LIS has no beliefs.   Rather, the LIS has capabilities—it can make use of certain types of information, and might want to indicate to the peer that measurements of that type might result in a location result being determined where none can presently be determined.   So I would phrase it thusly (and probably incorrectly—I'm just doing this to illustrate my gripe):

   In the HELD protocol, the inclusion of a measurement request in an
   error response with a code of "locationUnknown" indicates that the
   LIS has the capability to use the indicated measurements to increase
   the likelihood of a subsequent request being successful.

As I say, this is a style gripe, and if you want to just ignore it, I won't complain.   The use of the term "believes" to refer to capabilities also occurs earlier in this section, and may occur elsewhere in the document—I don't know because I haven't finished reading yet, but I won't call out any more of these that I see, since I think this gets the point across.

   Though many of the
   underlying protocols support extension, creation of specific XML-
   based extensions to the measurement format is favored over
   accommodating protocol-specific extensions in generic containers.

By "is favored" do you mean "works better because of X" or "we recommend as a standard practice for consistency" or something else?   It might be better to use the active voice here and be more explicit about what you mean.   This may be unnecessary for readers who are already deeply familiar with geopriv, so feel free to ignore this, but as a relatively naive reader I am left somewhat confused by this advice.

The definition for giaddr says the address is a dotted quad or an IPv6 address, but in the example you use an IPv6-encoded IPv4 address.   This seems contradictory.   If dotted quads and IPv6-encoded IPv4 addresses are interchangeable, the normative text should say so, but why create the opportunity for trouble here?   If it were up to me I would require dotted quad for IPv4 and IPv6 address representations only for IPv6 addresses.

In 5.3, this doesn't parse:

   parameter:  The "parameter" element identifies an optional
      measurements are requested for each measured access point. 

I think someone might have made a cut-and-paste error here.   I don't know what this text is supposed to say, so I can't suggest an edit, but you ought to fix this prior to publication.

In 7.1.3, Would a LIS ever use GPS information provided by handsets in combination with WiFi information provided by mobile nodes to populate a mapping database that could then be used to determine locations of other mobile nodes that don't have GPS receivers?   IOW, is one benefit of this sort of attack that you could corrupt the LIS' measurement map?

In 8.6, the enterprise number is given as optional, but the field is always present in the remote ID option.   So why is it optional in the XML?

Cool stuff.