Mohamed Boucadair's No Objection on draft-ietf-httpbis-cache-groups-05: (with COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-httpbis-cache-groups-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache-groups/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

Received on Friday, 18 April 2025 12:44:41 UTC