Thanks to Corey B. for the SECDIR review.

Thanks to Corey Bonnell for their secdir reviews. 

Normative References:  Using WHATWG standards as normative references can be done, but it does require using a snapshot or other techniques to pinpoint an exact version or time/date.

Thank you for the work on this document. The document is generally clear and technically mature.

Section 7, Caching:

770 >    To reuse a stored response, Section 4 of [HTTP-CACHING] requires that
771 >    the presented target URI and that of the stored response match.  If a
772 >    cache implements the No-Vary-Search extension, this matching
773 >    requirement is also satisfied if the URIs are equivalent modulo URL
774 >    variation config (Section 6) given the stored response's No-Vary-
775 >    Search header.

I don't think this document can be silent on "Updates: 9111." Corey
Bonnell raised exactly this in his SECDIR last-call review, and the
shepherd write-up's answer to question 19 is "It is an extension to
caching (RFC 9111) but does not strictly update it" -- asserted without
much argument. Nidhi's response to Corey on-list was that a new header
field is a well-established extension mechanism that doesn't need the
tag. I don't think that holds up against what RFC 9111 itself says. Its
Section 4 states that "a cache extension can override any of the
requirements listed; see Section 5.2.3," and Section 5.2.3 defines "cache
extension" specifically as a Cache-Control directive, not an arbitrary new
response header field. No-Vary-Search doesn't use that mechanism; it
changes the Section 4 matching condition from outside it.

Julian Reschke raised the identical question during WGLC ("Cache-Control
vs new header field," January 2026), pointing at the same Section 4/5.2.3
text and asking why this wasn't defined as a Cache-Control directive. He
concluded the WG probably wouldn't change course at that point, but asked
that the document "minimally mention this as a design choice/
consideration." I don't see that it did -- "Cache-Control" doesn't appear
anywhere in the current text.

I'm not asking the working group to redesign the field this late. But I'd
ask the authors either to add "Updates: 9111," or to add a sentence
explaining why they consider this outside the extension point that RFC
9111 itself defines.

---

Section 11.1, Normative References:

1083 > [WHATWG-ENCODING]
1084 >            van Kesteren, A., "Encoding Living Standard", 21 May 2026,
1085 >            <https://encoding.spec.whatwg.org/>.  WHATWG

I support Deb Cooley's and Roman Danyliw's comments on the
WHATWG references. encoding.spec.whatwg.org doesn't serve a "21 May 2026"
snapshot at that URL once the living standard has moved on, so a reader
who wants the exact text this RFC was written against has no way to
retrieve it. The shepherd write-up flags this too (Q14,
Q15, Q17), explicitly leaving it for the IESG to judge whether these four
WHATWG references are appropriate as normative, downward references. I'd
like to see that judgment actually made rather than left open. Either
point to an archived/pinned copy of each of the three WHATWG documents
(a W3C TR-style snapshot or a web archive capture would both work), or
explain why the working group believes a bare date is sufficient.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 5.2.1, Table 1:

415 >             +=================+==============================+
416 >             | Input           | Result                       |
417 >             +=================+==============================+
418 >             | No-Vary-Search: | no-vary params: (empty list) |
419 >             | key-order       | vary params: *wildcard*      |
420 >             |                 | vary on key order: false     |
421 >             +-----------------+------------------------------+

Mallory Knodel's Gen-ART review asked for the positive/explicit form
"key-order=?1" to be added here alongside the shorthand "key-order," for
completeness against Table 3, which shows the two as equivalent. That
still isn't in the table.

(revised ballot) 
Thank you to Mallory Knodel for the GENART review

** On the WHATWG references:
   [WHATWG-ENCODING]
              van Kesteren, A., "Encoding Living Standard", 21 May 2026,
              <https://encoding.spec.whatwg.org/>.  WHATWG

   [WHATWG-INFRA]
              van Kesteren, A. and D. Denicola, "Infra Living Standard",
              17 July 2026, <https://infra.spec.whatwg.org/>.  WHATWG

   [WHATWG-URL]
              van Kesteren, A., "URL Living Standard", 6 July 2026,
              <https://url.spec.whatwg.org/>.  WHATWG

It appears that the pattern of referencing specific commits has moved to providing a timestamp.  How does one use these reference dates?  For example, how does one access the 21-May-2026 version of [WHATWG-ENCODING] if a newer version is ever released?

+1 to everyone concerned with external reference stability. Given the extent to which you rely on WHATWG docs, I think that must be addressed (but I'm not going to force a DISCUSS because I'm confident that signal has made it through, pending telechat discussion).

Minor note:

   Note that no Unicode normalization is performed during this
   comparison.  For example, a query string of ?a=%C3%A9 (using the NFC
   encoding of é) and ?a=e%CC%81 (using the NFD encoding of é) will not
   be treated as equivalent.

Not questioning this decision, but it would a nice gesture to the reader to explain why, even super briefly ("because it's unnecessary complexity when one encoding is super uncommon" or "the complexity isn't worth trying to defend against worst case 2x results" or whatever your rationale is).