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

From: Elwyn Davies <[email-masked]>
Date: Sun, 23 Oct 2011 15:11:50 +0100

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-geopriv-deref-protocol-03.txt
Reviewer: Elwyn Davies
Review Date: 23 October 2011
IETF LC End Date: 25 October 2011
IESG Telechat date: (if known)  -

Summary:

Major issues:

Minor issues:
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.  There is a statement in s1 that sort of implies this but 
there is no statement with RFC 2119 language in it to make this 
mandatory in the body of the specification. Further, I am slightly 
confused by the ability to use http scheme URLs, which I assume would 
allow (indeed expect) unsecured HTTP to be used.

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.

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.

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.

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.

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.

Nits/editorial comments:

Abstract: Acronym HELD needs to be expanded here (currently expanded in s1).

s1, Figure 1: (PIcky nit): The infomation carried by the two xxxRequest 
messages is technically a request for xxx rather than the actual object.

s3.2, para 2: s/before before/before/

s5, Figure 5: (Picky nit): The indentation is slightly inconsistent 
<geopriv> element  only indented one space.

Appendix A, Req 12 bullet (b): s/about the identity about the 
Target/about the identity of the  Target/

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 31 Oct 2011 09:33:41 +0800

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:
> document.  
[...]
> 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.

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

> 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 

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.

> <geopriv> element  only indented one space.

You are too observant.  Unfortunately, indenting more causes the longer lines to be too wide.

> Target/about the identity of the  Target/

Done.