[Gen-art] Gen-ART Last Call review of draft-ietf-httpbis-cache-header-08

[Paul Kyzivat <[e-mail]>]

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-header-08
Reviewer: Paul Kyzivat
Review Date: 2021-07-07
IETF LC End Date: 2021-07-01
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.

General:

What I read in Security Considerations section scares me, but I'm not 
competent to express an opinion. I am going to leave this to the 
security review.

Issues:

Major: 0
Minor: 4
Nits:  0

1) Minor: Is a hit or fwd parameter required?

Is it required that an entry contain one of "hit" or "fwd"? Section 2.1 
makes it clear that you can't use both, but is less clear that one of 
them must be included. But logically it seems that an entry without 
either wouldn't be very useful.

I suggest that this be stated explicitly.

2) Minor: ttl for other caches

I'm not clear about the following in section 3:

    Going through two separate layers of caching, where the cache closest
    to the origin responded to an earlier request with a stored response,
    and a second cache stored that response and later reused it to
    satisfy the current request:

    Cache-Status: OriginCache; hit; ttl=1100,
                  "CDN Company Here"; hit; ttl=545

When "CDN Company Here" replies with a hit is it responsible for 
updating the ttl for the OriginCache? (Based on the time that has 
elapsed since it cached the value.) If not, does that ttl have any 
relevance?

3) Minor: registration of parameters

IMO the process of registration is underspecified.

For one thing, IANA is not instructed as to what the registry itself 
should look like. Given that a specification document is optional, the 
registry presumably must contain everything specified by the template in 
section 4 for new parameter registrations. But the instructions for 
pre-populating the registry from section 2 would mean copying a *lot* 
free formatted text into the registry.

ISTM that it would be more straightforward to always require a 
specification and have the IANA registry refer to it.

Alternatively, you could have different templates for registering 
with/without a specification and different registry formats for each.

I suggest you provide IANA with a template for the registry, and provide 
authors of extension parameters with a template for what should be 
included in a specification document.

4) Minor: Applicability of this header field is confusing

Section 2 says:

    The Cache-Status header field is only applicable to responses that
    are generated by an origin server.  An intermediary SHOULD NOT append
    a Cache-Status member to responses that it generates, even if that
    intermediary contains a cache, except when the generated response is
    based upon a stored response (e.g., a 304 Not Modified or 206 Partial
    Content).

The use of "are" implies to me that the cache received the response from 
the origin server just now. Using "were" (or even more explicit 
language) would tell me that this was a response received by the cache 
either now or in the past.

Also, IIUC the cache can't ever really distinguish if it received a 
response from the origin server or another cache. So how can it know if 
this response *ever* was created by the origin server? All it can know 
is that it received it from a server closer to the origin.

Can you clarify the language?