[apps-discuss] Review of "A Location Dereferencing Protocol Using HELD"
Ted Hardie <ted.ietf@gmail.com> Tue, 13 December 2011 00:19 UTC
Return-Path: <ted.ietf@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 87E1921F86B3; Mon, 12 Dec 2011 16:19:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.914
X-Spam-Level:
X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 n9OaD0PtixHB; Mon, 12 Dec 2011 16:19:09 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE0B921F86A4; Mon, 12 Dec 2011 16:19:08 -0800 (PST)
Received: by ggnk5 with SMTP id k5so6977065ggn.31 for <multiple recipients>; Mon, 12 Dec 2011 16:19:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=lAMBYGlo+muHivZK8FtuRfaeH/3x2ivp0rMGRYWcyz8=; b=yIbdBfsk+91n4vX9NbiKaeff6BR1e2vwMIogw/NIjE5Aq9aP3kWH+9jiymCU/mkbFS YT/6PIqCqbSkJ2YmykdGApzZlUC/L3ZAQcEvrROf28nYCrPUFj7VMckwJOkqXq2dfodE CyVp+GeKKlbvHBdewamTeuiysXLdxk/AxiaLc=
MIME-Version: 1.0
Received: by 10.236.145.72 with SMTP id o48mr387794yhj.86.1323735548478; Mon, 12 Dec 2011 16:19:08 -0800 (PST)
Received: by 10.236.156.40 with HTTP; Mon, 12 Dec 2011 16:19:08 -0800 (PST)
Date: Mon, 12 Dec 2011 16:19:08 -0800
Message-ID: <CA+9kkMC6mMXoxQ7XsJdOm5sHiBLbNajsvfESqe1EsoigzX4C9w@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: apps-discuss@ietf.org, IESG <iesg@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: draft-ietf-geopriv-deref-protocol.all@tools.ietf.org
Subject: [apps-discuss] Review of "A Location Dereferencing Protocol Using HELD"
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: Tue, 13 Dec 2011 00:19:09 -0000
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-deref-protocol-04 Title: A Location Dereferencing Protocol Using HELD Reviewer: Ted Hardie Review Date: 12/12/2011 Summary: There are some editorial issues which it would be useful to address, but within the right context, the document seems to be okay. There is also one extensibility question. Minor Issues: The document's introductory section is likely to be confusing to new readers, as it assumes both a pretty deep familiarity with RFC 5808 and RFC 5985, as well as some additional knowledge of the protocol contexts in which URIs are provided. Those documents are referenced early, but it might be useful to make the dependence on them even more explicit. Something like "This document describes a location dereferencing mechanism within the context of the location by reference model set out in RFC 5808, and readers are advised to familiarize themselves with the requirements set out in RFC 5808 prior to proceeding (see also the appendix). The protocol is described in terms which assume familiarity with HELD (RFC 5985), and it should be reviewed by anyone considering implementation or deployment of this mechanism. While at its base the protocol specified here describes how an HTTP or HTTPS-based HELD request to a specified URI returns an XML formatted response containing a location, this occurs within a context with specific authentication and authorization requirements, and these need to be well-understood to maintain the integrity of the system described." As I tried to read this from the point of view of a new reader, it also struck me that bringing sections 4 & 5 forward to before section 3 might make it easier to follow. As it stands now, the authorization model discussion relative to the URIs occurs prior to the discussion of the protocol mechanism. I understand the reasons for that, but it may be confusion. I have not written out the sections in the other order, so it may be more difficult than it is worth to make the change, but it seemed at first glance that all it would take is mechanical movement plus an opening section in the new section 5 (previously 3) saying something like "As is demonstrated above, the dereferencing of one of these URIs produces location data, and access to this operation thus requires authorization similar to that of providing the location data directly. The sections below describe authorization models and methods, and describe when they might be appropriate to deploy." It would also be useful to describe whether these methods may be extended. Someone who wanted to re-use URLAUTH principles, for example, could create a method that was proof-of-possession but which allowed only one use (thus thwarting replay attacks). That would require new language (it's not idempotent, obviously, so a method would have to be described); would that require an update to the document?