Re: Hit-metering: to Proposed Standard?

Jeff, Paul,
	I'm afraid silence doesn't always indicate consent; in my case
it indicated an expectation that this draft would be a major point of
discussion in San Jose and a desire to discuss it in person.  Given
the eagerness of your customers to implement a cache-metering
solution, though, we should probably start on this right away.  Let me
start by saying that I appreciate the work that has gone into this
draft, but that I feel that there are some very basic design changes
here that need critical discussion.  
	As your draft makes admirably clear, this new mechanism
creates a duty between proxy and an origin server, which is a
fundamentally different relationship than obtained before.  As was
pointed out at previous meetings, proxy servers currently act on
behalf of the end-user; to change that behavior without some way of
letting the end user know it has changed has privacy implications (and
these are not necessarily the same privacy implications as exist when
"proxy-revalidate" is sent from origin servers, because proxies have
access to data across multiple servers).
	If we accept that any hit-metering proposal must create such a
duty, we need to be very careful about the complexity of the duty that
is assigned.  Your proposal seems to me to have three different layers
of potential duties: the duty to limit usage; the duty to report
usage; and the duty to report how Vary headers resulted in usage.  The
first duty seems to me easy to implement and non-invasive in results;
it is less accurate than reportage, but within a scope which is
controlled by the origin server and which can be modified as time goes
on.  The second duty begins to create a more complex duty; it is not
that difficult to implement but may actual be a serious burden on very
large proxy caches, especially if they make a best effort to limit
network traffic by chaining reportage of hits against different
resources on the same origin server.  The third level seems to me far
beyond what should be expected of a proxy server; it asks the proxy to
track the kind of demographic data that can be both very complex and
an invasion of privacy. (I say that with some disappointment, frankly,
as the third level of data is really the only kind that I am
professionally interested in, as that level would give me information
I need to plan for future resources).
	Your proposal says very clearly that "any proxy that transmits
the Meter header in a request MUST implement every requirement of this
specification, without exception or amendment."  I don't think that
this is reasonable; I realize that your proposal includes methods
which allow a proxy to "implement" a requirement by failing to offer a
service, but I think a design in which there were some true MUSTs, and
other SHOULDs and MAYs would be more appropriate.  If we can establish
which duty is a "MUST" for this scheme to work, we can make this
radically easier to implement and use; especially as that
determination will also make clear to origin servers which of the
mechanisms (reportage or usage-exhaustion) is going to be the basic
method for usage counting.  If there are multiple methods which can
produce different counts, there are going to be problems, even if the
range of difference is small on a per-proxy basis.
	Even assuming that this basic design is accepted, there are
some problems in your current proposal.  The description of the
"metering subtree", for example, imples that proxies working together
within a "tree" to obey usage limits and maintain counts; there is an
underlying assumption, however, that the proxies in that tree will
maintain a particular "path" of proxies back to the origin server,
which may not always be the case.  The use of Meter as a sticky header
also presents some problems, as a meter request directive is sticky
and other meter headers are not.  You also provide no method of
unsticking the meter-request directive other than closing the
connection.  I frankly think the whole mechanism of creating sticky
headers needs to be worked out in other draft, rather implied by the
behavior of one header made sticky here.
	Again, let me say that I appreciate the work that has gone
into this, and I believe that we now have a very good document from
which to hash out the issues.  My belief that we have issues to hash
out should in no way imply that I believe the work isn't important
and urgent.
		regards,
			Ted Hardie
			NASA NIC






> Since we have not seen any criticism of our latest proposal, we would
> like to interpret this as lack of criticism rather than lack of
> interest, because we already have evidence that several large customers
> are eager to deploy implementations of our proposal.
> 
> Therefore, we intend to submit this I-D, or a minor revision thereof,
> to the IESG as a Proposed Standard as soon as possible.
> 
> Note that the criteria for Proposed Standard in RFC2026 says
> 
>    A Proposed Standard specification is generally stable, has resolved
>    known design choices, is believed to be well-understood, has received
>    significant community review, and appears to enjoy enough community
>    interest to be considered valuable.  However, further experience
>    might result in a change or even retraction of the specification
>    before it advances.
> 
> so we *would* like to encourage further community review.
> 
> If there is significant criticism based on technical merit, then we
> will reconsider our intention to submit it as a Proposed Standard.
> Of course, we are also eager to hear from people who support our
> proposal, or who would like to suggest revisions.  There are a
> few minor open "Design Questions" still listed in this draft.
> 
> -Jeff and Paul
> 
> P.S.: We should also note that Larry Masinter has suggested that
> this should be submitted for "Experimental" rather than "Proposed
> Standard" status.  Our reading of RFC2026, however, convinces
> us that "Experimental" would be inappropriate.  Larry may still
> disagree.
> 
>

Received on Tuesday, 19 November 1996 16:01:54 UTC