Keith-
We have no focus, interest, support, love for, etc. with interception proxies.
Of course we cannot control the ISV market and if they do/do not use them.
The intermediary service are at an application level not the network
level (NAT, etc.) and in some sense are an "end" in the "middle".
This space is short of clarifying terms and we hope to help that
shortly (a result of the last workshop). Certainly this is not
looking at the problems in the MidCom area.
This does not answer all your confusions, more later.
At 02:01 PM 6/15/2001 -0400, Keith Moore wrote:
I have several concerns about this charter.
I cannot tell whether those concerns are merely due to ambiguities in
the charter. I hope this is the case, and that the proponents of
the group will be willing to clarify the charter to narrow the apparent
scope of this proposed group.
> 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?
Does it matter whether the intermediary is operating on the client's
behalf, on the content-provider's behalf, or on behalf of some
communications provider?
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 ?
> The protocol provides a framework for integrating arbitrary services
> into arbitrary intermediaries.
The word "arbitrary" here is scary. Is this group really being given
a charter to allow it to entirely discard the internet architecture?
In other words, is this group going to define standard ways to say
- "yes, it's okay if you ignore the destination IP address for this
packet, and route it to some other location?"
- "yes, it's okay if you break end-to-end transparency of the packet,
not just for the packet header, but also for the payload?"
(or similarly for end-to-end transparency of the transport protocol
stream)
And who is allowed to consent to such deviations? One of the
endpoints or someone carrying the traffic?
> 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?
> 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.
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?
> A secondary task for this WG is to enumerate the requirements for
> management policies and associated administrative protocols that allow
> these services to be specified and deployed.
>
> The advantage of standardizing a protocol for this is that services can
> be re-used across vendor products without modifying the transit
> intermediaries or services.
Something very important seems to be missing from this charter, namely:
Why is this activity beneficial for the Internet user community?
Or to put it another way (and if my understanding is correct), how is this
protocol so valuable for the Internet community that it is worth destroying
the Internet architecture ?
(Or am I missing some implied constraints on the WG's charter that would
make it reasonable?)
This charter seems either dangerous, or dangerously ambiguous.
I am hoping that it is the latter, and that the charter's intent
is to do something reasonable and useful. But I cannot tell from
reading the charter what is reasonable and useful about what this
group proposes to do.
Keith
Michael W. Condry
Director, Network Edge Technology