Reviewer: Marco Tiloca Review result: Ready with Nits I reviewed this document as part of the Applications and Real-Time (ART) Area Review Team's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the ART Area Directors. Document authors, document editors, and WG Chairs should treat these comments just like any other IETF Last Call comments. Thanks for this document! I believe it is basically ready. Please see below a few minor comments. Best, /Marco [Section 1] * It says: > Section 2 introduces a means of describing the relationships between a set of stored responses in HTTP caches by associating them with one or more opaque strings. It also describes how caches can use that information to apply invalidation events to members of a group. If I understand correctly: * "set" in the first sentence is what "group" means in the second sentence. * The "opaque strings" in question are practically the names given to the groups. * If the strings are opaque, I'm not sure how much they are about "describing" relationships. I suppose that what actually reflects the relationships is the group memberships of the cached responses. If the above is correct, a possible rephrasing is: > Section 2 introduces a means of describing the relationships between stored responses in HTTP caches, by associating those responses with one or more groups that reflect their relationships and that are identified by opaque strings. It also describes ... A rephrasing along the same lines can apply to the abstract too. [Section 2.1] * It says: > to have the same group ... I guess it means: > to belong to the same group ... [Section 3] * It says: > For example, a POST request that has side effects on two cache groups could indicate that stored responses associated with either or both of those groups should be invalidated with: I think you mean: > For example, following the successful processing of a POST request that has side effects on two cache groups, the corresponding response could indicate that ... * Even though hardly useful, it seems admitted that: * A response includes both the Cache-Groups header field and the Cache-Group-Invalidation header field; and * Both header fields include the same string "foo". In that case, is it still entirely up to the cache receiving the headers to decide whether first associating the response with the group "foo" and then optionally removing the response from that group, or instead doing vice versa? Would a specific processing order be desirable/expected? For example, first process the Cache-Group-Invalidation header and then the Cache-Groups header, in case both are present in a response. [Nits] * Section 1 --- s/address this issues/address the issues * Section 2.1 --- s/The both/They both * Appendix A The "Acknowledgements" section is usually an unnumbered section after the appendices (if any), see RFC 7322. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
