IETF Last Call Review of draft-ietf-httpbis-unencoded-digest-03
review-ietf-httpbis-unencoded-digest-03-genart-lc-knodel-2026-01-06-00

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

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

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.