Paul, thank you for your review and thank you all for the following discussion. I have entered a No Objection ballot for this document.
Lars > On 2021-7-1, at 19:55, Paul Kyzivat <[email protected]> wrote: > > 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? > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
