Subject: [apps-discuss] apps-team review of draft-ietf-geopriv-held-identity-extensions-04

From: Scott Lawrence <[email-masked]>
Date: Tue, 19 Oct 2010 23:26:31 -0400

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

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-held-identity-extensions-04
Title: Use of Device Identity in HTTP-Enabled Location Delivery (HELD)
Reviewer: Scott Lawrence
Review Date: 2010-10-19

Summary: This draft is almost ready for publication as a Proposed
          Standard RFC but has a few issues that should be fixed before
          publication.

Major Issues:

- Section 6: the included schema does not validate, as it does not
   define the base type 'digits'.  Tested using
            http://www.w3.org/2001/03/webdata/xsv

- (several places) The term "Rule Maker" is used but is never
   defined.  I assume that this is used as defined (however loosely) in
   RFC 3693; if so, a reference is needed.

Minor Issues:

- In the Abstract, the phrase "a pointer to the location determination
   process" is awkward and possibly misleading.  The draft says:

      When a Location Information Server receives a request for location
      information (using the locationRequest message), described in the
      base HTTP Enabled Location Delivery (HELD) specification, it uses the
      source IP address of the arriving message as a pointer to the
      location determination process.

   The HELD specification that this draft extends describes the use of
   the IP address as an identifier:

      In this document, the IP address of the Device, as reflected by the
      source IP address in the location request message, is used as the
      identifier.

   replacing the awkward phrase quoted above with a use of the same
   terminology used in the HELD specification ("the identifier of the
   device whose location is to be determined").

- Section 1, paragraph 6: remove "obviously" from the first
   sentence.  (if it was obvious to the reader, then it's redundant; if
   it was not, then it's insulting: either way it adds nothing useful)

- Section 1.1, final paragraph:

       Automated mechanisms to ensure privacy constraints are respected
       are possible.

   An example would provide useful context for this statement.

- Section 4.2, first sentence:

       The LCP policy does not allow requests made by third parties.

   I assume that this refers to the "LCP Policy" as described in the
   preceding sections - this would be clearer if it were quoted as it
   was in those sections and elsewhere in the document.

Nits:

- Section 1:  When first used, it would be helpful to capitalize
   the phrases "Location Configuration Protocol", "Location Information
   Server", and "Location Recipients" so that the reader gets the hint
   that the subsequent abbreviations ("LCP", "LIS", and "LR") are bound
   to them.

- Figure 2: It would be more clear to use more than one value in the
   requiredIdentifiers content (since it is a list).

- (throughout) I found the hyphenation of 'third-party' to be
   frequently distracting, and suspect that several such should not
   have been hyphenated, as in "If an unauthorized third-party
   falsifies addressing..." in section 1.1.  I suggest consulting the
   RFC Editor for guidelines, but suspect that hyphenation should at
   most be used when the term in modifying a verb rather than acting as
   a noun, and it may be clearer to just never use hyphenation.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 21 Oct 2010 05:59:15 +0800

Thanks for the review Scott, and especially for picking up the schema error!

>             http://www.w3.org/2001/03/webdata/xsv

Oops.  That's an editorial bug.  It was collateral in a change that was made in response to a recent review.
 
>    RFC 3693; if so, a reference is needed.

ADD:
  A Rule Maker is the term used for the role that makes policy decisions about authorization, determining what entities are permitted to receive location and how that information is provided.

I'll add this to the terminology.  I'll add a reference to the updated geopriv-arch draft instead for this.

>    process" is awkward and possibly misleading.  The draft says:
...
>    device whose location is to be determined").

That's clearer.  Thanks.

>    An example would provide useful context for this statement.

You aren't the only one to point this out.  I proposed to add the following previously; it's just not in the draft yet.
  For instance, a policy rules document could be used to express the agreed policy.  Formal policy documents, such as [RFC4745], can be applied in an automated fashion by a LIS.

>    was in those sections and elsewhere in the document.

Will do.
 
> Nits:

Thanks, all fixed.  The third-party thing has bugged me too.

Cheers,
Martin