The No-Vary-Search HTTP Caching Extension
draft-ietf-httpbis-no-vary-search-09

[Ballot comment]
+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).

IANA understands that this document's IANA Considerations section is now creating a new registry called "No-Vary-Search Dictionary Keys" in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" group at https://www.iana.org/assignments/http-fields. The registration procedure will be IETF Review, and the initial contents will be

Key Description Reference
key-order Indicates if query parameter order affects caching this document
params A list of query parameters that do not affect caching this document
except A list of query parameters that affect caching this document

[Ballot comment]
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 >            .  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.

[Ballot comment]
(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,
              .  WHATWG

  [WHATWG-INFRA]
              van Kesteren, A. and D. Denicola, "Infra Living Standard",
              17 July 2026, .  WHATWG

  [WHATWG-URL]
              van Kesteren, A., "URL Living Standard", 6 July 2026,
              .  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?

[Ballot comment]
** On the WHATWG references:
  [WHATWG-ENCODING]
              van Kesteren, A., "Encoding Living Standard", 21 May 2026,
              .  WHATWG

  [WHATWG-INFRA]
              van Kesteren, A. and D. Denicola, "Infra Living Standard",
              17 July 2026, .  WHATWG

  [WHATWG-URL]
              van Kesteren, A., "URL Living Standard", 6 July 2026,
              .  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?

[Ballot comment]
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.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-httpbis-no-vary-search-06. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Hypertext Transfer Protocol (HTTP) Field Name Registry located at:

https://www.iana.org/assignments/http-fields/

a single new registration will be made as follows:

Field Name: No-Vary-Search
Status: permanent
Structured Type: Dictionary
Reference: [ RFC-to-be ]
Comments:

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

We understand that this is the only action required to be completed upon†approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-07-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-no-vary-search@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, mbishop@evequefou.be, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The No-Vary-Search HTTP Caching Extension) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'The No-Vary-Search HTTP Caching Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-07-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines an extension to HTTP Caching, changing how
  URI query parameters impact caching.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-no-vary-search/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The input on this document has mainly been strong from a few (4-5) individuals who
worked hard on reviewing caching aspects and consistency with other documents.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The one rough point I'll call out is
one issue on the structured field usage (https://github.com/httpwg/http-extensions/issues/3287)
that elicited a lot of discussion. This led to a change that had agreement by the group,
but one of the commenters preferred a different name for parameters
("include/exclude" vs "params/except"), and there was also discussion around
changing the name of the header field. However, the chairs felt that this was
in the realm of editorial / bike-shedding issues. Keeping the current name and
parameter names are partly driven by trying to reduce implementation churn, but
also based on the fact that the current names already went through bike-shedding
and churn prior to document adoption in W3C TPAC discussions, and has been discussed
in years past on the IETF WG list without coming to consensus on a different name.
It is not clear that opening a renaming discussion would come to a consensus,
and doesn't make a functional difference.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeal threatened or extreme discontent expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document has a history of implementation by Google; Firefox also has publicly
documented intent to implement and current prototyping work. Other browsers have
mentioned plans to implement but I have not heard specific timelines.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

As mentioned above, the document has also been discussed in W3C venues, and
many of the HTTP WG participants who were active in those document also participate there.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal type review required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal language. This does use HTTP structured fields.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I believe this document is ready to be handed off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This is mainly an HTTP area of work, and has the necessary reviews within the WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard, which is appropriate for this extension for HTTP caching.
Datatracker does reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, authors have been contacted and no IPR has been disclosed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the authors are willing to be listed. Two of the authors (Jeremy Roman and
Domenic Denicola) are no longer actively involved in day jobs associated with this
work, but have expressed a desire to still be listed and will finish the process.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The main nits that show up are about normative references to WHATWG documents.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

There are 4 normative references to WHATWG documents; I'll let the IESG confirm
if these are appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

The only documents potentially in this category are the WHATWG docs.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No normative references to drafts.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document doesn't update the status of any RFC. It is an extension to caching
(RFC 9111) but does not strictly update it.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The one IANA action is to register the HTTP field name No-Vary-Search. This is
appropriate for this document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The input on this document has mainly been strong from a few (4-5) individuals who
worked hard on reviewing caching aspects and consistency with other documents.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The one rough point I'll call out is
one issue on the structured field usage (https://github.com/httpwg/http-extensions/issues/3287)
that elicited a lot of discussion. This led to a change that had agreement by the group,
but one of the commenters preferred a different name for parameters
("include/exclude" vs "params/except"), and there was also discussion around
changing the name of the header field. However, the chairs felt that this was
in the realm of editorial / bike-shedding issues. Keeping the current name and
parameter names are partly driven by trying to reduce implementation churn, but
also based on the fact that the current names already went through bike-shedding
and churn prior to document adoption in W3C TPAC discussions, and has been discussed
in years past on the IETF WG list without coming to consensus on a different name.
It is not clear that opening a renaming discussion would come to a consensus,
and doesn't make a functional difference.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeal threatened or extreme discontent expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document has a history of implementation by Google; Firefox also has publicly
documented intent to implement and current prototyping work. Other browsers have
mentioned plans to implement but I have not heard specific timelines.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

As mentioned above, the document has also been discussed in W3C venues, and
many of the HTTP WG participants who were active in those document also participate there.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal type review required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal language. This does use HTTP structured fields.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I believe this document is ready to be handed off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This is mainly an HTTP area of work, and has the necessary reviews within the WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard, which is appropriate for this extension for HTTP caching.
Datatracker does reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, authors have been contacted and no IPR has been disclosed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the authors are willing to be listed. Two of the authors (Jeremy Roman and
Domenic Denicola) are no longer actively involved in day jobs associated with this
work, but have expressed a desire to still be listed and will finish the process.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The main nits that show up are about normative references to WHATWG documents.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

There are 4 normative references to WHATWG documents; I'll let the IESG confirm
if these are appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

The only documents potentially in this category are the WHATWG docs.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No normative references to drafts.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document doesn't update the status of any RFC. It is an extension to caching
(RFC 9111) but does not strictly update it.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The one IANA action is to register the HTTP field name No-Vary-Search. This is
appropriate for this document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The input on this document has mainly been strong from a few (4-5) individuals who
worked hard on reviewing caching aspects and consistency with other documents.
Others had no objections raised.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no particularly rough points. The one point I'll call out is
one issue on the structured field usage (https://github.com/httpwg/http-extensions/issues/3287)
that elicited a lot of discussion. This led to a change that had agreement by the group,
but one of the commenters preferred a different name for parameters
("include/exclude" vs "params/exclude"), and there was also discussion around
changing the name of the header field. However, the chairs felt that this was
in the realm of editorial / bike-shedding issues. Keeping the current name and
parameter names are partly driven by trying to reduce implementation churn, but
also based on the fact that the current names already went through bike shedding
and churn prior to document adoption in W3C TPAC discussions, and has been discussed
in years past on the IETF WG list without coming to consensus on a different name.
It is not clear that opening a renaming discussion would come to a consensus,
and won't make a functional difference.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeal threatened or extreme discontent expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document has a history of implementation by Google; Firefox also has publicly
documented intent to implement and current prototyping work. Other browsers have
mentioned plans to implement but I have not heard specific timelines.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

As mentioned above, the document has also been discussed in W3C venues, and
many of the HTTP WG participants who were active in those document also participate there.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal type review required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal language. This does use HTTP structured fields.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I believe this document is ready to be handed off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This is mainly an HTTP area of work, and has the necessary reviews within the WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard, which is appropriate for this extension for HTTP caching.
Datatracker does reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, authors have been contacted and no IPR has been disclosed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the authors are willing to be listed. Two of the authors (Jeremy Roman and
Domenic Denicola) are no longer actively involved in day jobs associated with this
work, but have expressed a desire to still be listed and will finish the process.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The main nits that show up are about normative references to WHATWG documents.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

There are 4 normative references to WHATWG documents; I'll let the IESG confirm
if these are appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

The only documents potentially in this category are the WHATWG docs.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No normative references to drafts.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document doesn't update the status of any RFC. It is an extension to caching
(RFC 9111) but does not strictly update it.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The one IANA action is to register the HTTP field name No-Vary-Search. This is
appropriate for this document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The input on this document has mainly been strong from a few (4-5) individuals who
worked hard on reviewing caching aspects and consistency with other documents.
Others had no objections raised.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

There were no particularly rough points. The one points I'll call out is
one issue on the structured field usage (https://github.com/httpwg/http-extensions/issues/3287)
that elicited a lot of discussion. This led to a change that had agreement by the group,
but one of the commenters preferred a different name for parameters
("include/exclude" vs "params/exclude"), and there was also discussion around
changing the name of the header field. However, the chairs felt that this was
in the realm of editorial / bike-shedding issues. Keeping the current name and
parameter names are partly driven by trying to reduce implementation churn, but
also based on the fact that the current names already went through bike shedding
and churn prior to document adoption in W3C TPAC discussions. It is not clear
that opening a renaming discussion would come to a consensus, and won't make
a functional difference.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No appeal threatened or extreme discontent expressed.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

This document has a history of implementation by Google; other browsers have
mentioned plans to implement but I have not heard specific timelines.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

As mentioned above, the document has also been discussed in W3C venues, and
many of the HTTP WG participants who were active in those document also participate there.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

No formal type review required.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal language. This does use HTTP structured fields.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, I believe this document is ready to be handed off.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This is mainly an HTTP area of work, and has the necessary reviews within the WG.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard, which is appropriate for this extension for HTTP caching.
Datatracker does reflect this.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, authors have been contacted and no IPR has been disclosed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, the authors are willing to be listed. Two of the authors (Jeremy Roman and
Domenic Denicola) are no longer actively involved in day jobs associated with this
work, but have expressed a desire to still be listed and will finish the process.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

The main nits that show up are about normative references to WHATWG documents.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

There are 4 normative references to WHATWG documents; I'll let the IESG confirm
if these are appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All references are available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

The only documents potentially in this category are the WHATWG docs.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No normative references to drafts.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document doesn't update the status of any RFC. It is an extension to caching
(RFC 9111) but does not strictly update it.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The one IANA action is to register the HTTP field name No-Vary-Search. This is
appropriate for this document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

No new registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/