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

Martin Thomson <> Thu, 11 April 2013 00:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96B4321F8733; Wed, 10 Apr 2013 17:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YG3Mv+yjMqC6; Wed, 10 Apr 2013 17:00:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1EACC21F8712; Wed, 10 Apr 2013 17:00:35 -0700 (PDT)
Received: by with SMTP id l18so1046683wgh.0 for <multiple recipients>; Wed, 10 Apr 2013 17:00:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=EfD13dCoJbSVX9/MWa4RapB0uQ2klN0PeC+8SCHVNek=; b=yNejMbb2pA0Ec3FfonOlPGvgAO10zA+aVcOXeSXnkWW5Swr6wsDwWPzTu5DEUwN9x1 1AaaHk15Uj+EZ/7al+iP7I91pC6L/GjO+47JtJDEIyJevVnoKTSNMVxWbHKvFvrfKo6k 6/HR7N8P9a8cEuXHdyc7HoCJsluo0PUsAF9PkReV1h7Punx+DpUZgsNXRkOAMr1RvMHk GfLJcZS5A6ztAG591dIv9CEsvWQJpsmgSCLtvCtGfr3netmu/ygd/ernueKBk6upxGyS 8zCVt4nVgQCnn6Rqmd5JNaQ0oGoe5KVZeDigoTiFt/GoiyFOwrq9bMLWy4jEGxAt3qW6 wQ4A==
MIME-Version: 1.0
X-Received: by with SMTP id hu5mr6394682wib.22.1365638435286; Wed, 10 Apr 2013 17:00:35 -0700 (PDT)
Received: by with HTTP; Wed, 10 Apr 2013 17:00:35 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 10 Apr 2013 17:00:35 -0700
Message-ID: <>
From: Martin Thomson <>
To: Eliot Lear <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, IESG <>,
Subject: Re: [apps-discuss] Apps Area Review for draft-ietf-geopriv-held-measurements-06.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Apr 2013 00:00:37 -0000

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

On 26 March 2013 07:29, Eliot Lear <> 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

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:

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.