HTTP Cache Groups
draft-ietf-httpbis-cache-groups-07

As Mark has stated he will change the example and my other concern is no longer valid, I am changing my ballot to No Objection.

Thanks to Barry Lieba for the secdir review.

Section 3, example:  I agree with Andy Newton's  "your fav pop star' discuss.  There are so many options to choose from, it would seem possible and prudent to pick an obviously fictional example. (It is reported that Kylie Minogue has never been on Eurovision, even though Australia is a member).

Nice, easy to read, and useful document.

Just one comment, when reading "opaque" I was expecting an apparently meaningless string, e.g., a hash of something, but readable strings are used in the examples. Should there be some operational guidance on the 'group' string (meaningful vs. random strings) ?

"Abstract", paragraph 0
>    This specification introduces a means of describing the relationships
>    between stored responses in HTTP caches, "grouping" them by
>    associating a stored response with one or more opaque strings.

The ballot text for this document still refers to Francesca as the Responsible AD. That should be fixed.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 5
> oduces one new source of such events: a HTTP response header field that allow
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Hi Mark,

Thank you for this well-written document.

Please find below some comments: 

# (nit) consider split this long sentence: 

OLD:
   In addition to sharing invalidation events, the relationships
   indicated by grouping can also be used by caches to optimise their
   operation; for example, it could be used to inform the operation of
   cache eviction algorithms.

NEW
   In addition to sharing invalidation events, the relationships
   indicated by grouping can also be used by caches to optimise their
   operation. For example, it could be used to inform the operation of
   cache eviction algorithms.

# (nit)

OLD: Section 3 introduces one new source of such events: a HTTP response

NEW: Section 3 introduces one new source of such events: an HTTP response

# Same origin

CURRENT:
   These mechanisms operate within a single cache, across the stored
   responses associated with a single origin server .  

Do we need to say how that "single origin server" is identified?

# Mention the section where to look at

CURRENT:
   The Cache-Groups HTTP Response Header is a List of Strings
   [STRUCTURED-FIELDS].   

and

CURRENT:
   The Cache-Group-Invalidation response header field is a List of
   Strings [STRUCTURED-FIELDS].   

Please add a reference to the exact section to look at.

As we don’t have a clear reference, I don't know whether we allow empty values? Same value repeated several times? upper case, etc.

# Parameters

CURRENT:
   The ordering of members is not significant.  Unrecognised Parameters 
   MUST be ignored.

Which parameters?

Also, shouldn’t the validation be based on RFC8941 to avoid redundant behaviors? That is, do we need this MUST?

# Lack of reasoning

CURRENT:
   Implementations MUST support at least 32 groups in a field value ,
   with up to at least 32 characters in each member.  Note that generic
   limitations on HTTP field lengths may constrain the size of this
   field value in practice.

and

CURRENT:
   Implementations MUST support at least 32 groups in a field value,
   with up to at least 32 characters in each member.  Note that generic
   limitations on HTTP field lengths may constrain the size of this
   field value in practice. 

What is the rationale for picking these values? What is currently supported by existing implementations? Can this be configurable? How one can retrieve what is supported by a given implementation?

# (nit) Both items

OLD: the same group when all of the following conditions are met

NEW: the same group when both of the following conditions are met

# Comparison logic

CURRENT:
   1.  They both contain a Cache-Groups response header field that
       contains the same String (in any position in the List), when
       compared character-by-character .

Is the comparison case-sensitive? Or do we rely on rfc8941 for these matters, e.g., to prevent upper case to be used in a list item?

# Reasoning again

CURRENT:
   A cache that receives a Cache-Group-Invalidation header field on a
   response to an unsafe request MAY invalidate any stored responses
   that share groups (per Section 2.1) with any of the listed groups. 

What is the rationale for the MAY here?

# Interaction with proxies

How this mechanism interacts with proxies? Are those allowed to inject/alter what is set by a server? 

May be adding a reference where such «generic» matters are covered would be useful here.

# Management

CURRENT:
   (sometimes referred to as "shared hosting") might allow one party to
   group its resources with those of others, or to send signals which
   have side effects upon them. 

How that is managed by a "party" in practice? Is it a configuration action?

# Cascaded effect

If we have an entry that belongs to A/B, another that belongs to B/C, and a third to C/D. If A group is invalidated, this will impact the second entry per the rules in 2.2.1. However, does this impact the third one as well is it shares a group with the second invalidated one?

Cheers,
Med

Thank you to Marco Tiloca to the ARTART Review.

Thanks for the clear document.

I also learned that Australia has in fact participated in the Eurovision Song Festival.

Thank you to Paul Kyzivat for the GENART review.