Using Device-Provided Location-Related Measurements in Location Configuration Protocols
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 (for -07)
Gonzalo Camarillo Former IESG member
No Objection (for -07)
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection ()
Joel Jaeggli Former IESG member
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 (for -07)
Pete Resnick Former IESG member
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? 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.
Sean Turner Former IESG member
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 (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 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.
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 (for -07)
Ted Lemon Former IESG member
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. --- 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. 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. --- 6.1 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". --- 6.1 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.