Telechat Review of draft-ietf-httpbis-cache-header-09
review-ietf-httpbis-cache-header-09-artart-telechat-duerst-2021-08-10-00

Request Review of draft-ietf-httpbis-cache-header
Requested rev. no specific revision (document currently at 10)
Type Telechat Review
Team ART Area Review Team (artart)
Deadline 2021-08-10
Requested 2021-07-09
Authors Mark Nottingham
Draft last updated 2021-08-10
Completed reviews Genart Last Call review of -08 by Paul Kyzivat (diff)
Artart Telechat review of -09 by Martin Dürst (diff)
Assignment Reviewer Martin Dürst 
State Completed
Review review-ietf-httpbis-cache-header-09-artart-telechat-duerst-2021-08-10
Posted at https://mailarchive.ietf.org/arch/msg/art/PkmUw1rBOy6R0EYSYGyKtO38CaQ
Reviewed rev. 09 (document currently at 10)
Review result Ready with Issues
Review completed: 2021-08-10

Review
review-ietf-httpbis-cache-header-09-artart-telechat-duerst-2021-08-10

Reviewer: Martin J. Dürst
Review result: Ready with Nits

This document is mostly ready, but a few places would benefit from updated/clarified wording.

Overall: The draft says the header's purpose is "to add debugging". Is the intent that this header is consumed by debugging tools, or is it simply intended for human debuggers? If the former, that should be called out more clearly because it might help implementing senders to be more careful. If the later, there's a chance that implementations will degrade over time, because humans are the ultimate example for the second half of Jon Postel's robustness principle. Also, it would be interesting to know if other uses besides debugging are possible.

Section 2, first paragraph: The sentence is grammatically correct, but avoiding "caches'" and the final "within" would definitely make it more readable. E.g.: "The Cache-Status HTTP response header field indicates how the caches have handled the request corresponding to the response where the header field occurs.".

Section 2, second paragraph: "Its value is a List ([RFC8941], Section 3.1):": RFC 8941 is just referenced in passing. If the header field is using the syntax from RFC 8941, that should be said independently up front. If only parts of that syntax are used, that should also be said explicitly.

Section 2, ~forth paragraph (fifth by different counting): This paragraph, and in particular its first sentence, have left me wondering about its exact meaning repeatedly. When the draft says "The Cache-Status header field is only applicable to responses that have been generated by an origin server.", is that another way of saying that the server  (which may be a cache, but not for the response in question) originally creating a response SHOULD NOT add such a header field to that response? The problem with the current language is that in my understanding, essentially all responses at one point are generated by an origin server, and so the quoted sentence doesn't in any way restrict anything. Or is the header also inappropriate for the case when a cache serves a full fresh response as originally received from the origin server, with 200 OK? Wouldn't that defy the purpose of this header field?

Section 2.4, first paragraph: "measured when the response header section is sent by the cache": This may be splitting hairs, but some header sections are quite large and may not be sent in one go, and on the other hand, generating a header field and sending it may not happen exactly synchronously, in which case it would be easy to measure and note down the ttl when generating, but difficult to do so when sending.

Section 3, last example: There is only one example with two layers of caching. One or more additional examples of multi-layer caching might greatly enhance understanding for example-directed readers.