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-httpbis-unencoded-digest-?? Reviewer: Mallory Knodel Review Date: 2026-01-06 IETF LC End Date: 2026-01-14 IESG Telechat date: Not scheduled for a telechat Summary: The document defines a third set of integrity fields, unencoded-digest/want-unencoded-digest and updates RFC 9530 with this terminology and specifications. Major issues: None. It's a well-written document and the history of the document was so well organized I was really able to appreciate the evolution from gap analysis, through naming changes, and to this final version. Minor issues: Perhaps a consideration for mitigating the security issue introduced by this spec and described in security considerations-- maybe a 'SHOULD NOT' for implementations that use content coding with encryption capabilities. Or another pointer back to RFC 9530 if appropriate. Nits/editorial comments: * Security considerations-- Change 'may' to 'might' in, "A content coding may provide encryption capabilities, for example "aes128gcm" ([RFC8188])." * This is probably my unfamiliarity with convention, so please ignore it if I'm going against established practise, but the first three normative references use a name rather than RFC number, which as a reader led me to believe they were internet-drafts until I arrived at the end and saw the RFC number in the URL of the reference-- this did have an impact on how I read the document, assuming the document's core references were not yet standards. * Section 6: Suggest rewriting, "The second example demonstrates a range request with content negotiation." to "The second example demonstrates a range request that uses content negotiation." for easier comparison between the two examples. * Not entirely clear from an implementation perspective what the relationship would be between Accept-Encoding header field with identity, and the use of Unencoded-digest. It's only briefly mentioned in describing the problem, but perhaps it would be conceptually useful for the reader to elaborate what this might look like in practice in Section 5.