I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-geopriv-deref-protocol-04
Title: A Location Dereferencing Protocol Using HELD
Reviewer: Ted Hardie
Review Date: 12/12/2011

Summary: There are some editorial issues which it would be useful to
address, but within the right context,  the document seems to be okay.
 There is also one extensibility question.

Minor Issues:

The document's introductory section is likely to be confusing to new
readers, as it assumes both a pretty deep familiarity with RFC 5808
and RFC 5985, as well as some additional knowledge of the protocol
contexts in which URIs are provided.  Those documents are referenced
early, but it might be useful to make the dependence on them even more
explicit.  Something like "This document describes a location
dereferencing mechanism within the context of the location by
reference model set out in RFC 5808, and readers are advised to
familiarize themselves with the requirements set out in RFC 5808 prior
to proceeding (see also the appendix).  The protocol is described in
terms which assume familiarity with HELD (RFC 5985), and it should be
reviewed by anyone considering implementation or deployment of this
mechanism.  While at its base the protocol specified here describes
how an HTTP or HTTPS-based HELD request to a specified URI returns an
XML  formatted response containing a location, this occurs within a
context with specific authentication and authorization requirements,
and these need to be well-understood to maintain the integrity of the
system described."

As I tried to read this from the point of view of a new reader, it
also struck me that bringing sections 4 & 5 forward to before section
3 might make it easier to follow.  As it stands now, the authorization
model discussion relative to the URIs occurs prior to the discussion
of the protocol mechanism.  I understand the reasons for that, but it
may be confusion.  I have not written out the sections in the other
order, so it may be more difficult than it is worth to make the
change, but it seemed at first glance that all it would take is
mechanical movement plus an opening section in the new section 5
(previously 3) saying something like  "As is demonstrated above, the
dereferencing of one of these URIs produces location data, and access
to this operation thus requires authorization similar to that of
providing the location data directly.  The sections below describe
authorization models and methods, and describe when they might be
appropriate to deploy."

It would also be useful to describe whether these methods may be
extended.  Someone who wanted to re-use URLAUTH principles, for
example, could create a method that was proof-of-possession but which
allowed only one use (thus thwarting replay attacks).  That would
require new language (it's not idempotent, obviously, so a method
would have to be described); would that require an update to the
document?