Re: I-D ACTION:draft-ietf-http-hit-metering-01.txt

Koen Holtman (koen@win.tue.nl)
Mon, 24 Mar 1997 22:12:49 +0100 (MET) 

Jeffrey Mogul:
[...]
>    ftp://ds.internic.net/internet-drafts/draft-ietf-http-hit-metering-01.txt
> 
[...]
>To this date, I don't think there have been many (or any) comments on
>the Design Notes/Design Questions identified in the draft.  Consider
>this as your last change to discuss those notes.

I just read the design notes, and I agree with the way you have resolved the
known design choices.

>  If there is no
>specific and unresolved discussion of these notes, I will remove them
>and generate a new draft by the pre-Memphis I-D submission deadline
>(next Wednesday, March 26).

Some other quick comments:

- I'm happy with the new material about user counting. This revision removes
my earlier concerns about the support for user counting being overstated.

- Some exotic proxy arrangements could lead to there being a `metering
sub-graph' instead of a tree.  Have you done the analysis to find out if
section 5.6 really covers all subcases?

- Section 3.3: `then the proxy MUST add "Cache-control:
   proxy-maxage=0" to all responses it sends for the resource.'
You probably mean: `then the proxy MUST add "Cache-control:
   proxy-maxage=0" to all responses for which metering or limiting was
   requested.'
because you say earlier on that being metered is a property of a response,
not of a resource.

- Section 4.1:

  `The existing (HTTP/1.0) "cache-busting" mechanisms for counting
   distinct users will certainly overestimate the number of users behind
   a proxy, since it provides no reliable way to distinguish between a
   user's initial request and subsequent repeat requests caused by
   insufficient space in the end-client cache.'

Hit metering also `provides no reliable way to distinguish between a user's
initial request and subsequent repeat requests caused by insufficient space
in the end-client cache' if I'm correct (there is no If-* header if the page
dropped out of the cache), so limiting this statement to "cache-busting" is
a bit misleading.

  `The "Cache-control:
   proxy-maxage=0" feature of HTTP/1.1 does allow the separation of
   use-counts and reuse-counts, provided that no HTTP/1.0 proxy caches
   intervene.'

How can they intervene?  Do some 1.0 proxies stip off the If-NoMatch headers
when forwarding a request on a stale cache entry, or are you talking about
something else?

- Concluding: I can live with this draft going forward as a proposed
standard.  I think it is technically sound.  I'm converting my `no' on the
previous last call to a `don't care'.  It is not a `yes' because I still feel
there is insufficient evidence that this draft is really needed.

>-Jeff

Koen.