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

Martin Thomson <martin.thomson@gmail.com> Thu, 11 April 2013 17:14 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94EB21F920B; Thu, 11 Apr 2013 10:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level:
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAMReNXdksTe; Thu, 11 Apr 2013 10:14:40 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8ED21F91D8; Thu, 11 Apr 2013 10:14:39 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id d46so1389200wer.2 for <multiple recipients>; Thu, 11 Apr 2013 10:14:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=p42cJ5gdCxeuM+96SVnpmnca9e3S1VGegInY//q/dEA=; b=JNttpGdvFgw1HQu29LFHDmdwjuiwDST0psMg4lS6Uz9cAg28dCUHy/sJG/+tAoX7s+ Wuj/Hk4y/+DiSuTHHJOFDRIsU8ZOBtdeq/JbxGhWrA5sSDFx3ttgOPsYFqGPJMnep4EE 2WY4kskvsOFriJKP63ytLS4zB5b0evgKIspowaCh8akuuWmtA2B0P22j9+otbdUBAveS G8WD4QoyTQxCr2Xwdro5l6ZzTIolBpZwbqLY76hUyVCokemZ8UqfX2dB/6H5mpCYYMyX 4H1NaPY9N+3srjipOQiXFES/EEYCBB4nZfBqrPJi8j1fwKJM11oXldB9Lkh6/L7kUlSS 6fjA==
MIME-Version: 1.0
X-Received: by 10.180.72.228 with SMTP id g4mr35448359wiv.22.1365700478681; Thu, 11 Apr 2013 10:14:38 -0700 (PDT)
Received: by 10.194.41.35 with HTTP; Thu, 11 Apr 2013 10:14:38 -0700 (PDT)
In-Reply-To: <51666591.30208@cisco.com>
References: <5151B0B5.2090407@cisco.com> <CABkgnnWNPMgsNACjOYdxcn3VW20LFOOS5XeFO9Nifxv2hJTwUg@mail.gmail.com> <51666591.30208@cisco.com>
Date: Thu, 11 Apr 2013 10:14:38 -0700
Message-ID: <CABkgnnUFXQ-hH1n8onJzRVPDWsoVXo=uQ75mV639gKrFqCSXSA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: text/plain; charset=UTF-8
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, IESG <iesg@ietf.org>, draft-ietf-geopriv-held-measurements.all@tools.ietf.org
Subject: Re: [apps-discuss] Apps Area Review for draft-ietf-geopriv-held-measurements-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 17:14:40 -0000

On 11 April 2013 00:26, Eliot Lear <lear@cisco.com> wrote:
> Sorry I meant that you are honing in on HELD even outside of the
> specific example.

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

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

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.