I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-cose-hpke-?? Reviewer: Mallory Knodel Review Date: 2026-10-26 IETF LC End Date: 2026-10-22 IESG Telechat date: Not scheduled for a telechat Summary: The document defines the use of HPKE with COSE. Checking in on other reviews and also reviews of ietf-hpke-hpke there are some open, consequential issues that aren't yet addressed, so perhaps timing and content of this draft is dependent on that one. Therefore, I've intentionally kept my feedback very surface level and focussed on readability. Major issues: None Minor issues: None Nits/editorial comments: * It seems to me that the IANA section might be better as a table instead of a long, linear outline. * Might Section 5 Examples be an appendix, before Testvectors [sic]? * "Test Vectors" seems to be two words in other documents. * I expected this document to follow more or less the outline of RFC9180. It's okay that it doesn't, but perhaps a paragraph at the end of the introduction will better help the reader understand the structure and flow of the document (and why various choices were made). Furthermore in each of the sections 3, 4 and 5 it might be helpful to briefly explain why subsections appear in the order that they do. In general I found that I had to essentially read the entire document to understand why it is organized the way that it is, and I'm still somewhat left with questions. You could, say, extend 3.1 with some additional architectural context explaining why both modes are specified, how they relate to existing mechanisms, and what security properties or tradeoffs implementers should consider, eg move up the "security design rationale" into the overview.