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

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Apr 2013 17:00:35 -0700

Hi Eliot,

Thanks for the review.  I think that you caught a few important things here.

And now time for my much-belated response (sorry about that).  A draft
revision will follow in due course; hopefully in less time than this
response.

On 26 March 2013 07:29, Eliot Lear <[email-masked]> wrote:
> 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.

Hmm, I'd be interested to hear about what you consider to be
problematic with the privacy considerations.  We put a lot of thought
into those.  Obviously, this is potentially highly sensitive, but I
thought we'd hit the important considerations.

> 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.

I don't see how you could infer that the example is normative from
this.  The examples throughout were always intended to be illustrative
only.

I can see how you might want to have a separate document for the
measurement "request", such as it is, but that doesn't fare especially
well outside of the context of the document, so we decided to keep
this together with the measurement definitions.

I didn't get the XMPP comment until I saw your nit on it.  This isn't
actually XMPP, it's a presence document format (PIDF) that is shared
by SIMPLE (SIP), XMPP and geopriv.  PIDF-LO is the location extension,
and protocol agnostic in that sense.

> 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.(*)

That is true, the assertion is a wee bit strong.  I'll add "a request
for location information in any protocol capable of carrying XML",
which includes carrying it by reference, at least in theory ;)

> §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?

The first <tuple> element contains a child
       <lmsrc:source>lis device</lmsrc:source>
The second:
       <lmsrc:source>lis</lmsrc:source>

I don't quite know how to make this clearer.  (It would be clearer if
the XML were smaller, but that is the smallest valid PIDF-LO I could
construct :/ )

> §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?

I truly wish that there were an existing spec.  I'm not sure that I
can justify the effort involved in making a split.  Especially since
we seem to be moving away from XML schema en masse.  I would still be
supportive of an attempt to do this.

> 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).

Thanks for picking up the 11v reference.

Yeah, someone pinged me on an RFC 20 reference in a different review.
It was the best I could find at the time I originally drafted the
document almost a decade ago.

> 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]

Thanks for catching 2661.
5226 is normative in the sense that it defines the rules for the
registries that the document establishes.

> 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.

I believe that TR101 and 25 are informative only.  They describe
deployment architectures.

> Nits:

All done.  Much thanks.

> Page 5, first paragraph, has some extraneous characters (\u002D).

A regression in xml2rfc :)  It no longer converts &mdash; properly.

> idnits indicates that there are 7 instances of lines that are too long, and

Another damned regression in xml2rfc.  I mentioned this on
tools-discuss a while back.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Apr 2013 17:01:55 -0700

> registries that the document establishes.

Oops, I was wrong about 5226 and forgot to check before hitting send.
Scratch that comment.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Apr 2013 09:26:09 +0200

Hi Martin,

All my other review comments are satisfied, save just one:

> this.  The examples throughout were always intended to be illustrative

Sorry I meant that you are honing in on HELD even outside of the
specific example.

> this together with the measurement definitions.

That's right, and I don't think you should create a separate spec.  Now
it's been a while since I did the review but I recall traipsing through
HELD to try to determine whether in fact this spec updates that spec. 
If so that should be indicated.

Eliot

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 Apr 2013 10:14:38 -0700

> Sorry I meant that you are honing in on HELD even outside of the

Ah yes, I am painfully aware of the sampling bias that arises from a
sample set of one.  However, that's what we have and it wouldn't be
practical to pretend otherwise.  Maybe there needs to be a disclaimer
along the lines of:

"This document attempts to provide generic capabilities that apply to
any location request protocol.  In practice however, only the HELD
protocol [RFC5985] has been considered.  Use of these capabilities in
other protocols could require additional adaptation."

Though that would be a small lie.  Other protocols have been
considered.  I'm aware of at least 3 that could use these
capabilities.  I just don't think that any of those protocols wants
these extensions (for a range of other reasons).

> If so that should be indicated.

Ah yes, our document shepherd asked this same question, to wit I
answered: This draft exercises extension points established by <the
document in question: RFC5985> and therefore does not need to update
that document.

We knew about this work when we published HELD, so made sure that the
extension points were available.