I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other review
comments.

This document is basically ready, but has issues to consider before publication as a Proposed Standard RFC.

Primary Issues:

The figure makes it clear what a responder is intended to do, but the text does not. At the bottom of page 6, the statement "it MUST copy the request message into the object payload" is not what's intended. The intent is to only copy the part of the request message the figure describes (headers up to a certain point).

The document claims that "middle boxes are not intended to modify the Reflect All object" and "Middle boxes must not modify the Reflect All extension object." The use of lower case must not here is a warning sign. I think all you can say in both cases is "If a middle box modifies the Reflect All extension object, this mechanism does not work." and "There's no way to detect if a middle box modifies the Reflect All extension object" (Unless there _is_, in which case, the document should _definitely_ talk more about that.)

Consider discussing whether there's risk involved if a responder intentionally misrepresents what it received in the Reflect All response. At least note the possibility. Consider also discussing if there's any reason a responder and a middlebox would collaborate to tell the requester something other than what actually appeared at the responder.

I think it would be worth noting that a requester and responder could collaborate to use this new payload space as a tunnel for arbitrary communication (even using other extensions to make sure there was enough _space_ needed for that collaboration) possibly circumventing security mechanisms at, say, enterprise edges. Security ADs - note here that the doc calls out the possibility of using this space for enabling round-trip time calculations, for example.

Nits:

Page 3 2nd paragraph: s/as was when/as it was when/

Section 3 "Use Cases" doesn't look like use cases. It calls out some other extensions and notes that the sender might be interested in what's received when those extensions are used. Consider naming the section "Motivation".

Consider explicitly saying _why_ the Reflect All object MUST be the first object in the Extension Structure.