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

Robert Sparks <> Wed, 02 November 2011 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67F1011E817E; Wed, 2 Nov 2011 14:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.589
X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7QQ442pQXgqG; Wed, 2 Nov 2011 14:15:33 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id B7FE711E811F; Wed, 2 Nov 2011 14:15:33 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id pA2LF19U013715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Nov 2011 16:15:06 -0500 (CDT) (envelope-from
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Robert Sparks <>
In-Reply-To: <>
Date: Wed, 02 Nov 2011 16:15:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Thomson, Martin" <>
X-Mailer: Apple Mail (2.1084)
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: GEOPRIV <>,, General Area Review Team <>
Subject: Re: [Gen-art] Gen-art last call review : draft-ietf-geopriv-deref-protocol-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Nov 2011 21:15:34 -0000

(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?


On Oct 30, 2011, at 8:33 PM, Thomson, Martin wrote:

> Hi Elwyn,
> Thanks for going through this in detail.
> I see that you've found a few holes in the appendix.  I've attempted to correct those.  More detail on that below.
> I've posted -04 with the changes.
> 	<>
> On 2011-10-24 at 01:11:50, Elwyn Davies wrote:
>> Appendix A: Compliance statement for Req 4:  The Compliance statement 
>> states that use of HTTPS from Location Recipient to LS is mandated.  I 
>> cannot find any MUST statement to this effect in the main body of the 
>> document.  
> [...]
>> Appendix A: Compliance statement for Req 4:  Use of the HTTP over TLS 
>> PKI infrastructure, would I suppose be implicit if the previous 
>> comment were fixed.  However, it might be good to make this explicit.
> The MUST doesn't exist.  There was discussion about mandatory TLS that ended with the text in the body, but the appendix was missed in the edit.  The conclusion was that we wouldn't prevent use of http:, but the risks needed to made clear.  I hope that this was achieved.
> I've added a little note that should make this clearer:
>   Though discouraged, using unsecured http: URIs is permitted.
>   Using unsecured HTTP is likely to result in non-compliance
>   with this requirement.
>> Appendix A: Compliance statement for Req 9:  Again, the body of the 
>> specification is silent on what a Location Reciepient may or may not 
>> do with a Location URL.  Clearly any constraints are not enforceable 
>> within the context of the HELD protocol but it is probably desirable 
>> to note the policy of non-propagation implied by Req 9.
> That's a good idea.
>> Appendix B: Compliance statement for Req C3: Compliance for Auth by 
>> Possession seems somewhat dubious.  Derogation due to the requirement 
>> for expiry is discussed in the body of the document.
> The idea that there are two distinct models for authorization is a little bit misleading.  A URI that is authorized by possession can still be cancelled using the mechanism described in the policy-uri draft.
> An implementation that doesn't support cancellation is not going to be compliant, but that's not a fault in the specification.
>> Appendix B: Compliance statement for Req C8: The explicit requirement 
>> for a minimum of 128 bits of randomness does not appear in the body of 
>> the document.  Since the requirements doc is informational, this needs 
>> to be made explicit in the main body of the doc.
> The amount of randomness is not specifically identified since it depends on a number of factors that change over time, such as the number of valid location URIs, the validity period of those URIs and the rate that guesses can be made.
>> Appendix C: Compliance statement for Req D5:  See comments above on 
>> App A, Req 4.  May be a contradiction here: App A appears to require a 
>> MUST; this compliance implies a RECOMMENDS and possibility of http.
>> Needs sorting out.
> Sorted out as described above.
>> Abstract: Acronym HELD needs to be expanded here (currently expanded 
>> in s1).
> Fixed.
>> s1, Figure 1: (PIcky nit): The infomation carried by the two 
>> xxxRequest messages is technically a request for xxx rather than the 
>> actual object.
> Good point; added "for " to each parenthetical.
>> s3.2, para 2: s/before before/before/
>> s5, Figure 5: (Picky nit): The indentation is slightly inconsistent 
>> <geopriv> element  only indented one space.
> You are too observant.  Unfortunately, indenting more causes the longer lines to be too wide.
>> Appendix A, Req 12 bullet (b): s/about the identity about the 
>> Target/about the identity of the  Target/
> Done.