Hi Ben, Thanks for your third Gen-ART review of this document. My responses are inline below, with the exception of the Minor issue you highlight to which I responded in a separate email. Mary. -----Original Message----- From: Ben Campbell [mailto:ben@xxxxxxxxxxxx] Sent: Thursday, June 04, 2009 5:58 PM To: General Area Review Team; Barnes, Mary (RICH2:AR00); james.winterbottom@xxxxxxxxxx; martin.thomson@xxxxxxxxxx; barbara.stark@xxxxxxx Cc: Richard Barnes; acooper@xxxxxxx; Cullen Jennings; ietf@xxxxxxxx Subject: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-geopriv-http-location-delivery-14 Reviewer: Ben Campbell Review Date: 2009-06-04 IETF LC End Date: 2009-06-09 IESG Telechat date: (if known) Summary: This draft is ready for publication as a proposed standard. I have a few editorial and clarity comments that might could slightly improve the draft, but can safely be ignored. Additionally, I have one comment highlighting a "feature" that is not necessarily a problem, but is architecturally important enough that I want to make sure the IESG thinks about it. Major issues: None. Minor issues: -- There is one feature of HELD that the ADs should explicitly think about: The HTTP binding forbids LIS reliance on HTTP digest or basic authentication. If I understand correctly, this means effectively that the _only_ method for client authentication is the built in reverse routeability test. I am agnostic as to whether this is sufficient. Nits/editorial comments: -- section 4, paragraph 1: Please expand (and reference) PIDF-LO on first mention. [MB] Okay. -- Section 6.2, value list: -- In my previous review, I was confused as to the relationship between the geodetic/civic and LoBV/LoBR choices. I think it's worth some clarification in this section that geodetic and civic imply LoBV. [MB] Okay, how about the following: OLD: geodetic: The LIS SHOULD return a geodetic location for the Target. civic: The LIS SHOULD return a civic address for the Target. NEW: geodetic: The LIS SHOULD return a location by value in the form of a geodetic location for the Target. civic: The LIS SHOULD return a location by value in the form of a civic address for the Target. -- section 9.3, 5th paragraph: "A temporary spoofing of IP address could mean that a device could request a Location Object or Location URI that would result in another Device's location." It might be worth clarifying that (if I understand correctly) that this is more than a spoofing attack, in that the attacker must not only spoof its source address, but must be able to receive packets sent to the spoofed address? [MB] That statement was intended to include both those items, I'd propose to clarify as follows: NEW: A temporary spoofing of IP address could mean that a device could request a Location Object or Location URI that would result in receiving another Device's location if the attacker is able to receive packets sent to the spoofed address. -- same paragraph: "... re-use of the Device's IP address could result in another Device receiving the original Device's location rather than its own location." It seems like this problem is pretty unlikely to occur by _accident_ when HELD is used over TCP (the only binding right now), right? And certain not to happen over TLS? Might be worth a "mitigating" mention. [MB] Certainly, it is fairly unlikely (if not impossible in most situations), but the recommendations in the bullet points further reduce the potential for problems in the off chance that this occurs. It's not entirely clear to me why you suggest this is certain not to happen over TLS since this is talking about a device that has dropped and thus the connection would drop and it would seem there's a window for another device (although quite unlikely) to use that same IP address. But, perhaps, qualifying the statement as follows would address your concern: OLD: These exposures are limited by the following: NEW: While these situations are fairly unlikely to occur (in particular with the use of TCP/TLS), the exposures can be further limited by the following: _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf