Skip to main content

Targeted HTTP Cache Control
draft-ietf-httpbis-targeted-cache-control-04

Revision differences

Document history

Date Rev. By Action
2022-04-28
04 Mark Nottingham This document now replaces draft-cdn-control-header instead of None
2022-03-14
04 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-02-28
04 (System) RFC Editor state changed to AUTH48
2022-01-30
04 Barry Leiba Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing
2022-01-30
04 Barry Leiba Assignment of request for Last Call review by ARTART to Harald Alvestrand was marked no-response
2022-01-28
04 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2022-01-28
04 Tero Kivinen Assignment of request for Last Call review by SECDIR to Klaas Wierenga was marked no-response
2022-01-27
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-01-27
04 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2022-01-26
04 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2022-01-26
04 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-01-26
04 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-01-24
04 (System) RFC Editor state changed to EDIT
2022-01-24
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-01-24
04 (System) Announcement was received by RFC Editor
2022-01-24
04 (System) IANA Action state changed to In Progress
2022-01-24
04 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-01-24
04 Cindy Morgan IESG has approved the document
2022-01-24
04 Cindy Morgan Closed "Approve" ballot
2022-01-24
04 Cindy Morgan Ballot approval text was generated
2022-01-24
04 Francesca Palombini IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2022-01-23
04 (System) Removed all action holders (IESG state changed)
2022-01-23
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-01-23
04 Mark Nottingham New version available: draft-ietf-httpbis-targeted-cache-control-04.txt
2022-01-23
04 (System) New version approved
2022-01-23
04 (System) Request for posting confirmation emailed to previous authors: Mark Nottingham , Stephen Ludin , Yuchen Wu
2022-01-23
04 Mark Nottingham Uploaded new revision
2022-01-20
03 (System) Changed action holders to Mark Nottingham, Stephen Ludin, Yuchen Wu (IESG state changed)
2022-01-20
03 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2022-01-20
03 Lars Eggert
[Ballot comment]
Thanks to Elwyn Davies for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/LgEyhFr95SkeHZGTiJbsM2xKO7I).

-------------------------------------------------------------------------------
All comments below are about very minor …
[Ballot comment]
Thanks to Elwyn Davies for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/LgEyhFr95SkeHZGTiJbsM2xKO7I).

-------------------------------------------------------------------------------
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.

"Table of Contents", paragraph 2, nit:
> layers of caching. For example, a Web site might use a cache on the origin se
>                                  ^^^^^^^^
Nowadays, it's more common to write this as one word.

Section 1. , paragraph 5, nit:
> ield (hereafter, "targeted field") is a HTTP response header field that has t
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 2.2. , paragraph 1, nit:
> eceives a response with one or more of of the header field names on its targe
>                                    ^^^^^
Possible typo: you repeated a word.
2022-01-20
03 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2022-01-19
03 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-01-19
03 Warren Kumari [Ballot comment]
Much thanks to Joel for the OpsDir review, and thanks to the authors and WG for this document...
2022-01-19
03 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2022-01-19
03 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2022-01-18
03 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from No Record
2022-01-18
03 Robert Wilton
[Ballot comment]
Hi,

Thanks for this document, and thanks Joel for the opsdir review.

A few comments:

1.
  Because it is often desirable to …
[Ballot comment]
Hi,

Thanks for this document, and thanks Joel for the opsdir review.

A few comments:

1.
  Because it is often desirable to control these different classes of
  caches separately, some means of targeting directives at them is
  necessary.

As a reader that is not familiar with the reasons (but I could potentially guess), I was wondering whether it would be help to add a sentence to explain why this might be done?


2. I felt a bit ambiguous to me about what directives are actually allowed in a cache directive:

Section 2.1 states:
  "Targeted fields are Dictionary Structured Fields (Section 3.2 of
  [STRUCTURED-FIELDS]).  Each member of the dictionary is a cache
  response directive from the Hypertext Transfer Protocol (HTTP) Cache
  Directive Registry (https://www.iana.org/assignments/http-cache-
  directives/)."

  and

  If a targeted field in a given response is empty, or a parsing error
  is encountered, that field MUST be ignored by the cache (i.e., it
  behaves as if the field were not present, likely falling back to
  other cache control mechanisms present)

Section 3.1 states:

  Cache-Control: no-store
  CDN-Cache-Control: none

  (note that 'none' is not a registered cache directive; it is here to
  avoid sending a header field with an empty value, which would be
  ignored)

It was left somewhat unclear to me whether an implementation is allowed to use a cache directive that is not defined in the "Cache Directive Registry", noting that the example in 3.1 seems to suggest this is allowed.  Perhaps the document would be clearer if this was explicitly stated in section 2.1?


Some nits:

more of of => more of

\[CDN-Cache-Control]]) => strange escape or extra ].

"directive" to "Cache directives" in a few more places for consistency?  Particularly in section 2.1, I thought that this might make the text slightly better.

Thanks,
Rob
2022-01-18
03 Robert Wilton Ballot comment text updated for Robert Wilton
2022-01-18
03 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2022-01-18
03 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2022-01-18
03 Zaheduzzaman Sarker
[Ballot comment]
Thanks for working on this specification.

I have only one observation - CND-Cache-Control is a targeted for CDN caches, however, my understanding is …
[Ballot comment]
Thanks for working on this specification.

I have only one observation - CND-Cache-Control is a targeted for CDN caches, however, my understanding is this can end up in the clients. There is no description or reference to description about what a client supposed to handle this (obvious is to ignore). It would be great if we can write something about it or refer to the client behavior description elsewhere. If my understanding is wrong that this header field will never reach any client then I would say it requires some wording in the specification to clearly state that.
2022-01-18
03 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-01-17
03 Benjamin Kaduk
[Ballot comment]
Thanks for responding to the gen-art reviewer with the remark about the
"publisher site" link for the [AGE-PENALTY] reference.  I would not have …
[Ballot comment]
Thanks for responding to the gen-art reviewer with the remark about the
"publisher site" link for the [AGE-PENALTY] reference.  I would not have
followed that link without the extra nudge, and wonder if it could be
incorporated somehow into the document.  Perhaps the RFC Editor has
thoughts...

I put some very minor editorial thoughts in
https://github.com/httpwg/http-extensions/pull/1890 .

Section 2.1

  Parameters received on directives are to be ignored, unless other
  handling is explicitly specified.

I assume that the "other handling" could be specified in many ways,
including but not limited to some future RFC and explicit administrator
configuration.  (Which, to be clear, suggests no change to this text.)

Section 5

  The ability to carry multiple caching policies on a response can
  result in confusion about how a response will be cached in different
  systems, if not used carefully.  [...]

The "if not used carefully" is probably not how I would have phrased it.
It's possible to try to use it carefully and still (Murphy's Law) have
things go awry, after all.  I don't have any suggestions other than just
removing the clause, though, which I recognize is a pretty heavy hammer
-- some additional clarification here is worthwhile, if we can wordsmith
it.

NITS

Section 1

  Because it is often desirable to control these different classes of
  caches separately, some means of targeting directives at them is
  necessary.

This feels a bit like begging the question -- it doesn't actually
present any supporting evidence for separation of control as desirable;
rather, it just assumes that it is desirable.  Some example of where
divergent behavior by different caches is useful might be helpful.

Section 2.2

  When a cache that implements this specification receives a response
  with one or more of of the header field names on its target list, the
  cache MUST select the first (in target list order) field with a
  valid, non-empty value and use its value to determine the caching
  policy for the response, and MUST ignore the Cache-Control and
  Expires header fields in that response, unless no valid, non-empty
  value is available from the listed header fields.

As I understand it, the final "unless no valid, non-empty value is
available" is redundant with the previous "MUST select the first (...)
field with a valid, non-empty value and use its value".  But it seems
kind of confusing to have that listed twice, as it invites the reader to
invent some other reason for having the second statement.  Is it safe to
just drop the final clause of the sentence?
2022-01-17
03 Benjamin Kaduk [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk
2022-01-17
03 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-01-14
03 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-01-14
03 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-01-14
03 John Scudder
[Ballot comment]
Thanks for this clear and useful document; also for the helpful shepherd writeup. I have a nit, and a question:

1. §2.1 Nit: …
[Ballot comment]
Thanks for this clear and useful document; also for the helpful shepherd writeup. I have a nit, and a question:

1. §2.1 Nit:

  Implementations SHOULD NOT consume values that violate these inferred
  constraints.  For example, a consuming implementation were to coerce
  a max-age with a decimal value into an integer would behave
  differently than other implementations, potentially causing
  interoperability issues.

I think “were to coerce” should be “that were to coerce”.

2. I have a question regarding one of the examples in §3.1:

  Whereas these would prevent all caches except for CDN caches from
  storing the response:

  Cache-Control: no-store
  CDN-Cache-Control: none

  (note that 'none' is not a registered cache directive; it is here to
  avoid sending a header field with an empty value, which would be
  ignored)

As a httpbis naïf, I might have guessed that a field that contains no registered directive might be considered equivalent to an empty field, in which case according to the rules of §2.2 the field would be ignored and the Cache-Control field would be respected instead.

Your example makes it clear that guess would be wrong, thank you. My question is whether it’s completely obvious to those conversant with the subject area, that it’s fine to just bung a random string into the field? For that matter, supposing someone came along and registered 'none' at some point in the future. Might that cause the example case to break?
2022-01-14
03 John Scudder Ballot comment text updated for John Scudder
2022-01-14
03 John Scudder
[Ballot comment]
Thanks for this clear and useful document; also for the helpful shepherd writeup. I have a nit, and a question:

1. §2.1 Nit: …
[Ballot comment]
Thanks for this clear and useful document; also for the helpful shepherd writeup. I have a nit, and a question:

1. §2.1 Nit:

  Implementations SHOULD NOT consume values that violate these inferred
  constraints.  For example, a consuming implementation were to coerce
  a max-age with a decimal value into an integer would behave
  differently than other implementations, potentially causing
  interoperability issues.

I think “were to coerce” should be “that were to coerce”.

2. I have a question regarding one of the examples in §3.1:

  Whereas these would prevent all caches except for CDN caches from
  storing the response:

  Cache-Control: no-store
  CDN-Cache-Control: none

  (note that 'none' is not a registered cache directive; it is here to
  avoid sending a header field with an empty value, which would be
  ignored)

As a httpbis naïf, I might have guessed that a field that contains no registered directive might be considered equivalent to an empty field, in which case according to the rules of §2.2 the field would be ignored and the Cache-Control field would be respected instead.

Your example makes it clear that guess would be wrong, thank you. My question is whether it’s completely obvious to those conversant with the subject area, that it’s fine to just bung a random string into the field?
2022-01-14
03 John Scudder Ballot comment text updated for John Scudder
2022-01-14
03 John Scudder
[Ballot comment]
Thanks for this clear and easy-to-read document; also for the helpful shepherd writeup. I have a nit, and a question:

1. §2.1 Nit: …
[Ballot comment]
Thanks for this clear and easy-to-read document; also for the helpful shepherd writeup. I have a nit, and a question:

1. §2.1 Nit:

  Implementations SHOULD NOT consume values that violate these inferred
  constraints.  For example, a consuming implementation were to coerce
  a max-age with a decimal value into an integer would behave
  differently than other implementations, potentially causing
  interoperability issues.

I think “were to coerce” should be “that were to coerce”.

2. I have a question regarding one of the examples in §3.1:

  Whereas these would prevent all caches except for CDN caches from
  storing the response:

  Cache-Control: no-store
  CDN-Cache-Control: none

  (note that 'none' is not a registered cache directive; it is here to
  avoid sending a header field with an empty value, which would be
  ignored)

As a httpbis naïf, I might have guessed that a field that contains no registered directive might be considered equivalent to an empty field, in which case according to the rules of §2.2 the field would be ignored and the Cache-Control field would be respected instead.

Your example makes it clear that guess would be wrong, thank you. My question is whether it’s completely obvious to those conversant with the subject area, that it’s fine to just bung a random string into the field?
2022-01-14
03 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2022-01-13
03 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. Even not being a specialist, the interest of the document is clear (and the …
[Ballot comment]
Thank you for the work put into this document. Even not being a specialist, the interest of the document is clear (and the document itself is easy to read).

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tommy Pauly for the shepherd's write-up including the section about the WG consensus (and be clear about that I-D is mainly the work of 3 CDNs).

I hope that this helps to improve the document,

Regards,

-éric


Generic comment: while the document appears to be very generic (barring my comment below), it actually only requests IANA for a "CDN-Cache-Control" targeted header, I.e., should this be reflected in the title ?

-- Section 1 --
Is there any reason why the enterprise caches/proxies are not mentioned in the first § ?

-- Section 2.2 --
As the target list is merely a local decision, why are the behaviours specified as a "MUST" and not as a "SHOULD" ? I.e., after all it is all local decisions and there could be local constraints/restrictions. There is also no negotiation between the cache and its upstream cache/origin that could contractually bind the 2 parties.

== NITS ==

-- Section 1 --
In "a Web site", does "web" really deserve being capitalised ?

-- Section 2.1 --
In "as if the field were not present" should field be in the plural form ?
2022-01-13
03 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-01-05
03 Amy Vezza Placed on agenda for telechat - 2022-01-20
2022-01-05
03 Francesca Palombini Ballot has been issued
2022-01-05
03 Francesca Palombini [Ballot Position Update] New position, Yes, has been recorded for Francesca Palombini
2022-01-05
03 Francesca Palombini Created "Approve" ballot
2022-01-05
03 Francesca Palombini IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2022-01-04
03 (System) Changed action holders to Francesca Palombini (IESG state changed)
2022-01-04
03 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-01-04
03 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-01-04
03 Mark Nottingham New version available: draft-ietf-httpbis-targeted-cache-control-03.txt
2022-01-04
03 (System) New version approved
2022-01-04
03 (System) Request for posting confirmation emailed to previous authors: Mark Nottingham , Stephen Ludin , Yuchen Wu
2022-01-04
03 Mark Nottingham Uploaded new revision
2022-01-04
02 Francesca Palombini Waiting for a new submission including all changes already made in the editor's version before moving forward.
2022-01-04
02 (System) Changed action holders to Mark Nottingham, Stephen Ludin, Francesca Palombini, Yuchen Wu (IESG state changed)
2022-01-04
02 Francesca Palombini IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2021-12-30
02 Barry Leiba Request for Last Call review by ARTART is assigned to Harald Alvestrand
2021-12-30
02 Barry Leiba Request for Last Call review by ARTART is assigned to Harald Alvestrand
2021-12-30
02 Barry Leiba Assignment of request for Last Call review by ARTART to Tim Bray was marked no-response
2021-12-23
02 Elwyn Davies Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Elwyn Davies. Sent review to list.
2021-12-23
02 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-12-20
02 Joel Jaeggli Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Joel Jaeggli. Sent review to list.
2021-12-16
02 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from Reviews assigned
2021-12-16
02 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2021-12-14
02 Sabrina Tanamal IANA Experts State changed to Reviews assigned
2021-12-14
02 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2021-12-14
02 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-targeted-cache-control-02. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-httpbis-targeted-cache-control-02. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator 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 new registration is to be made as follows:

Field Name: CDN-Cache-Control
Status: permanent
Reference: [ RFC-to-be ]
Comments: Cache-Control directives targeted at Content Delivery Networks

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

The IANA Functions Operator understands 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.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-12-12
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2021-12-12
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2021-12-11
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Klaas Wierenga
2021-12-11
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Klaas Wierenga
2021-12-10
02 Barry Leiba Request for Last Call review by ARTART is assigned to Tim Bray
2021-12-10
02 Barry Leiba Request for Last Call review by ARTART is assigned to Tim Bray
2021-12-09
02 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2021-12-09
02 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2021-12-09
02 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-12-09
02 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-12-23):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-targeted-cache-control@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com …
The following Last Call announcement was sent out (ends 2021-12-23):

From: The IESG
To: IETF-Announce
CC: draft-ietf-httpbis-targeted-cache-control@ietf.org, francesca.palombini@ericsson.com, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Targeted HTTP Cache Control) to Proposed Standard


The IESG has received a request from the HTTP WG (httpbis) to consider the
following document: - 'Targeted HTTP Cache Control'
  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 2021-12-23. 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 a convention for HTTP response header
  fields that allow cache directives to be targeted at specific caches
  or classes of caches.  It also defines one such header field,
  targeted at Content Delivery Network (CDN) caches.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpbis-targeted-cache-control/



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




2021-12-09
02 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-12-09
02 Francesca Palombini Last call was requested
2021-12-09
02 Francesca Palombini Last call announcement was generated
2021-12-09
02 Francesca Palombini Ballot approval text was generated
2021-12-09
02 Francesca Palombini AD review posted: https://mailarchive.ietf.org/arch/msg/httpbisa/yQYQJ53SsYkj2tpNIKo11hNWFAs/
2021-12-09
02 Francesca Palombini IESG state changed to Last Call Requested from AD Evaluation
2021-11-22
02 (System) Changed action holders to Francesca Palombini (IESG state changed)
2021-11-22
02 Francesca Palombini IESG state changed to AD Evaluation from Publication Requested
2021-11-18
02 Francesca Palombini Ballot writeup was changed
2021-11-16
02 Tommy Pauly
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed standard, which is appropriate for the definition of new HTTP fields. The type is indicated in the header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines a technique for specifying Cache-Control that's scoped to a specific entity, specifically a CDN. This allows conventions used across CDNs to be standardized.

Working Group Summary:

This document had support and authorship from three major CDNs. The rest of the WG supported the work, but was less involved than the CDN vendors.

Document Quality:

The protocol is being worked on by three major CDNs, who have done implementations of cache control mechanisms for their CDNs. These vendors are all planning to use this new standard format.

Personnel:

Document Shepherd: Tommy Pauly
Responsible Area Director: Francesca Palombini

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I've reviewed this document through adoption and WGLC. It is succinct and clear, and I believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns about review quality.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No need for extra review.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, all authors confirmed that there is no IPR that they are aware of.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WGLC didn't elicit many responses, since this is a relatively niche document. However, some of the core WG members who weren't CDN implementers did review the document and filed some nits. The WG supports the document progressing, and has been fine with it at all meetings.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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 appeals or discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits.

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

No formal review required.

(13) Have all references within this document been identified as either normative or informative?

Yes, all references are normative or informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No changes to existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

One new HTTP field is registered, which looks fine.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal language apart from the use of structured fields, which define their own ABNF.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

No YANG.

2021-11-16
02 Tommy Pauly Responsible AD changed to Francesca Palombini
2021-11-16
02 Tommy Pauly IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2021-11-16
02 Tommy Pauly IESG state changed to Publication Requested from I-D Exists
2021-11-16
02 Tommy Pauly IESG process started in state Publication Requested
2021-11-16
02 Tommy Pauly
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed standard, which is appropriate for the definition of new HTTP fields. The type is indicated in the header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document defines a technique for specifying Cache-Control that's scoped to a specific entity, specifically a CDN. This allows conventions used across CDNs to be standardized.

Working Group Summary:

This document had support and authorship from three major CDNs. The rest of the WG supported the work, but was less involved than the CDN vendors.

Document Quality:

The protocol is being worked on by three major CDNs, who have done implementations of cache control mechanisms for their CDNs. These vendors are all planning to use this new standard format.

Personnel:

Document Shepherd: Tommy Pauly
Responsible Area Director: Francesca Palombini

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I've reviewed this document through adoption and WGLC. It is succinct and clear, and I believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns about review quality.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No need for extra review.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, all authors confirmed that there is no IPR that they are aware of.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

WGLC didn't elicit many responses, since this is a relatively niche document. However, some of the core WG members who weren't CDN implementers did review the document and filed some nits. The WG supports the document progressing, and has been fine with it at all meetings.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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 appeals or discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits.

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

No formal review required.

(13) Have all references within this document been identified as either normative or informative?

Yes, all references are normative or informative.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No changes to existing RFCs.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

One new HTTP field is registered, which looks fine.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No formal language apart from the use of structured fields, which define their own ABNF.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

No YANG.

2021-11-11
02 Tommy Pauly Notification list changed to tpauly@apple.com because the document shepherd was set
2021-11-11
02 Tommy Pauly Document shepherd changed to Tommy Pauly
2021-11-11
02 Tommy Pauly Changed consensus to Yes from Unknown
2021-11-11
02 Tommy Pauly Intended Status changed to Proposed Standard from None
2021-10-18
02 Mark Nottingham Tommy called WGLC in https://www.w3.org/mid/39D77CD2-229D-4D4A-BDB8-B12BE54DC11B@apple.com
2021-10-18
02 Mark Nottingham IETF WG state changed to In WG Last Call from WG Document
2021-10-14
02 Mark Nottingham New version available: draft-ietf-httpbis-targeted-cache-control-02.txt
2021-10-14
02 (System) New version approved
2021-10-14
02 (System) Request for posting confirmation emailed to previous authors: Mark Nottingham , Stephen Ludin , Yuchen Wu
2021-10-14
02 Mark Nottingham Uploaded new revision
2021-09-20
01 Mark Nottingham New version available: draft-ietf-httpbis-targeted-cache-control-01.txt
2021-09-20
01 (System) New version approved
2021-09-20
01 (System) Request for posting confirmation emailed to previous authors: Mark Nottingham , Stephen Ludin , Yuchen Wu
2021-09-20
01 Mark Nottingham Uploaded new revision
2021-07-26
00 Mark Nottingham New version available: draft-ietf-httpbis-targeted-cache-control-00.txt
2021-07-26
00 (System) WG -00 approved
2021-07-26
00 Mark Nottingham Set submitter to "Mark Nottingham ", replaces to (none) and sent approval email to group chairs: httpbis-chairs@ietf.org
2021-07-26
00 Mark Nottingham Uploaded new revision