Skip to main content

Using Device-Provided Location-Related Measurements in Location Configuration Protocols
RFC 7105


(Richard Barnes)

No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Stewart Bryant)


Note: This ballot was opened for revision 07 and is now closed.

Richard Barnes Former IESG member
Yes (for -07)

Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2013-06-24 for -08)
Thanks for addressing all my questions and comments!
Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2013-09-23)
Thanks for addressing my DISCUSS and COMMENT
Brian Haberman Former IESG member
No Objection
No Objection (for -07)

Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -07)

Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection ()

Joel Jaeggli Former IESG member
No Objection
No Objection (2013-06-13 for -07)
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -07)

Pete Resnick Former IESG member
No Objection
No Objection (2013-06-11 for -07)
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?


   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.


   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.
Sean Turner Former IESG member
No Objection
No Objection (2013-06-12 for -07)
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?
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-06-10 for -07)
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

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.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-10-02)
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
Stewart Bryant Former IESG member
No Objection
No Objection (for -07)

Ted Lemon Former IESG member
No Objection
No Objection (2013-06-13 for -07)
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.
Adrian Farrel Former IESG member
Abstain (2013-06-13 for -07)
As I observed in my Abstain on RFC 6772, I am not comfortable with the
motivation for this work, but I (of course) accept that there is a 
working group chartered to do the work and that there is support from
part of the community.

In this document my concern manifests that, under the guise of a device
doing something to find out where it is located, the device supplies 
information to a third party that allows that third party to work out
where is is located and then (possibly) report back to the device. I
can't see how that is consistent with privacy and I regret that we have
not devised a way for a device to determine its location without giving
away its location.

The argument that a Device does not have to supply information to an LIS
or ask for its location is true. However, I am exceedingly doubtful that
such features will be off by default or that they will be configurable 
by the average user. We should be looking for ways to improve function
for the user without sacrificing privacy or security. 

It is almost certain that this work could be turned around to allow the
Device to request, and the LIS to supply, information that the Device
could use together with its own measurements to determine its location.
Such an approach is computationally identical, but moves the venue of 
the computation to the Device and so preserves privacy.

It seems doubtful that there is anything that the authors can do to this
document to resolve my concerns, and so rather than force a debate with
unlikely positive outcome, I will Abstain on this document.


There are so many Discusses and Comments on this document it is hard to
find something new to say. I would observe that I found the document
generally quite readable, and that the techncial work seems sound modulo
the concerns expressed by others.


Need to expand LIS in the Abstract.



   A Device can use this attribute to prevent the LIS
   from retaining measurement data or limit the time that a LIS retains
   this information.

I doubt this! I think the attribute is a request. The device cannot 
actually control the LIS. And this is not mitigated by:

   The LIS MUST NOT keep location-related measurement data beyond the
   time indicated in the "expires" attribute.

You are attempting to use 2119 language to constrain implementations of
function that are not relevant to bits on the wire. Such statements are
at best false comforts. It would be better to not include them.

Perhaps there is a relationship to how the information is used in the
scope of this document that you *can* say. For example:

   The LIS MUST NOT use location-related measurement data to determine
   location information returned to the Device beyond the time indicated
   in the "expires" attribute.



   It is less desirable to distribute measurement data in the same
   fashion as location information.  Measurement data is less useful to
   location recipients than location information.  Therefore, a simple
   distribution model is desirable.

I think there is a double negative here. If there is an implicit 
statement that location information is distributed in a privacy-safe 
way, then you are probably saying that the measurement information is
less privacy-sensistive and could be distributed in a less privacy-safe
way. But that is not "it is less desirable" which would mean there is a 
desire not to. Maybe "there is less need".



   No entity is permitted to redistribute measurement data.  The Device
   directs other entities in how measurement data is used and retained.

You surely understand that writing this in an RFC will not actually
have any impact on what implementations of an LIS do, or what the NSA
instructs operators to do. [Other secret agencies also exist.]

What, then, is the value of this statement?

Ditto 6.2

   A LIS MUST NOT reveal location-related measurement data or location
   information based on measurement data to any other entity unless
   directed to do so by the Device.