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/
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
