At 14:01 6/15/2001 -0400, Keith Moore wrote:
> The Open Plugable Edge Service (OPES) WG primary task is to define a
> protocol to be used to extend participating transit intermediaries to
> incorporate services executed on application data transported by HTTP.
What are "participating transit intermediaries"?
To me, an intermediary is anything that handles network traffic and
which is not an endpoint, regardless of what layer of the stack it
operates on, or on whose behalf it is operating.
Do the charter authors intend that this group's purview include bridges,
routers, NATs, proxies, firewalls, gateways, etc? how about things
that operate on multiple layers ?
(If this group is approved are we abandoning the idea of functional
separation between layers in the internet architecture? )
Are "intermediaries" intended to include interception proxies?
I was under the impression that they were specifically out of scope, and
that the reason for that choice would also exclude other (lower layer)
intermediaries from scope. (This is related to a point you make later
regarding awareness vs. consent.)
Re: "application data transported by HTTP" -
Does this mean that this group's purview is limited to things that use
the HTTP protocol?
Are we now trying to encourage people to layer applications over HTTP,
in spite of the concerns outlined in draft-moore-using-http-01.txt ?
I'm not sure I understand what you're asking Keith. Is your point that by
limiting OPES to HTTP only that act will encourage developers to layer
things on top of HTTP?
> Intermediaries may employ either local
> or remote ("callout") servers to perform a service, and as a result,
> the data may be diverted temporarily over a closed loop pathway
> different from the transit pathway. Intermediary services provided in
> this way are not transparent: Either the content requestor or provider
> will be aware that a tranformation has been performed.
Why is it (apparently) sufficient that one of the end points "be aware"
that the data path is not transparent, rather than "consent"?
Is this group really going to legitimize arbitrary corruption of the
data stream by intermediaries which the endpoints do not control,
just so long as one of the end points is "aware" of the corruption?
My understanding was that either party would have consented. I think this
one is just down to choice of words.
> As part of the development of this protocol the WG will produce an
> analysis of the security impliciations of this architecture.
Why is security the only concern that the group is expected to analyze?
It seems like reliability, predictability, ability to distinguish errors
from normal operation, ability to diagnose and problems, user privacy, and
intellectual property rights, are all at least as important as security.
Agreed.
It also seems like there should be strict constraints on when this technology
should be used. If we do this work, will we be saying that it's legitimate
for ISPs to rewrite HTTP requests or responses for better traffic
utilization?
How about to insert or delete advertisements, or to hide content that the ISP
doesn't want the user to transmit or receive?
I'm not sure that publishing an RFC of any kind can dictate actual
constraints of when the technology should be used, but I understand your
concern.
As for the latter point the group is, I believe, suggesting that the case
of an ISP modifying requests/responses for those reasons is covered under
the consent of the end user (since they have a contract with the ISP and
that such practice must be documented in that contract).
We're definitely on dangerous ground regarding "layer > 7" stuff here.