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

[Martin Thomson <[e-mail]>]

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 <[e-mail]> 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.