Subject: Re: WG Review: Open Pluggable Edge Services (opes)

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jun 2001 14:01:10 -0400

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

---

From: Ian Cooper <[email-masked]>
Date: Fri, 15 Jun 2001 12:21:40 -0700

I share some of Keith's concerns; this seems a somewhat badly written 
charter (and seems to omit changes that the group agreed on).

At 09:18 6/15/2001 -0400, The IESG wrote:
>Open Pluggable Edge Services (opes)
>-----------------------------------
>
>Current Status: Proposed Working Group
>
>Description of Working Group:
>

The lack of scope is worrying here, and Keith's point about the meaning of 
"intermediary" is particularly relevant.

Further, I was under the impression that the group was also considering RTP 
in addition to HTTP?  I believe there was a decision to specifically 
exclude SMTP, but I'm not sure I follow the logic here.  There are 
different requirements in terms of how the protocols are used (mostly the 
real-time requirements I suspect) but it seems that the following charter 
text states some good reasons to consider SMTP:

"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."

(That said, one can argue the case that with SMTP one could simply relay 
the message to the processing box using SMTP anyway.)

>into arbitrary intermediaries.

The minutes of the BoF in Minneapolis state that there was agreement to 
remove the word "arbitrary" in the first paragraph.

---

From: Ian Cooper <[email-masked]>
Date: Fri, 15 Jun 2001 12:21:13 -0700

>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.)

>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?

>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.

>intellectual property rights, are all at least as important as security.

Agreed.

>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.

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jun 2001 15:43:32 -0400

> regarding awareness vs. consent.)

it would be helpful if that were clarified in the charter.

it's one thing if we're just talking about explicitly configured 
(at client or server end) proxies; quite another if we're talking
about proxies that intervene without a user's consent.

> limiting OPES to HTTP only that act will encourage developers to layer 

there are two separate questions.  

First, I cannot tell whether "transported by HTTP" is intended as a constraint 
on the group's activities. 

Second, it appears that this group's charter presumes that layering
arbitrary applications on top of HTTP is a Good Thing, and I would take
strong issue with that presumption.  But if the group is really only
trying to add some flexibility to HTTP's proxy and cache mechanisms,
for traditional uses of HTTP, that seems somewhat less dangerous.

> one is just down to choice of words.

it's a very important distinction.  IMHO, awareness is not enough, 
explicit consent is essential.

> constraints of when the technology should be used, but I understand your 

we have no means of enforcing such constraints, but we do sometimes impose them.
it is useful to communicate expectations of how the technologies are used.

we are very fortunate that most ISPs have no so far seen to take arbitrary 
liberties with network traffic, so we can still deploy some new applications.

as I said, we can't stop them.  but the last thing we need to do is to encourage 
ISPs to interfere with network transparency.

> that such practice must be documented in that contract).

so? this self-appointed "group" doesn't even represent the interests of the diversity 
of protocol implementors within IETF, much less the interests of the Internet user.

> We're definitely on dangerous ground regarding "layer > 7" stuff here.

it's far better to discuss such "stuff" explicitly than to pretend like it's not 
important, or that it will take care of itself.

even on a purely technical level, the utility of the Internet is constantly being 
eroded by folks who think that it's okay to perform arbitrary operations on 
third-party traffic.  rather than having a network with predictable characteristics
on which a wide variety higher-level services can be layered, we are getting
a network which supports only a few services, and those in an unpredictable and
arbitrary manner.

Keith

---

From: [email-masked]
Date: Fri, 15 Jun 2001 12:29:10 -0700 (PDT)

> scope of this proposed group.

Keith, I think you are being unduly paranoid here. You are reading using the
"that which isn't explicitly disallowed is not only permitted, but condoned".
This sort of analysis is neither valid, useful, or necessary.

> What are "participating transit intermediaries"?

Application area working group -> application layer intermediaries.

> operates on, or on whose behalf it is operating.

In the general context of the IETF, perhaps. But in the context of an
application area WG, nonsense. And I don't think stating in an application WG
charter that it is scoped to the application area is necessary.

> routers, NATs, proxies, firewalls, gateways, etc?

The charter covers none of these things.

> how about things

The application layer aspects of such things could be covered, but not the
other parts.

> separation between layers in the internet architecture? )

Of course not.

> Are "intermediaries" intended to include interception proxies?

It depends on whether or not they are participating in the overall
architecture. Stuff that intercepts willy-nilly without the various other
parties being aware of it isn't part of the picture.

> behalf, on the content-provider's behalf, or on behalf of some

Part of the work of the group is to clarify this issue.

> Does this mean that this group's purview is limited to things that use

Basically, yes.

> in spite of the concerns outlined in draft-moore-using-http-01.txt ?

Not intentionally. However, to the extent that standardizing additional
capabilities for HTTP will make HTTP more attactive for some uses, this could
happen.

The alternative -- not adding needed functionality to various protocols because
we're afraid that making them more attactive will encourage misuse, is
untenable.

> a charter to allow it to entirely discard the internet architecture?

Of course not.

> ...

Keith, I stopped reading here, as your subsequent comments are built on
your earlier erroneous assumptions to such a large extent that no
further commentary from me appears to be useful.

				Ned

---

From: "Michael W. Condry" <[email-masked]>
Date: Fri, 15 Jun 2001 12:51:18 -0700

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.

>reading the charter what is reasonable and useful about what this

Michael W. Condry
Director,  Network Edge Technology

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jun 2001 15:57:52 -0400

> This sort of analysis is neither valid, useful, or necessary.

Perhaps not.  But I've seen people in working groups make the same assumptions
about charter language, and I think it's a good idea to avoid such misunderstanding.

And while I'd very much like to believe that nobody actually is proposing to
legitimize some of the practices I mentioned in my earlier message, there
is plently of evidence to the contrary.  And some of those folks are likely to
be attracted to a group with this charter.

So the question in my mind is whether this particular group is proposing to 
legitimize such practices.  If not, then please just accept my message as
a request for clarification of the charter, since (if nothing else) having 
such an open-ended charter seems likely to attract folks who really do want 
license to break layering, and those people will distract the group from
its purpose.  (and they do exist, in spades)
 
> Application area working group -> application layer intermediaries.

We do cross-area activities quite frequently.  Obviously the group's scope
would include application layer intermediaries, but the fact that it's in the
apps area doesn't inherently mean that it wouldn't look at other kinds of
intermediaries.  

Put it this way - if we were going to charter a group that was allowed to 
define protocols for intermediaries on multiple layers, would it axiomatically 
be in some area other than apps?  It's not clear to me that it would, and 
daresay I understand the structure of this organization as well as anyone else.

Keith

---

From: Ian Cooper <[email-masked]>
Date: Fri, 15 Jun 2001 13:33:29 -0700

>The charter covers none of these things.

*cough*

I'd seriously hope it would cover proxies and gateways, for some 
definitions of those terms anyhow!!!

---

From: "B. Scott Michel" <[email-masked]>
Date: Tue, 19 Jun 2001 17:23:09 -0700

> that operate on multiple layers ?

I think, and you might or might not agree with me, that OPES is a reaction
to evolution that's occuring in peer-to-peer applications. In a general
sense, there is a need to be able to embed "transit intermediaries" to
transform and operate on a message flow from a source peer to a destination
peer. Think of it not as peer-to-peer applications but peer-through-peer
networking that provide store-and-forward characteristics.

OPES, it seems to me, is trying to deal with a legacy client-server system
and transforming it into something that looks and tastes a bit like a
store-and-forward peer-through-peer networking system for X-over-HTTP or
interneworking between cache/content-delivery systems. The WG might uncover
interesting issues that would be useful for future peer-through-peer network
systems.

Architecturally, it seems to me that there are three components in a
"peer-through-peer" system forwarding layer, if location-independent naming
is used to identify remote peer resources:

a) topology construction to create "peer subnetworks" and interconnect peer
subnetworks
b) routing to propagate names and name space region reachability,
c) forwarding based on names from a source peer through transit peers to a
remote peer or peers

In such a system, interception and redirection are explicit ("I'm forwarding
this to a next-hop peer because they are on a path..."), and OPES recognizes
this. It's also desireable for the transit peers to be functionally
transparent, from the perspective that new types of peers can be added as
transit peers or intermediaries without changing the upper layer application
protocols. OPES assumes HTTP as a lingua franca that can be bent (as it has
been) to accomplish functional transparency.

I would tend to agree with you that that time might be better spent on
defining a peer-through-peer networking framework that defines a general
purpose forwarding layer for peer-through-peer systems. I do have some
thoughts in this regard that I could BOF. But there may be some utility on
OPES that uncovers the challenges for legacy systems.

-scooter