* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #535 (closed design: fixed)

Opened 12 months ago

Last modified 11 months ago

IESG ballot on draft-ietf-httpbis-p6-cache-25

Reported by: julian.reschke@gmx.de Owned by: draft-ietf-httpbis-p6-cache@tools.ietf.org
Priority: normal Milestone: 26
Component: p6-cache Severity: In IESG Evaluation
Keywords: Cc:
Origin: http://datatracker.ietf.org/doc/draft-ietf-httpbis-p6-cache/ballot/

Description (last modified by julian.reschke@gmx.de) (diff)

Benoit Claise

Comment (2013-12-19)

Please see Lionel's OPS-DIR review, and please engage in the discussion:

#1: Section 1.2.1. Delta Seconds

"A recipient parsing a delta-seconds value and converting it to binary form ought to use an arithmetic type of at least 31 bits of non-negative integer range."

How should the "ought to" above be interpreted? If it is a recommendation, "SHOULD" is maybe more appropriate.

We use that phrase consciously when we wanted to give implementation advice, but did not want to make existing implementations non-conformant.


#2: section 4.3.1. Sending a Validation Request

No normative wording is used in this section, especially there is no "MUST" and "MUST NOT". It seems therefore that this part is only for information and provides some guidelines for sending validation requests. Is it really the intention here?

Yes. The relevant requirements are specified in p4 (as referenced); this is just a discussion of how validation is relevant to caching. Furthermore, caches aren’t required to use validation; it’s just a tool that’s available to them.


#3: section 5.2. Cache-Control

"For the directives defined below that define arguments, recipients ought to accept both forms, even if one is documented to be preferred. For any directive not defined by this specification, a recipient MUST accept both forms."

"MUST" seems more appropriate than "ought to" in the first sentence above. As I understand the rest of the document, a recommendation can be given in the form to use for a given directive (when applicable) but it is expected that both forms will be always accepted by the cache. As a consequence,it does not seem so relevant to make the difference between directives defined in this document and in other documents.

See above; there are historical reasons for this.


#4: section 5.5. Warning

It could be clarified that Warn-text are only intended to be human readable or to be logged and should not affect the interpretation of the warn-code. -- see [2522]


Richard Barnes

Comment (2013-12-18)

COMMENT 1: In Section 1, a minor suggestion: OLD: "A private cache, in contrast, is dedicated to a single user." NEW: "A private cache, in contrast, is dedicated to a single user, for instance as a component of a user agent." -- see [2511]

COMMENT 2: In Section 3, you use "cache directive", "cache response directive", and "response cache directive". Choose one. -- see [2512]


Sean Turner

Comment (2013-12-19)

*) I'll not repeats the OWS discuss point from p1. If it gets changed there I assume it will get changed here. If not then this can be ignored. -- see #537

0) Abstract: Maybe would add stateless in front of protocol in the description. -- see #538

1) What Stephen said about cache poising. -- see [2523]


Stephen Farrell

Comment (2013-12-18)

section 8: It would be very useful to add some references where cache poisoning and how to handle it are explained in more detail. -- see [2523]

Change History

comment:1 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:2 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:3 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:4 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:5 Changed 12 months ago by mnot@pobox.com

From [2522]:

Note that warn-text is advisory; see #535.

comment:6 Changed 12 months ago by mnot@pobox.com

From [2523]:

Reword security considerations around cache poisioning; see #535.

comment:7 Changed 12 months ago by mnot@pobox.com

  • Description modified (diff)

comment:8 Changed 12 months ago by mnot@pobox.com

Think these are all dealt with, pending responses from ADs.

comment:9 Changed 12 months ago by julian.reschke@gmx.de

From [2524]:

fix xref, change tracking (see #535)

comment:10 Changed 12 months ago by julian.reschke@gmx.de

  • Description modified (diff)

comment:11 Changed 12 months ago by julian.reschke@gmx.de

I believe this ticket can be closed.

comment:12 Changed 12 months ago by mnot@pobox.com

  • Status changed from new to closed
  • Resolution set to fixed

comment:13 Changed 11 months ago by julian.reschke@gmx.de

From [2548]:

update issue status (see #535)

Note: See TracTickets for help on using tickets.