Subject: [apps-discuss] Apps Area Review for draft-ietf-geopriv-held-measurements-06.txt

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Mar 2013 15:29:09 +0100

Gents,

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-held-measurements-06.txt
Title: Using Device-provided Location-Related Measurements in Location
Configuration Protocols
Reviewer: Eliot Lear
Review Date: 26 Mar 2013

Congratulations.  Really nice draft.    This draft describes a container
that can be used to request and report measurements relating to
location.  It is almost ready for publication.

I'd suggest that this draft receive additional review regarding its
privacy considerations section.  I will comment outside this review
regarding that issue, as this is an apps area review.  Also, I've not
done schema validation.

Major issues:

§ 4.3, page 10: I realize it'd be silly to write a six line RFC for
this, but the semantics of the HELD examples seem normative.  I think
it's appropriate for them to be so, but then you should make it more
explicit.  Same with your XMPP example. 

Minor issues:

§4.1, 2nd para on page 7.  While surely this is applicable for HELD,
there are protocols that have size considerations, and so your assertion
is a bit strong, and I would suggest that you scope it to be applicable
where XML can be carried.(*)

§4.4 Page 11, last paragraph.  It's not quite clear how the example
combines information in the LIS.  Maybe it's because I'm not steeped in
location lore, so perhaps you might point this out to me, if not others?

§8.3, Page 44: there has got to be an existing schema one can borrow IP
addresses from, no?  If not, is this worth splitting off?

Finally, see RFC 2026 for proper use of normative references.  You're
referencing 802.11v as an informative reference when in fact flightTime
depends on TOD and TOA from that spec.  And you're normatively
referencing RFC 20 (you were just aching to get that one in there) when
the ASCII reference is more than sufficient (btw, if you're using
xml2rfc you're looking for ANSI.X3-4.1986).

I get the following normative:

[ASCII], [RFC3629],  [RFC5985], [RFC2119], [RFC4119], [IEEE.8021AB],
[RFC3046], [RFC4649], [RFC3993], [RFC4580], [IANA.enterprise],
[RFC3986], [RFC4291], [IEEE.80211], [RFC5491], [TS.3GPP.23.003],
[TIA-2000.5], [GPS.ICD], [GALLILEO.ICD], [RFC2865], [IEEE.80211V]

The following are Informative:

[RFC3693], [RFC6155], [ANSI-TIA-1057], [RFC2661], [HARPER], [GPS.SPOOF],
[RFC5226], [RFC3688], [DSL.TR025], [DSL.TR101]

N.B.: regarding TRs 25 and 101, if you meant that other parameters could
somehow be pulled in as responses, then more work needs to be done in
the draft on this point to specify them.

Nits:

*Please save the RFC Editor some time and run the thing through a spell
checker*.  I've only caught a few errors, but I'll bet there are more.

  * In §2, plain language would dictate that an estimate cannot depend
    on a determination.  A location estimate can be based on reported
    observations. 
  * HELD should be defined on first use (§ 3, page 5).
  * Page 5, first paragraph, has some extraneous characters (\u002D).
  * Page 6, PIDF-LO should be defined on first use.
  * §4.2.1, Page 9, "multiple samples of a measurement is taken" ->
    "multiple samples of a measurement are taken"
  * §4.3 Page 9, last paragraph first sentence, last word: change "a
    error" to "an error"
  * Page 12, label the XMPP example.
  * §5.2, Page 14, remote identifier -> Remote ID or remote-id
    (depending on whether you refer to RFC 3046 or RFC4649,
    respectively).  Similarly, subscriber-id or Subscriber-ID for RFCs
    3993 and 4580.
  * Page 16, (type specification) introducted -> introduced
  * idnits indicates that there are 7 instances of lines that are too
    long, and that RFC 20 is listed as normative without being used in
    the body.

Eliot

(*) I thought about whether or not you've chosen the correct format for
this sort of information exchange (as opposed to ASN.1 or JSON), and
whether or not you should abstract away from it.  I think it would be a
good idea for somebody (like a grad student) to do that, but in the end
your primary application for this is HELD, and the draft is just fine
with its use of XML.  But it wouldn't kill you to indicate that as
possible future work, if someone is interested in this information in
very compressed form.