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-websec-strict-transport-sec-11 Reviewer: Ben Campbell Review Date: 2012-07-24 IETF LC End Date: 2012-07-25 Summary: This draft is almost ready for publication as a proposed standard, but there are a few issues that should be considered first. *** Major issues: None *** Minor issues: -- Does this draft update any other RFCs (e.g. 2616 or 2818)? If so, that should be explicitly flagged and mentioned in the abstract. -- I did not find any guidance on how to handle UAs that do not understand this extension. I don't know if this needs to be normative, but the draft should at least mention the possibility and implications. -- How should a UA handle potential conflicts between a the policy record that includes the includeSubdomain, and any records for subdomains that might have different parameters? -- section 6.1: The draft mentions that directives may be extended, but defers creation of an IANA registry to the time of first extension. IANA registries are not expensive; I suggest it be created now. If there's a good reason not to, then the draft should still address the specification policy for extensions. Also, do you expect that some future directive might need to have a "required-to-understand" status? Given that this is a security-affecting extension, it seems likely. If so, then the mechanism for expressing that needs to be defined in this draft. -- section 7.2: Am I correct to assume that the server must never just serve the content over a non-secure connection? If so, it would be helpful to mention that, maybe even normatively. -- section 8.4: Does this imply a duty for compliant UAs to check for revocation one way or another? *** Nits/editorial comments: -- idnits reports an uncited reference: == Unused Reference: 'RFC6376' is defined on line 1709, but no explicit reference was found in the text -- section 1.2: The description of indented notes is almost precisely the opposite of how they are described in the RFC editor's style guide. It describes them as "parenthetical" notes, which is how experienced RFC readers are likely to perceive them. While it doesn't say so explicitly, I think putting normative text in parenthetical notes should be avoided. If these are intended to be taken more strongly than that (and by the description, I take it they should be taken more strongly than the surrounding text), then I suggest choosing a stronger prefix than "NOTE:" -- section 7: Does the reference to I-D.ietf-tls-ssl-version3 indicate a requirement for SSL3? Also, that's a long expired draft, even for an informational reference. -- section 8.2, paragraph 5 (first non-numbered paragraph after numbered list) To be pedantic, this could be taken to mean a congruent match only applies if the includeSubdomains flag is not present. I assume it's intended to apply whether or not the flag is present. -- section 12 and subsections: I was surprised to see more apparently normative material after the non-normative guidance sections. I think it would improve the organization to put this closer to the normative rules for UAs. -- section 14.1, 4th paragraph (first non-bulleted paragraph following bullet list) This issue is only true for proxies that act as a TLS MiTM, right? Would proxies that tunnel TLS via the CONNECT method have this issue? _______________________________________________ Gen-art mailing list Gen-art@xxxxxxxx https://www.ietf.org/mailman/listinfo/gen-art