Skip to main content

Last Call Review of draft-ietf-httpbis-cache-16
review-ietf-httpbis-cache-16-genart-lc-sethi-2021-05-30-00

Request Review of draft-ietf-httpbis-cache
Requested revision No specific revision (document currently at 19)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2021-06-10
Requested 2021-05-27
Authors Roy T. Fielding , Mark Nottingham , Julian Reschke
Draft last updated 2021-05-30
Completed reviews Secdir Last Call review of -16 by Derek Atkins (diff)
Genart Last Call review of -16 by Mohit Sethi (diff)
Opsdir Last Call review of -16 by Al Morton (diff)
Assignment Reviewer Mohit Sethi
State Completed
Review review-ietf-httpbis-cache-16-genart-lc-sethi-2021-05-30
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/YWMvuhly5ShJtk5PJ09KCLw-0vk
Reviewed revision 16 (document currently at 19)
Result Ready with Nits
Completed 2021-05-30
review-ietf-httpbis-cache-16-genart-lc-sethi-2021-05-30-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-httpbis-cache-16
Reviewer: Mohit Sethi
Review Date: 2021-05-30
IETF LC End Date: 2021-06-10
IESG Telechat date: 2021-06-17

Summary: This draft specification defines HTTP caches and header fields for
controlling the cache behavior.

Major issues:

Minor issues:
- In the HTML version of the draft, the reference to [Semantics] does not work
properly. I looked at the xml source which looks fine. I suspect it is
something to do with the tooling.

- It is not clear to me which draft is creating the "Hypertext Transfer
Protocol (HTTP) Field Name Registry". It seems both this draft and
draft-ietf-httpbis-semantics are creating it? Perhaps you could remove the text
in this draft saying "introduce the new" and just ask IANA to update the
registry with fields in Table 1 of this draft.

Nits/editorial comments:

- Section 1: When does a client or server act as "tunnel"? I don't know if it
is absolutely necessary to explain the term. You can decide.

- Section 1: HTTP caching's goal is significantly improving performance -> HTTP
caching's goal is to significantly improve performance?

- Section 1.3: Maybe it is obvious to many readers, but I was not sure what is
meant by a "canned string"?

- Section 3 vs Section 4: "A cache MUST NOT store a response to a request
unless:" does not have a comma before unless while "When presented with a
request, a cache MUST NOT reuse a stored response, unless:" has a comma before
unless?

- Some of the bullets in section 3 and 4 were hard to parse. Take for example:
"When presented with a request, a cache MUST NOT reuse a stored response,
unless: the stored response does not contain the no-cache cache directive
(Section 5.2.2.4), unless it is successfully validated (Section 4.3), and". I
am not sure how to simplify the text on all these requirements.