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.
-- 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.
-- 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?
-- 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.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf