Re: [Gen-art] Gen-art last call review : draft-ietf-geopriv-deref-protocol-03

Robert Sparks <rjsparks@nostrum.com> Thu, 03 November 2011 20:54 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5581F0CA9; Thu, 3 Nov 2011 13:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 P1jJnwZ59TRk; Thu, 3 Nov 2011 13:54:39 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EAB0E1F0C35; Thu, 3 Nov 2011 13:54:38 -0700 (PDT)
Received: from [192.168.2.105] (pool-173-74-105-241.dllstx.fios.verizon.net [173.74.105.241]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pA3KsSPG099707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Nov 2011 15:54:32 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D7C1F1B2@SISPE7MB1.commscope.com>
Date: Thu, 03 Nov 2011 15:54:28 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <5DD55DB0-D9ED-4B4E-890C-7BB78DA0A616@nostrum.com>
References: <4EA420A6.4090702@dial.pipex.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D7C1EF94@SISPE7MB1.commscope.com> <F6514D0E-19E1-42AA-9695-0BD09C6967FA@nostrum.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D7C1F1B2@SISPE7MB1.commscope.com>
To: "Thomson, Martin" <Martin.Thomson@commscope.com>
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass (nostrum.com: 173.74.105.241 is authenticated by a trusted mechanism)
Cc: GEOPRIV <geopriv@ietf.org>, "draft-ietf-geopriv-deref-protocol.all@tools.ietf.org" <draft-ietf-geopriv-deref-protocol.all@tools.ietf.org>, General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-art last call review : draft-ietf-geopriv-deref-protocol-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2011 20:54:41 -0000

I'll add that as an RFC editor note and more this into IESG evaluation.

Thanks!

RjS

On Nov 2, 2011, at 5:18 PM, Thomson, Martin wrote:

> On 2011-11-03 at 08:15:01, Robert Sparks wrote:
>> (Including the geopriv list on this reply).
>> 
>> Martin - there's one change you made that I think you need to adjust.
>> In response to Elwyn's suggestion about Appendix A, Req 9 below, 
>> you've added some 2119 text to that appendix which isn't right. Is 
>> there a place you can say what you want to say in the body of the document?
> 
> Yeah, and that was stupid of me.
> 
> The security considerations already contains a statement to this effect:
> 
>   Location URIs MUST only be disclosed to authorized Location
>   Recipients.  
> 
> As for the 2119 language, a reference to the above statement should do:
> 
> OLD:
>   In order to comply with these rules, a Location Recipient	
>   MUST NOT redistribute a location URI without express	
>   permission. Depending on the access control model, the	
>   location URI might be secret (see Section 3.3 of	
>   [RFC5808]).
> NEW:
>   For location URIs that are use possession as a component of
>   authorization, the protecting the secrecy of the URI is
>   necessary in order to comply with this requirement (see
>   Section 6).
> 
> --Martin