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

["Thomson, Martin" <[e-mail]>]

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.
	<http://tools.ietf.org/html/draft-ietf-geopriv-deref-protocol-04>

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.

ADDED:
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.