Skip to main content

Hypertext Transfer Protocol (HTTP/1.1): Caching
draft-ietf-httpbis-p6-cache-26

Yes

(Barry Leiba)

No Objection

(Adrian Farrel)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Spencer Dawkins)
(Stewart Bryant)

Note: This ballot was opened for revision 24 and is now closed.

Barry Leiba Former IESG member
Yes
Yes (for -24) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2013-12-19 for -25) Unknown
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.

#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?

#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.


#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.
Brian Haberman Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (2013-12-18 for -25) Unknown
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."


COMMENT 2:
In Section 3, you use "cache directive", "cache response directive", and "response cache directive".   Choose one.
Sean Turner Former IESG member
No Objection
No Objection (2013-12-19 for -25) Unknown
 *) 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.

0) Abstract: Maybe would add stateless in front of protocol in the description.

1) What Stephen said about cache poising.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -25) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2013-12-18 for -25) Unknown
- section 8: It would be very useful to add some references
where cache poisoning and how to handle it are explained in
more detail.
Stewart Bryant Former IESG member
No Objection
No Objection (for -25) Unknown