Re: Roy Fielding's comments on draft-ietf-http-hit-metering-03

Although draft-ietf-http-hit-metering-03 has moved into IESG
"last call", it is still useful to ask, once more, if there
are any additional working group comments on the draft in support
of the points raised by Roy Fielding in
<mid:9707162253.aa22535@paris.ics.uci.edu>.

While there's been some concern that those comments were "late",
I don't think that's the issue: if there is working group support
for considering them, we should consider them, no matter when they
are offered. In any case, it is certainly better to raise issues
before the RFC gets issued than afterward.

Here is my analysis of the points raised, as working group chair
I'd like to ask Roy to withhold continuing
to argue the points just so that we can see if there is any
other support for any of them from anyone else in the mailing list;
if not, we can go on, without additional discussion:

Issue 1:

> It may also be that, by placing this proposal on the standards track,
> proxy implementers will be forced, for the sake of efficiency or lack
> of network resources, to add the Meter field to every request regardless
> of their intention to pass along metering information. 

This point is hypothetical, expressed as an "It may also be that ...".
Creating a "Proposed Standard" which has the approval of the
implementors
of proxies doesn't seem to force them to do anything they didn't
want to do by dint of supporting the protocol. So I don't think
this particular objection carries any weight, at least in the 
form it is expressed. It is our belief that proxy implementors
DO intend to pass along metering information, and if they do
not, then this proposed standard will not progress to draft
standard.

> It is NOT the "Meter header".  The header of a message is the sum of all
> of the header fields.  It should be referred to as the "Meter field" or
> "Meter header field" or "Meter request-header" (the latter is a BNF rule).

This objection is one of terminology and seems like a quibble;
certainly I don't think the draft is misleading even without
fixing this particular nit.

> The proposal places restrictions on proxies in order to restrict the
> actions of shared caches.  The presence of a non-caching proxy in the
> chain will break the metering tree, even though a non-caching proxy
> has no impact on metering itself.  Section 5.5 (which should be referred
> to by earlier sections) suggests that such proxies always add the Meter
> field, thus increasing network overhead merely to sustain the possibility
> of the metering tree.

This objection indicates that the document could use an additional
cross reference;  the main point, though, seems to be based on a
problem which occurs in fairly rare circumstances (with a non-caching
proxy in a meter tree). In any case, it is my reading that the
weight of the working group does not believe this is an issue.

> In other words, it is a design that forces the proxy (with or without
> cache) to advertize metering support, rather than using the existing
> extensibility of the Cache-Control field to allow the origin server
> to state its requirements for metering explicitly.  The alternative
> design that is not mentioned is to introduce a metering cache-directive
> that modifies the semantics of the "private" or "s-maxage" directives, e.g.

This comment seems to indicate a preference for an alternative design,
but does not, by itself, render the proposal's design inoperable.
As was recounted, the alternative design has its own drawbacks.

> Then don't define any non-abbreviated form!  This is a network protocol,
> not a user-readable treatise.  Long header field names are often necessary
> to avoid conflicts with other names (and protocols); long field values
> are never useful unless they contain data intended to be read by a
> human being, which is clearly not the case here.

This expresses a desire for a simplification of the design. However,
the design can be simplified if implementation experience warrents it.
As is, there doesn't seem to be a strong opinion that we should change
the proposal just because we can.

> When the proposal is ready for publication as an RFC, it should be
> assigned Experimental status until such time as the overhead placed on
> proxies is *demonstrated* to be offset by the benefit gained by caching
> responses that would otherwise have been busted for the sole purpose of
> gathering hit counts.  In particular, no Internet proxy should activate an
> implementation of this proposal until there exist some deployed origin
> server implementations.

It is believed that the proposal _is_ ready for publication as an RFC,
and that it is ready now, and that it is ready for Proposed Standard.

Advice about deployment strategy seems to be consistent with a Proposed
Standard as well as an Experimental RFC. It may well be the case that
deployment of origin servers should be staged before proxy servers will
provide value, but given how fast Internet software and web browsers and
proxies seem to be deployed, trying to control this by changing the
status
of the publications of RFCs doesn't seem to be appropriate.

If anyone on the mailing list disagrees and wishes to defend any of the
points raised in mid:9707162253.aa22535@paris.ics.uci.edu, will you
please
speak up now?

If you would prefer to contact me privately, I will make sure that your
voice gets heard.

Thanks,

Larry
(as HTTP working group chair)

Received on Tuesday, 22 July 1997 16:28:00 UTC