RE: Review of draft-ietf-geopriv-http-location-delivery-07
"Mary Barnes" <mary.barnes@nortel.com> Mon, 14 July 2008 16:11 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 E9AEB28C1EA; Mon, 14 Jul 2008 09:11:34 -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 0B6A93A6A75; Thu, 10 Jul 2008 12:08:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.143
X-Spam-Level:
X-Spam-Status: No, score=-5.143 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4]
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 HS3hkd8Y-6e3; Thu, 10 Jul 2008 12:08:27 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A43843A6A58; Thu, 10 Jul 2008 12:07:16 -0700 (PDT)
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m6AJ7Bh09228; Thu, 10 Jul 2008 19:07:11 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Review of draft-ietf-geopriv-http-location-delivery-07
Date: Thu, 10 Jul 2008 14:04:38 -0500
Message-ID: <F66D7286825402429571678A16C2F5EE04522E99@zrc2hxm1.corp.nortel.com>
In-Reply-To: <20080620195947.29D0B5081A@romeo.rtfm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-geopriv-http-location-delivery-07
Thread-Index: AcjTDz0Btg36b9AWTxeiRbcUtyqVPQPrR2zQ
References: <20080525020040.4DE5A5081A@romeo.rtfm.com> <F66D7286825402429571678A16C2F5EE03ADF950@zrc2hxm1.corp.nortel.com> <20080620195947.29D0B5081A@romeo.rtfm.com>
From: Mary Barnes <mary.barnes@nortel.com>
To: Eric Rescorla <ekr@networkresonance.com>
X-Mailman-Approved-At: Mon, 14 Jul 2008 09:11:34 -0700
Cc: draft-ietf-geopriv-http-location-delivery@tools.ietf.org, geopriv@ietf.org, secdir@mit.edu, 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-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
Hi Eric, I've snipped the thread to just include the issues (3 total) that I'm uncertain as to whether they've been adequately addressed in the -08: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-del ivery-08.txt Thanks, Mary. -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com] Sent: Friday, June 20, 2008 3:00 PM To: Barnes, Mary (RICH2:AR00) Cc: Eric Rescorla; secdir@mit.edu; draft-ietf-geopriv-http-location-delivery@tools.ietf.org; ietf@ietf.org; iesg@ietf.org; geopriv@ietf.org Subject: Re: Review of draft-ietf-geopriv-http-location-delivery-07 At Thu, 29 May 2008 07:51:02 -0500, Mary Barnes wrote: > > Hi Eric, > > Thanks for you review and comments. My responses are embedded below > [MB]. > > Mary. > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: Saturday, May 24, 2008 9:01 PM > To: secdir@mit.edu; > draft-ietf-geopriv-http-location-delivery@tools.ietf.org > Cc: ietf@ietf.org; iesg@ietf.org > Subject: Review of draft-ietf-geopriv-http-location-delivery-07 > > $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 > 2008/05/24 15:03:19 ekr Exp $ > > TECHNICAL > > ---snipped------ > 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? > > [MB] This isn't a MUST strength because we had WG discussion/consensus > that we can't mandate LIS behavior. We can make recommendations, but a > LIS may not necessarily follow them. I'm not entirely clear on your > first point as far as "identification by position". [/MB] I mean that knowing where someone is with high enough resolution gives a lot of information about their identity. For instance, if you know that someone is at the AP associated with my house, it seems pretty likely it's me. [MB] But, the identifier doesn't necessarily indicate who the "someone" is. My contrarian example would be my kids are using my home network and I'm in Dublin. How would you know who specifically this location might be associated with? I agree it certainly could. There was a comment on the list yesterday related to this: http://www.ietf.org/mail-archive/web/geopriv/current/msg05895.html So, would changing the text to align with Martin's response be adequate, something like the following: OLD: 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. NEW: Thus, it is RECOMMENDED that the "locationURI" element contain an address that provides indirect access to the LIS to avoid inadvertently revealing a location that could be associated with a Device. Also, an anonymous identifier is RECOMMENDED, such as a local identifier or unlinked pseudonym. [/MB] --snipped-- > Is this MUST implement or MUST use? Don't the next two sentences > imply MUST use? > > [MB] Per the thread above, that text does need some clarification for > consistency. It should be > MUST "implement" and not MUST "use", so I would propose the > following change: > OLD: > The implementation of HTTP as a transport mechanism MUST implement > TLS as described in [RFC2818]. TLS provides message integrity and > privacy 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. > NEW: > The implementation of HTTP as a transport mechanism MUST implement > TLS as described in [RFC2818]. TLS provides message integrity and > privacy between Device and LIS. privacy->confidentiality. Also, only if the right cipher suiotes are used. [MB] It wasn't clear to me what you were suggested we add in terms of cipher suites. Do you just want that general statement or were you thinking of specific cipher suites that would be appropriate for this application? [/MB] ---snipped---- > 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? > > [MB] Per Richard's response on this thread, the IP address spoofing > recommendation is due to HELD using the devices IP address as the > identifier for the device. In this case it is important to have a > recommendation for IP address spoofing. I think the paragraph prior to > those bullets appropriately qualifies the context of that > recommendation. > [/MB] I can't say I really agree with this assertion about the qualification. This still looks to me like a general levy on the access network. [MB] I'm not certain of the concern here. Doesn't the "SHOULD" account for networks that have other mechanisms, thus this isn't an across the board levy. Or is your concern that we don't have the should not situations identified? [/MB] -Ekr _______________________________________________ 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