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-x-frame-options-07 Reviewer: Robert Sparks Review Date: 2013-08-08 IETF LC End Date: 2013-08-12 IESG Telechat date: 2013-08-15 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This document is intended to act as a informational reference describing what's already deployed, and not to act as a standard for new implementations to follow. It's obvious that some care has been taken to keep that tone in the text, but there are places where it still looks like a proposed standard. Please make it even more clear who the audience for this document is, and look for places to reinforce that this is documenting what _is_, as opposed to trying to influence what should be. The introduction of this version of the document does a good job of describing what a clickjack attack is. Appendix B is not really adding to that description. I suggest that the two usecases it call out be reduced to a couple of sentences in the introduction as examples, and a reference to a more in-depth treatment of scenarios like them be added for those looking for more information. Section B.3 is different, and doesn't add to the understanding of this document. Again, I suggest pointing to somewhere else that provides an in-depth treatment. (Hopefully, that source would discuss the nested frame issue the security considerations section points out in the context of the this specific configuration page). [FRAME-BUSTING] might be enough, but pointers to something even more rich would certainly be helpful. Here are some suggestions in document order: In the Abstract, I suggest replace "specification" with either "definition" as the introduction uses, or with "the syntax and behavior observed in current deployments". The last paragraph of the introduction reads like standards text. Please consider rewriting it with a tone of history and current fact. Perhaps starting with "In existing implementations, ", and replacing the last sentence with something like "The policy this HTTP header declares is enforced by the browser implementations documented here". Since this is documenting an existing deployed header (not standardizing it), it would be useful to comment whether the existing known implementations allow all the productions of the ABNF described here to be used. For instance, would they all honor X-FRAME-OPTIONS: deny? (While thinking about this, focus on who this document is for.) The last sentence of 2.3.1 as written is an attempt to be a standard, and is an odd use of 2119. I suggest rewriting it as a warning about what happens with existing plugins that ignore the policy carrid in the header. That keeps the message aligned with documenting what exists. The first sentence of 2.3.2 is not adding anything to the document. I suggest deleting it. The second sentence is placing an implementation requirement again. Please consider rewriting as an observation of what existing things do, calling out the ramifications of the ones that behave differently. Similarly, the first paragraphs of Section 2.3.2.1 is written to affect new implementation, not document existing implementation. They could be re-tuned as above. The third paragraph is good history The last sentence of 2.3.2.2 should not say "replace this document" - this document is informational documentation about existing deployments. CSP1.1 won't Obsolete or Replace this document. Rather it should say something like "it is expected that newer implementations will use it rather than the mechanisms documented here". Nit: s/does support only one/only supports one/ Do the known implementations follow the pattern described in 2.3.2.3? Saying something would help tie this to being information about the known deployment rather than trying to constrain new development. Nit: If Appendix B is kept, please expand CSRF (and consider re-pointing to a reference)