Review of draft-ietf-geopriv-http-location-delivery-07
Eric Rescorla <ekr@networkresonance.com> Sun, 25 May 2008 01:55 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213F93A69BC; Sat, 24 May 2008 18:55:00 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1BA3A6868; Sat, 24 May 2008 18:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.553
X-Spam-Level:
X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok+bS2nrsu6y; Sat, 24 May 2008 18:54:56 -0700 (PDT)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id A825E3A67FB; Sat, 24 May 2008 18:54:56 -0700 (PDT)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 4DE5A5081A; Sat, 24 May 2008 19:00:40 -0700 (PDT)
Date: Sat, 24 May 2008 19:00:40 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: secdir@mit.edu, draft-ietf-geopriv-http-location-delivery@tools.ietf.org
Subject: Review of draft-ietf-geopriv-http-location-delivery-07
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080525020040.4DE5A5081A@romeo.rtfm.com>
Cc: ietf@ietf.org, iesg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
$Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 2008/05/24 15:03:19 ekr Exp $ TECHNICAL S 4.2. which a Location Recipient (LR) can use to retrieve LI. A location URI provided by a LIS can be assumed to be globally-addressable; that is, anyone in possession of the URI can access the LIS. However, this does not in any way suggest that the LIS is bound to reveal the location associated with the location URI. This issue is deemed out I don't understand this point. anyone in possession of the URI can access the URI but the LIS isn't required to reveal it? Those seem kind of contradictory. S 4.3.1. Devices that establish VPN connections for use by other devices inside a LAN or other closed network could serve as a LIS, that implements the HELD protocol, for those other Devices. Devices within the closed network are not necessarily able to detect the presence of the VPN and rely on the VPN device. To this end, a VPN device should provide the address of the LIS server it provides, in response to discovery queries, rather than passing such queries through the VPN tunnel. How do you envision this happening? Isn't this going to require changing every VPN protocol? I think some more text would be appropriate here... S 5.1. o The HELD protocol must provide authentication, confidentiality and protection against modification per Section 10.3. Are you talking about HELD, which doesn't seem to have these features, or about the transport protocol? Also, authentication for who? Based on what model? S 6.5. I'm having trouble keeping straight two kinds of URIs: - URIs that a Device uses to get its own LI. - LbyR references that the LIS hands out. This text seems to imply that an LIS can hand out a helds: URI. Is that *also* the URI that a Device derferences? S 6.5.1. A "locationURI" SHOULD NOT contain any information that could be used to identify the Device or Target. Thus, it is RECOMMENDED that the "locationURI" element contain a public address for the LIS and an anonymous identifier, such as a local identifier or unlinked pseudonym. 1. This seems like it should be clearer about what is desired. In particular it's not just "identify" but also "link". Also this needs to be clarified to indicate the implications of idetntifiction by position. 2. Shouldn't this be MUST strength? S 8. Does this say somewhere what "helds" actually means? I see the definitition of the URI, but it doesn't say what the underlying transport is, as far as I can tell. Given a "helds:" URI, what am I supposed to do with it? S 9. OK and here's how I get confusied about the two types of URI, since this is an HTTP binding, but there's no corresponding URI. The implementation of HTTP as a transport mechanism MUST implement TLS as described in [RFC2818]. Is this MUST implement or MUST use? Don't the next two sentences imply MUST use? TLS provides message integrity and privacy "privacy" -> "confidentiality" between Device and LIS. The LIS MUST use the server authentication method described in [RFC2818]; the Device MUST fail a request if server authentication fails, except in the event of an emergency. This is incomplete, because 2818 assumes the presence of a URI to compare against. Where does that come from? How is client authentication supposed to work here? S 10.3. o The network SHOULD have mechanisms that protect against IP address spoofing, such as those defined in [RFC3704]. Is this WG really in a position to levy a SHOULD level requirement for network ingress filtering? Recall that this is really a global level technology. Or do you mean something else? o The LIS and network SHOULD be configured so that the LIS is made aware of Device movement within the network and addressing changes. If the LIS detects a change in the network that results in it no longer being able to determine the location of the Device, then all location URIs for that Device SHOULD be invalidated. This probably needs some more detail about how it's going to work. When there are further mechanisms available to authenticate ownership of the IP address, the LIS SHOULD use them to authenticate that the client is the owner of the target IP address. For example, in a TLS transaction, the client could present a certificate with a public key bound to an IPv6 Cryptographically Generated Address, and the LIS could verify this binding. Not that I think that any situation in which the client has an IP level cert is particularly likely, but this one seems particularly unlikely. EDITORIAL Abstract: independent of session-layer. This document describes the use of Hypertext Transfer Protocol (HTTP) as a transport for the protocol. This should be HyperText Also, isn't this using HTTPS, not HTTP. S 1. information. The LIS service applies to access networks employing This is the first reference to LIS. Please expand. [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which the Device might rely on its access network to provide location "the" -> "a" capable of MIME transport. This document describes the use of Hypertext Transfer Protocol (HTTP) as a transport for the protocol. See comments about abstract. S 4.3. I would move this to precede 4.1 and 4.2, since it's orthogonal to the value/reference distinction. S 5.1. o The HELD protocol is a request, response protocol, thus the I would write request/response. S 6.6. schema Section 7 for a location response message due to XML schema "schema Section 7" -> "schema in Section 7" _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Review of draft-ietf-geopriv-http-location-delive… Eric Rescorla
- Re: Review of draft-ietf-geopriv-http-location-de… Hannes Tschofenig
- Re: Review of draft-ietf-geopriv-http-location-de… Eric Rescorla
- Re: Review of draft-ietf-geopriv-http-location-de… Hannes Tschofenig
- Re: Review of draft-ietf-geopriv-http-location-de… Eric Rescorla
- Re: Review of draft-ietf-geopriv-http-location-de… Eric Rescorla
- Re: [secdir] Review of draft-ietf-geopriv-http-lo… Richard Barnes
- RE: [Geopriv] [secdir] Review ofdraft-ietf-geopri… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Geopriv] Review of draft-ietf-geopriv-http-l… Eric Rescorla
- RE: [Geopriv] Review of draft-ietf-geopriv-http-l… Tschofenig, Hannes (NSN - FI/Espoo)
- RE: Review of draft-ietf-geopriv-http-location-de… Mary Barnes
- Re: Review of draft-ietf-geopriv-http-location-de… Eric Rescorla
- Re: Review of draft-ietf-geopriv-http-location-de… TSG
- SHOULD vs MUST (was Re: Review of draft-ietf-geop… Lawrence Conroy
- Re: SHOULD vs MUST (was Re: Review of draft-ietf-… Eric Rescorla
- RE: [Geopriv] Review of draft-ietf-geopriv-http-l… Dawson, Martin
- Re: SHOULD vs MUST (was Re: Review of draft-ietf-… Dave Cridland
- Re: SHOULD vs MUST (was Re: Review of draft-ietf-… Joe Abley
- Re: SHOULD vs MUST Frank Ellermann
- Re: SHOULD vs MUST (was Re: Review of draft-ietf-… Iljitsch van Beijnum
- Re: SHOULD vs MUST Fred Baker
- Re: SHOULD vs MUST Scott Brim
- Re: SHOULD vs MUST John C Klensin
- Re: SHOULD vs MUST Fred Baker
- Re: SHOULD vs MUST Scott Brim
- Re: SHOULD vs MUST John C Klensin
- Re: SHOULD vs MUST Scott Brim
- Re: SHOULD vs MUST Dean Willis
- Re: SHOULD vs MUST Robert Sparks
- Re: SHOULD vs MUST Dave Crocker
- Re: SHOULD vs MUST Dave Cridland
- Re: SHOULD vs MUST Iljitsch van Beijnum
- SHOULD vs MUST case sensitivity Dave Crocker
- RE: SHOULD vs MUST case sensitivity Eric Gray
- Re: SHOULD vs MUST case sensitivity Julian Reschke
- Re: SHOULD vs MUST case sensitivity Keith Moore
- SHOULD vs MUST case sensitivity Dave Crocker
- RE: SHOULD vs MUST Eric Gray
- SHOULD vs MUST case sensitivity Dave Crocker
- Re: SHOULD vs MUST case sensitivity C. M. Heard
- Re: SHOULD vs MUST case sensitivity Iljitsch van Beijnum
- Re: SHOULD vs MUST case sensitivity Randy Presuhn
- Re: SHOULD vs MUST case sensitivity Dave Crocker
- Re: SHOULD vs MUST case sensitivity Dave Crocker
- Re: SHOULD vs MUST case sensitivity Randy Presuhn
- Re: SHOULD vs MUST case sensitivity Keith Moore
- Re: SHOULD vs MUST case sensitivity Dave Crocker
- RE: SHOULD vs MUST case sensitivity Eric Gray
- Re: SHOULD vs MUST case sensitivity Spencer Dawkins
- Re: SHOULD vs MUST case sensitivity Ralph Droms
- Re: SHOULD vs MUST case sensitivity Dave Crocker
- RE: SHOULD vs MUST case sensitivity Hallam-Baker, Phillip
- Re: SHOULD vs MUST case sensitivity John Levine
- RE: SHOULD vs MUST case sensitivity Hallam-Baker, Phillip
- Re: SHOULD vs MUST case sensitivity John Leslie
- RE: Review of draft-ietf-geopriv-http-location-de… Mary Barnes