Re: Gen-ART Last Call review draft-ietf-httpbis-p6-cache-25

Hi Meral,

Thanks for the review. I'm CC:ing the WG; responses below.


On 3 Dec 2013, at 4:05 pm, Meral Shirazipour <meral.shirazipour@ericsson.com> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq  .
>  
> Please resolve any Last Call comments you may receive.
>  
>  
>  
> Document: draft-ietf-httpbis-p6-cache-25
> Reviewer: Meral Shirazipour
> Review Date: 2013-11-18/2013-12-02
> IETF LC End Date: End of November (special deadline)
> IESG Telechat date: 2013-12-19
>  
>  
> Summary:
> This draft is almost ready to be published as Proposed Standard but I have some comments.
>  
>  
> Major issues:
> none
>  
>  
> Minor issues:
> none
>  
>  
> Nits/editorial comments:
> Part 6 of:
> draft-ietf-httpbis-p1-messaging (82 pages)
> draft-ietf-httpbis-p2-semantics (98 pages)
> draft-ietf-httpbis-p4-conditional (27 pages)
> draft-ietf-httpbis-p5-range (24 pages)
> *draft-ietf-httpbis-p6-cache (41 pages)
> draft-ietf-httpbis-p7-auth (18 pages)
> draft-ietf-httpbis-method-registrations (7 pages)
> draft-ietf-httpbis-authscheme-registrations (5 pages)
>  
> -As mentioned in p4 review, was it considered merging p4 and p6?

It was, but conditional requests are not only used for caches; e.g., they're also useful for avoiding the "lost update" problem.


>  -[Page 1], abstract, Suggestion to change the sentence to remove the word "requirements" to avoid confusion with a Requirements RFC (which is usually followed by the spec).
> "This document defines requirements on HTTP caches... "

I've removed "requirements on".


>  -[Page 12], last paragraph, suggestion to use SHOULD  or MUST
>  
> "heuristics can only be used on responses without explicit freshness"----->
> "heuristics SHOULD/MUST only be used on responses without explicit freshness"

That sentence is explaining the requirement directly above -- " A cache MUST NOT use heuristics to determine freshness when an explicit expiration time is present in the stored response." We try to avoid duplicative requirements, as they can be confusing and cause interop problems.



>  -[Page 19], "update the stored response a described below;"--typo-->"update the stored response as described below;

I believe Julian has fixed this.


>  -[Page 22], does is matter if it is strong versus weak validation?
> "
> 5.2.1.4.  no-cache
>  
>    The "no-cache" request directive indicates that a cache MUST NOT use
>    a stored response to satisfy the request without successful
>    validation on the origin server.
> "

If the server supplies a weak validator along with a no-cache directive, their intent is pretty obvious -- i.e., it can be either, depending on what the server wants.


> -[Page 34], Security section, as mentioned in my other reviews, would it be better to have a separate draft to discuss all security issues related to HTTP?

We've discussed such a thing at various times, but so far there hasn't been enough energy or focus to produce it. 

Thanks again,


--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 6 December 2013 03:23:57 UTC