IETF Logo Mail Archive

RE: Review of draft-ietf-geopriv-http-location-delivery

"Thomson, Martin" <Martin.Thomson@andrew.com> Tue, 16 June 2009 23:20 UTC

Return-Path: <Martin.Thomson@andrew.com>
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 DDAC93A6BAA for <ietf@core3.amsl.com>; Tue, 16 Jun 2009 16:20: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.059, 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 RMsz3ONdhAGg for <ietf@core3.amsl.com>; Tue, 16 Jun 2009 16:20:39 -0700 (PDT)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BA91B3A6C83 for <ietf@ietf.org>; Tue, 16 Jun 2009 16:20:39 -0700 (PDT)
X-SEF-Processed: 5_0_0_910__2009_06_16_18_25_45
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 16 Jun 2009 18:25:45 -0500
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 18:04:02 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Subject: RE: Review of draft-ietf-geopriv-http-location-delivery
Date: Tue, 16 Jun 2009 18:04:00 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF105E7D2E5@AHQEX1.andrew.com>
In-Reply-To: <4A372104.1050206@bbn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-geopriv-http-location-delivery
Thread-Index: AcnuO9poPLdGy/wQQiilurE+7Kkk5QAmriWA
References: <BLU137-W24F8D6BFA3482E7A3F7E2493460@phx.gbl> <E51D5B15BFDEFD448F90BDD17D41CFF105E1B418@AHQEX1.andrew.com> <4A372104.1050206@bbn.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Richard Barnes <rbarnes@bbn.com>
X-OriginalArrivalTime: 16 Jun 2009 23:04:02.0159 (UTC) FILETIME=[BD359FF0:01C9EED6]
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, Cullen Jennings <fluffy@cisco.com>, ietf@ietf.org, mary.barnes@nortel.com
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/mail-archive/web/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>
X-List-Received-Date: Tue, 16 Jun 2009 23:20:41 -0000

This is probably better than my phrasing, particularly the MAY piece.

I would like to make the consequences of ignoring the "SHOULD" clear though:

   A Device that conforms to this specification MAY choose not to
   support for HTTP authentication [RFC2617] or cookies [RFC2965].
   Because the Device and the LIS may not necessarily have a prior
   relationship, the LIS SHOULD NOT require a Device to authenticate,
   either using the above HTTP authentication methods or TLS client
   authentication.  Unless all Devices that access a LIS can be expected
   to be able to authenticate in a certain fashion, denying access to
   location information could prevent a Device from using
   location-dependent services, such as emergency calling.

> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: Tuesday, 16 June 2009 2:35 PM
> To: Thomson, Martin
> Cc: Bernard Aboba; ietf@ietf.org; Cullen Jennings;
> mary.barnes@nortel.com
> Subject: Re: Review of draft-ietf-geopriv-http-location-delivery
> 
> Martin:
> 
> Regarding #2, I would feel more comfortable with your text if it had
> the
> strength of a RECOMMENDATION.  Making a specific policy configuration a
>   MUST NOT doesn't make sense.  Also, this discussion is missing the
> possibility of client authentication in TLS, which falls under the same
> recommendation.  Suggested text follows:
> 
> > Old:
> >
> > The LIS MUST NOT rely on device support for cookies [RFC2965] or use
> > Basic or Digest authentication [RFC2617].
> >
> >
> > New (Thomson):
> >
> > A Device that conforms to this specification is not required to
> > support HTTP authentication [RFC2617] or cookies [RFC2965].  Because
> > the Device and LIS do not necessarily have a prior relationship and
> > this protocol is suited to a range of networks, there is no common
> > authentication mechanism that can be used for any access network.
> > A LIS MUST NOT deny access to location information based on the
> > absence of Device authentication, unless it can be guaranteed that
> > all Devices in the access network are aware that authentication is
> > required.
> 
> New (Barnes):
> 
> A Device that conforms to this specification MAY omit support for HTTP
> authentication [RFC2617] or cookies [RFC2965].  Because the Device and
> the LIS may not necessarily have a prior relationship, it is
> RECOMMENDED
> that that the LIS not require a Device to authenticate, either using
> the
> above HTTP authentication methods or TLS client authentication.
> 
> --Richard

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

v2.23.0 | Report a Bug | By Email