Telechat Review of draft-ietf-geopriv-deref-protocol-
review-ietf-geopriv-deref-protocol-genart-telechat-davies-2011-11-19-00

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/