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

From: "Maciocco, Christian" <[email-masked]>
Date: Mon, 18 Jun 2001 17:13:13 -0700

IMHO OPES can offer a standard way of defining and running services but
cannot prevent people from mis-using it. The trust model including security,
policy, etc. is one of OPES' biggest challenge.

Christian

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Monday, June 18, 2001 3:30 PM
> To: Maciocco, Christian
> Cc: 'Daniel Senie'; Scott Brim; [email-masked]
> Subject: Re: WG Review: Open Pluggable Edge Services (opes)
> 
> 
> How is this enforced? I.e., what prevents an ISP from running an 
> ad-insertion service using OPES mechanisms in transparent proxies?
> 
> I know that the group working on OPES doesn't intend these uses. 
> However, there isn't anything in the design that will prevent them 
> (please tell me if I've missed something), and everything I've seen 
> indicates that interposition of services by access providers 
> is by far 
> the largest market for this technology.
> 
> Cheers,
> 
> 
> Maciocco, Christian wrote:
> 
> >>Publishers care if their content is damaged in flight (e.g. 
> >>proxies which remove or alter content, which includes AOL's 
> mangling of 
> >>graphics). They also may care to know how many people and 
> which people are
> >>
> > 
> >>accessing content.
> >>
> > 
> > One advantages offered by OPES is that the publisher only 
> allows their
> > trusted services to be run at the edge(s) of the network. 
> Services are run
> > explicitely, not transparently.
> > 
> > 
> >>I think OPES will further the sale of SSL accelerator boxes and web 
> >>certificates. If the only way to protect content from 
> >>uninvited third-party intermediaries, then content which is 
> not otherwise 
> >>confidential is going to be encrypted.
> >>
> >>It's one thing if the publisher purposely buys the services 
> >>of a content delivery network, it's quite something else 
> when someone
> >>
> > inserts a 
> > 
> >>transparent proxy, especially one which alters the content.
> >>
> > 
> > See above.
> > 
> > Christian
> > 
> > 
> >>-----Original Message-----
> >>From: Daniel Senie [mailto:[email-masked]]
> >>Sent: Monday, June 18, 2001 2:01 PM
> >>To: Scott Brim; Mark Nottingham
> >>Cc: [email-masked]
> >>Subject: RE: WG Review: Open Pluggable Edge Services (opes)
> >>
> >>
> >>At 04:23 PM 6/18/01, Scott Brim wrote:
> >>
> >>>Publishers lose control of how a resource is treated but still
> >>>(optionally) retain control over the resource itself, e.g. through
> >>>watermarks.  I doubt that publishers care if their content 
> is carried
> >>>over Ethernet or ATM today.
> >>>
> >>
> >>
> >>> How much do publishers care how their
> >>>content is encapsulated, routed, encoded, etc.?
> >>>
> >>Publishers care if their content is damaged in flight (e.g. 
> >>proxies which 
> >>remove or alter content, which includes AOL's mangling of 
> >>graphics). They 
> >>also may care to know how many people and which people are 
> >>accessing content.
> >>
> >>
> >>> What do you think OPES
> >>>could do that a publisher (1) would be concerned about, 
> and (2) could
> >>>not protect against?
> >>>
> >>I think OPES will further the sale of SSL accelerator boxes and web 
> >>certificates. If the only way to protect content from 
> >>uninvited third-party 
> >>intermediaries, then content which is not otherwise 
> >>confidential is going 
> >>to be encrypted.
> >>
> >>It's one thing if the publisher purposely buys the services 
> >>of a content 
> >>delivery network, it's quite something else when someone inserts a 
> >>transparent proxy, especially one which alters the content.
> >>
> >>
> >>>On 18 Jun 2001 at 12:51 -0700, Mark Nottingham apparently wrote:
> >>>
> >>>>As such, the OPES goals break end-to-end transparency at the
> >>>>application layer. As a result, (using HTTP as an 
> >>>>
> >>example, because it
> >>
> >>>>seems the first target of OPES), the publisher loses 
> >>>>
> >>control over a
> >>
> >>>>resource once it leaves their server. It then becomes 
> >>>>
> >>impossible to
> >>
> >>>>makes statements about that resource (e.g., P3P, Semantic 
> >>>>
> >>Web, legal
> >>
> >>>>status of a resource, etc.).
> >>>>
> >>-----------------------------------------------------------------
> >>Daniel Senie                                        [email-masked]
> >>Amaranth Networks Inc.                    http://www.amaranth.com
> >>
> >>
> >>
> > 
> 
> 
> -- 
> Mark Nottingham, Research Scientist
> Akamai Technologies (San Mateo, CA USA)
> 
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 18 Jun 2001 22:45:49 -0400

> cannot prevent people from mis-using it. 

yes, but is there a significant need for these services outside of 
the mis-uses of those services?

and given that a significant amount of folks seem to want these for the sole
purpose of abusing the rights of content-providers, will this group basically
be using IETF's reputation to try to legitimize the practice?

Keith

p.s. reminds me of an old Tom Lehrer song
"when rockets go up, who cares where they come down...that's not my department"

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jun 2001 09:31:14 -0500

It seems to me there are 3 ways the world could go, and no 4th option:

1. Something OPES-like will be standardised in the IETF

2. Something OPES-like will be standardised in another organisation, perhaps 
   one with less clue than the IETF about scaling and security.

3. Non-standardised OPES-like things will be widely deployed.

Pick the one you prefer. 

   Brian

---

From: "Michael W. Condry" <[email-masked]>
Date: Tue, 19 Jun 2001 07:55:51 -0700

Keith-
Our interest in OPES and the interest of the folks we are working with
are not with services such as unrequested ad insertion or other items that 
might
be viewed as offensive. Lots of things can be mis-used, SPAM email
is a better example; we even get it on the working group mailing lists, ever
read the WEBI mailing list?

Although you have made many comments on the charter as well
as your thoughts during the open area applications meeting I have not
seen you at the OPES BOFs or OPES workshops. There you could
hear a diverse set of applications that I would be surprised if you would
feel to be offensive. We plan to have a '"Deployment Scenarios" document
that describes a range of applications and constructive comments from
you would be appreciated.

Offensive services can be done at the server end of things as well, such
as ad-insertion; so the edge architecture is not the issue. We have
recorded your key point that is doing modifications on the content
without the permission of the "ends" (client and server) of the operation.
OPES is quite clear about this requirement.

So, I would like to distinguish "Keith offensive services" regardless
of where there are done from the architecture being discussed
under the proposed OPES working group. Maybe someday a
I-D on "Keith offensive services" could be generated but its
not clear that people building these services would care. These people
are not the OPES team.

Michael

>"when rockets go up, who cares where they come down...that's not my 

Michael W. Condry
Director,  Network Edge Technology

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 11:59:20 -0400

> might be viewed as offensive. 

I've already invited you guys to provide some justification for OPES.
So far I've heard only hand-waving.   Merely having useful applications
for OPES is not sufficient; you also have the burden of explaining why
these applications justify destroying the end-to-end model along with
the various consequences of that design choice.

In fact, I don't doubt that there are some useful applications for OPES, 
but there is tremendous potential for harm.  The OPES proponents seem to
want to stick their heads in the sand and pretend that this potential does
not exist.  It doesn't really matter whether this is due to ignorance, 
naivete, or malice.  The bottom line is that the activity proposed for this
group is very dangerous.  Mere hand-waving about the dangers - especially
from a presumed leader of the group - doesn't inspire confidence that the 
group can be trusted to act with foresight or responsibly.

> seen you at the OPES BOFs or OPES workshops. 

IETF is a large organization, and there are lots of things going on.
If you have diverse interests, you have to concentrate your activity in
areas where it will be likely to be useful.  

There seemed to be little utility in my attending OPES BOFs or workshops because 
in my previous experience, the OPES proponents had little or no understanding 
of protocol design issues (including such fundamental concepts as layering) 
and little or no ability to assess the consequences of their design choices. 

> We plan to have a '"Deployment Scenarios" document

Then it seems entirely appropriate to delay any action on the OPES charter until 
this document is complete and has been reviewed by the community.  After all, 
the justification for the working group should come before the group is formed, 
not afterward.

> as ad-insertion; so the edge architecture is not the issue. 

You're entirely missing the point.  If a content-provider wants to be 
offensive, whether by inserting offensive ads or making the content itself
offensive, that's between the provider and any audience the provider might
attract.  Creating a mechanism for which unauthorized third parties can 
change that content, whether to change the level of offsense or for some
other purpose, breaks that relationship between content-providers and their 
audience.

> We have recorded your key point that is doing modifications on the content

Then why isn't it in the charter?

> under the proposed OPES working group. 

So what you're arguing is that having third parties corrupt the data path
between the endpoints is only an issue for me?   Get over it.  
Such arguments don't do anything for either OPES or your reputation.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 19 Jun 2001 09:10:25 -0700

Brian E Carpenter wrote:
> 2. Something OPES-like will be standardised in another organisation,
> perhaps one with less clue than the IETF about scaling and security.
>

One would hope the lack of a credible 'Security Considerations' section
would give the IESG the justification to prevent option 1 (but there should
be plenty of other reasons). I suspect the reason this is even being
discussed in the IETF is that the alternative organizations required for
option 2 were significantly more clueful and told them to go far away, very
far away. So that would leave us with option 3, which is happening anyway.

This leaves the basic question; why are we wasting valuable meeting room
slots on a brain-dead idea where the primary beneficiaries are violating
laws, and the envisioned legal uses can't be obtained with end-to-end
security?

The IESG needs to do some serious navel gazing over the decision to even
allow a BOF on this one.

Tony
Agreeing with MO about the seriousness of the long-term impact of this path
...

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 12:25:27 -0400

> 3. Non-standardised OPES-like things will be widely deployed.

I'd say that we're likely to end up with some of #2 and #3 in any case.

The fact that these exist, or are likely to exist, does not by itself compel
action by IETF, because it's not immediately clear whether IETF's work on #1 
would reduce the abuses present with #2 and #3, or whether IETF's work would 
facilitate a significant increase in abuse.   And the argument that providing 
a standardized interface that facilitiates abuse will increase the amount of 
abuse, is not easily dismissed.

We need to have a better understanding of whether, and under what conditions,
IETF standardization of something OPES-like would benefit the Internet community.
The currently-proposed charter completely ignores the issue.

I believe that it is possible to define an OPES-like service in such a way that it 
can only be used with the explicit consent of at least one of the endpoints.  If 
those constraints were designed in and properly implemented, then IETF's OPES work 
could indeed be beneficial and would be unlikely to do harm.  

However, I doubt that IETF's work on OPES (even if so constrained) would lessen the 
amount of abuse due to #2 and #3.  So I don't see the "external threat" as being a 
justification for doing OPES work in IETF.  

We should judge this proposed group on its own merits, and not approve this group
merely because other folks might be working on similar things for ill purposes.

Keith

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Jun 2001 09:35:00 -0700

>    perhaps one with less clue than the IETF about scaling and security.

i do not intend this to be a comment on the worthiness or not of the opes
effort.  but i very much dislike this argument.

maybe someone else will load mrs. greenberg on the train, but it will not
be i.

randy

---

From: Ian Cooper <[email-masked]>
Date: Tue, 19 Jun 2001 10:24:50 -0700

>read the WEBI mailing list?

I don't think this is a fair example.  Unless you're comparing OPES 
services with open-relay SPAM filters?  (OK, sorry, that's probably another 
Pandora's box I just opened on this list...)

>seen you at the OPES BOFs or OPES workshops.

*cough* not everyone can make it to physical meetings, and while I suspect 
that Keith (since that's who you are addressing) is physically present at 
the IETF meetings it's very possible that he's actually sat in another 
meeting that's take place at the same time.

That's why we have the mailing lists.

>  There you could

I don't think that's quite the objection, though of course I could be wrong.

I haven't seen anyone state *clearly* what the objection is to OPES-stuff 
with relation to the end-to-end nature of the Internet (and why it's still 
applicable even when you have an end-to-end connection between browser and 
OPES proxy).  So here's an attempt (with thanks to the work on the midtax 
document for getting me thinking about this)...

The problem with OPES when deployed in the "general Internet" is that as an 
end user I may experience substantially different experiences (receiving 
very different content) depending on my entry point.  So, for example, I 
may suddenly find that I'm using a network that doesn't have that virus 
scanning service I was relying on.  Or the French-to-English translation 
service I needed would suddenly be unavailable, so I couldn't browse a 
favorite site any more.

And yes, general caching proxies cause problems too - I can experience 
different views because of aggressive caching or the absence of caching.

That said, it's possible that as a user I could authenticate myself with my 
home/usual Web intermediary so that I could still get at my services.  If 
they're available of course (what happens if I'm at home and the OPES proxy 
goes down - I don't get my virus scanning any more do I...)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jun 2001 12:22:25 -0500

> maybe someone else will load mrs. greenberg on the train, but it will not

I very carefully refrained from making that argument; you (and others) are 
reading it into what I said, which was a factual observation. This is yet 
another game of whack-a-mole. 

My personal views on e2e transparency are well enough known (RFC 2775). 
I like it.

   Brian

---

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 19 Jun 2001 15:59:57 -0400

This debate over OPES appear sto have a blend of technology religion,
business interest, and even some hand-waving or other failures to
communicate at its core.   I, too, can quibble with the proposed charter but
there is a need for a standard mechanism for calling services that operate
on http (and possibly rtp) messages at an [application-level] intermediary.

In general, the technical and industry requirements can be demonstrated by
the fact that there are emerging w3c standards and implementations for
constructing distributed applications by calling web services and,
specifically with respect to edge services, by the fact that there are
edge-of-network implementations that provide various transform services,
e.g., virus scan, language translation, and, yes, content adaptation based
on device and network capabilities.  These aren't layer violations, some of
these applications are, however, aware of the protocol layers much the way a
management application can be layer-aware.  These intermediaries exist and
they will continue to do so.  The only question is are there standards.

The requirement for doing this at an application intermediary in a standard
way is the usual requirement for standards:  the industry serves its
customers best when products interoperate.  Standards for selecting the
services to be called (rules) and how to call them (service bindings and
protocols) will provide interoperability in constructing those distributed
applications.   One of the areas for investigation in the working group
(assuming it gets chartered) is whether we need something unique to edge
services (a la icap) or whether something more general is appropriate (a la
soap).

I, personally, don't think the applications need to justify themselves
against a model; rather, models may provide insights in the presence of
reality.  The problem is fundamentally one of scaling.  How do we distribute
the work load, provide an improved user experience and do so with an
authenticated and authorized set of rules?  If OPES can help answer those
questions, I'm not sure what the problem is.  There may well be "better"
ways of building these distributed applications, but the market has chosen
these application intermediaries as an evolutionary step.  It would be a
mistake for the IETF to abdicate its responsibility here.

Lee M. Rafalow
Voice: 1-919-254-4455, Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Personal email: [email-masked]

---

From: "Melinda Shore" <[email-masked]>
Date: Tue, 19 Jun 2001 17:00:02 -0400

> The only question is are there standards.

I'd dispute that it's the *only* question, but anyway,
there are a lot of standards bodies out there.  

I've had to think about these questions quite a lot, since
midcom certainly engendered a similar level of hostility.
I think it does matter - there's an idiom to IP networking,
and if what you do on top of IP isn't idiomatic things are
inevitably going to be clunky and, at worst, break
completely.  That said, I don't think it's accurate that
the cause of all of this unidiomatic crap in the network
is the result of lack of understanding (or outright
stupidity) on the part of those doing the crap.  I think
the problem is that with the commercial success of IP the 
economic model has changed and the incentives have changed.
It's inevitable that there's been a technical response to
the change in incentives.

We've always behaved as if the notion that the value of
the network is a function of the number of connected nodes
is true.  While it may very well be, I think we now need
to start raising the question of value to whom and
whether or not there might be other considerations.  It
may be the case that my network is more valuable to me if
I have access to you, but that it's less valuable to me if 
you (and you and you and you) have access to it.

Because enterprises want to protect their property and
service providers want to be able to make money with their
services they're asking for the means to make the edges of
their networks visible.  They're working from a business
model that requires it.  Many of the middleboxes we're
arguing about are instantiations of policy, and policies
are instantiations of business models.  It seems clear to
me that if we want to restore end-to-end networking we need
to find alternate business models.  Finger-shaking won't
solve the problem.

Melinda

---

From: [email-masked]
Date: Tue, 19 Jun 2001 14:58:48 -0700 (PDT)

Lee,
	The debate does have a blend of technology, religion, business
interest, and historical allusion.  At its core, though, is a serious
question: does the desire for a mechanism for calling services that
operate on application level messages at an intermediary outweigh the
desire to maintain an application infrastructure that mirrors the
end-to-end datagram model of the underlying routing system and, if so,
does the fulfillment of that desire require an interoperable standard?
(I said it was a serious question, but I didn't promise it was one
that you could get out in one breath).
	As someone who worked for a long time in content negotiation
(as chair of CONNEG in the IETF and, for a short time, as a
contributor to the CC/PP effort in the W3C), I am well aware of the
existing intermediaries in the system.  The application infrastructure
is already using systems which do not mirror the end-to-end routing
system (and the end-to-end routing system has multiple address realms
now as well, but that is a different kettle of fish).  As you note,
the question about these intermediaries is not whether they exist,
but it also not whether or not there are standards.  The question
is how they interact with the applications which pass traffic through
them.
	OPES makes no claims in this regard and that, I suspect, is a
large part of the problem the readers of this list have with its
charter.  OPES proposes to standardize an enabling protocol with no
definition of what it might enable.  From a practical standpoint, the
arbitrary nature of the services which OPES might enable creates the
need for an enabling protocol of extraordinary flexibility, where the
IETF has historically done better biting off rather small problems.
Hilarie Orman noted earlier in this thread that OPES "is motivated by
notions of dynamic content and the notion of distributed semantic
evaluation.  It is a logical general of caching....The OPES
architecture and protocols go a long way towards building an
application friendly Internet by developing standards for a coherent
substrate for scalable application deployment.  This allows caches and
gateways to provide the services needed for rich content."  I think "a
coherent substrate for scalable application deployment" is a pretty
big chunk, and not one that many IETF working groups would likely get
through.
	From an architectural standpoint, it is absolutely impossible
to tell what applications might be broken, transformed, or improved
once OPES's enabling protocol is in place.  Frankly, that's pretty
scary, as having an interoperable enabling protocol may not do us much
good if it enables things that break the applications themselves.  The
charter acknowledges some of these fears; it specifically rules out
the possibility of a "transparent" service (for which read
"interception proxy"): "Intermediary services provided in this way are
not transparent: Either the content requestor or provider will be
aware that a tranformation has been performed."  This doesn't handle
the problem, though, it merely improves debugging.  To handle the
problem, the working group would have to define either an architecture
which ensured that the applications worked correctly whether the
intermediary services were called or not (not likely to cover
"arbitrary" services, and very dependent on specific applications) or
one in which the availability of services is not dependent on the
network path taken by the application layer message.  Both of those
seem outside the task the working group has set itself.
				regards,
					Ted Hardie

>  This debate over OPES appear sto have a blend of technology
> religion, business interest, and even some hand-waving or other
> failures to communicate at its core.  I, too, can quibble with the
> proposed charter but there is a need for a standard mechanism for
> calling services that operate on http (and possibly rtp) messages at
> an [application-level] intermediary.  In general, the technical and
> industry requirements can be demonstrated by the fact that there are
> emerging w3c standards and implementations for constructing
> distributed applications by calling web services and, specifically
> with respect to edge services, by the fact that there are
> edge-of-network implementations that provide various transform
> services, e.g., virus scan, language translation, and, yes, content
> adaptation based on device and network capabilities.  These aren't
> layer violations, some of these applications are, however, aware of
> the protocol layers much the way a management application can be
> layer-aware.  These intermediaries exist and they will continue to
> do so.  The only question is are there standards.  The requirement
> for doing this at an application intermediary in a standard way is
> the usual requirement for standards: the industry serves its
> customers best when products interoperate.  Standards for selecting
> the services to be called (rules) and how to call them (service
> bindings and protocols) will provide interoperability in
> constructing those distributed applications.  One of the areas for
> investigation in the working group (assuming it gets chartered) is
> whether we need something unique to edge services (a la icap) or
> whether something more general is appropriate (a la soap).  I,
> personally, don't think the applications need to justify themselves
> against a model; rather, models may provide insights in the presence
> of reality.  The problem is fundamentally one of scaling.  How do we
> distribute the work load, provide an improved user experience and do
> so with an authenticated and authorized set of rules?  If OPES can
> help answer those questions, I'm not sure what the problem is.
> There may well be "better" ways of building these distributed
> applications, but the market has chosen these application
> intermediaries as an evolutionary step.  It would be a mistake for
> the IETF to abdicate its responsibility here.  Lee M. Rafalow Voice:
> 1-919-254-4455, Fax: 1-919-254-6243 IBM Internet Technology
> Management IBM Corporation P.O. Box 12195, BRQA/502 RTP, NC 27709
> USA Alternate email: [email-masked] Personal email:
> [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 18:09:22 -0400

wow...I'm not sure we fundamentally disagree about the outcome,
but this seems to contain several different kinds of confusion.

1. "intermediary":  Lately it has become fashionable to use this term
as a catch-all to describe any network element between the endpoints,
acting at any layer of the protocol stack.  Such usage tends to
gloss over several important issues, such as whether the intermediary
introduces layering violations (and the problems that come with doing so),
or whether the intermediary is acting with explicit consent of at least
one of the endpoints (and the associated issues with control of content).
So we shouldn't treat all intermediaries as if they are equally useful
or valid.

2. The fact that there are emerging standards (by IETF, w3c or anyone else)
emphatically does not demonstrate requirements.  Old issues of trade 
magazines are full of references to standardization efforts that went
nowhere - often they were trying to solve the wrong problem, because
their work was obsolete before they started, of simply because they
didn't understand the problem they were trying to solve.

3. Similarly, the fact that the "market" has chosen a particular path does
not justify that choice as good engineering, and the IETF does not have 
a responsibility to endorse bad engineering.  Deployment in some form
is a necessary condition for an engineering solution to be successful, but
"market acceptance" is not a sufficient condition for engineering success.  
The market is quite often wrong.

I don't doubt that it would be useful to have a standard mechanism for
modifying content (even in fairly arbitrary ways) before it is transmitted 
to an audience, or to modify it on receipt by a member of that audience.
And you cite a number of valuable services that could take advantage of
such a mechanism.  But the charter currently under discussion is a lot 
more open-ended than that, and that's part of why it's controversial.

Keith

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 19 Jun 2001 16:12:37 -0700

Has everyone who has a reallyreallyreally strong opinion on this 
matter actually read the charter? Right there near the top, it says:

>Intermediary services provided in this way are not transparent: 
>Either the content requestor or provider will be aware that a 
>tranformation has been performed.

OK, so the spelling is not so great, but it sure is clear. What some 
people seem to be up in arms about is that the IETF would even think 
of helping someone change the content in HTTP. Data mungers are doing 
that already, and it is bad, and it is untraceable. So what should 
the IETF do?

- Bury our head in the sand and at the same time keep yelling 
"end-to-end", thereby getting sand in our mouths and having the other 
people on the beach laugh at our collective and rapidly-aging rear 
ends

- Let some other group create a standard, even though that group 
probably cares much less about both end-to-end integrity or alerting 
one or both sides than the IETF does

- Create a standard that does a really good job of allowing one end 
(or, hopefully both ends) know what has been changed and why, in an 
interoperable fashion

If my data coming or going gets changed, I want to be notified; that 
cannot happen now.

As for the argument about "TLS everywhere", you have to ask who is 
going to pay for it. The end-user cannot demand it; only the server 
can. TLS is universally available today, and servers rarely use it 
for anything other than getting credit cards or passwords.

Data is already being changed, some of in ways that we should really 
be unhappy about, and there is no way for the folks changing it to 
tell either end. OPES gives them that capability. Post-OPES, data 
will still get changed silently without using OPES, but at least 
there can be pressure put on the changers to use OPES so that someone 
sees what is happening. Without OPES, they never will.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 19:29:17 -0400

> stupidity) on the part of those doing the crap.  

not all of it, but some of it does demonstrate a profound
lack of foresight.

> I think

and the models continue to change, and there's no end in sight
yet.  I think we are in a period of experimentation with 
many different kinds of models to see which ones work best.
It's not at all clear where we will end up, because the models
make assumptions about an economy that is itself changing.

to take a crude exmaple, if banner advertisements continue
to drop in value, business models based on insertion of
banner ads that seem viable today may not seem viable in 
six months' time.

(and there's only so much space in a browser window , and
only so much of a user's attention to be borrowed. someone
is going to have to figure out to whom it belongs :)

> you (and you and you and you) have access to it.

that's a good way of expressing it.

> to find alternate business models.  Finger-shaking won't

I don't think that IETF is compelled to support arbitrary business 
models - especially those that don't make good engineering sense.  

It seems that business models are a bit like religions. You should 
be able to believe whatever you choose, but that doesn't mean you
can realistically expect the rest of the world (or anyone for that 
matter) to conform to it.  And a religion is not a justification to 
harm things that work for others

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Jun 2001 21:47:04 -0400

> that already, and it is bad, and it is untraceable. So what should 

the IETF SHOULD NOT pretend that the practice does not exist.
  (*that* would be burying our heads in the sand)
the IETF SHOULD NOT encourage the practice by making it appear legitimate,
  even by making the endpoints aware of it.
the IETF SHOULD (probably) NOT try to interfere with other groups that 
 might want to standardize this; to do so is to risk getting trapped
 in a herd of lemmings who are bent on jumping off a cliff.

IF, on the other hand, there is a need for pluggable end services
which are *explicitly requested* by one or more end points, the IETF 
SHOULD consider doing work in this area, but it SHOULD also clearly 
distinguish such work from work that interferes with end-to-end 
transparency. 

ELSE, IETF should do nothing.  Sometimes refusing to pretend that your
action can accomplish anything useful really is the best choice.

> tell either end. OPES gives them that capability. 

no it won't.  OPES is an application-level mechanism and the folks
who are corrupting data now are doing so at lower layers.  OPES won't 
change what they are doing.

> Post-OPES, data 

I don't think so.  
Nor do I think this is a worthwhile use of IETF's energies.

Keith

---

From: [email-masked]
Date: Tue, 19 Jun 2001 23:11:43 -0400

> constructing distributed applications by calling web services and,

Remember that the w3c is by definition a vendor of hammers, and thus
has a vested interest in constructing nail-delivery protocols.

Or less cynically put - is calling web services the best way to construct
a distributed application?

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: "Micah Beck" <[email-masked]>
Date: Tue, 19 Jun 2001 23:13:52 -0400

Suppose this clause of the proposed OPES WG charter:

"Intermediary services provided in this way are not
transparent: They have to be authorized by either the
content requestor or the provider, corresponding to
who the service being provided for."

Were modified to read

"Intermediary services provided in this way are not
transparent: They have to be authorized by the provider."

This would put control of all content transformations back in the hands of
the content provider.  If the end user or the ISP wanted a transformation,
they would have to ask to content provider to authorize it.  This would make
the OPES box purely an extension of the content provider's server, and would
only rule out transformations that the content provider is unwilling to
authorize.

With this modification, the end user can only see services intended by the
provider.  The fact that those services might be provided by a distributed
system that used intermediaries would not compromise integrity.

This would rule out business models based on selling intermediary services
that the content provider refuses to authorize.  It would rule out business
models based on capturing content and transforming it in unintended ways.
It would not rule out any business model that is based on the advise and
consent of the content provider.  Automatic mechanisms for providing such
consent could be used in cases where users are pre-approved for a class of
transformations.

I encourage everyone who is in Boston attending the Web Caching and Content
Delivery Workshop to attend the afternoon panel on Thursday on "Rule-Based
Active Edge Services".

Micah Beck

---

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 20 Jun 2001 10:04:55 -0400

There have been and will continue to be experiments in the "best" way to
construct distributed applications.  There are many ways to implement
distributed applications already and, over time, the paradigm may well
change.  But for the foreseeable future the way that has been endorsed by
the companies that will deliver the products to their customers is web
services.  And that endorsement isn't just in the form of a set of emerging
standards, it's in the form of many millions of dollars invested in
software, in infrastructure and in marketing.  There's a whole industry out
there!  And it's not a dot com bubble.

In my personal opinion, icap is a flash in the pan done in isolation and
seeking a standards body, any standards body (although I'm sure they'd like
to have "RFCnnnn" somewhere in their marketing literature).  But the OPES
framework of a rule-based platform for providers to distribute and users to
customize applications is an important problem with interesting and
significant technical challenges.  The iterative approach outlined in the
OPES charter seems perfectly reasonable to me and in keeping with the IETF
strategy for success.

The IETF can defer to other standards bodies if it so chooses, but I believe
the Application Area will eventually become irrelevent in the web arena and
the W3C will take over all of that protocol work. (A current example: where
do we do cache invalidation protocol work and how scalable is the solution?)
I don't think it would be good for the industry, but it's reasonable to
abdicate that responsibility.  But let's make the decision consciously.  The
IETF has been the standards body of choice for protocol work because of the
networking expertise.  Sacred models do not serve a fast paced industry;
informed thought and engineering work do.  That thought and work occur in
the WG, not in a meta-discussion.

We're not going to change any business models, the market will, in it's own
stumbling way, take its course.  We're also not going to make interception
proxies go away no matter what we do.  But we can contribute to providing
Internet-level scalability and improved user experience for the web
applications that are the current and future Internet.

If people have specific suggestions for improving the charter, I personally
welcome them.  If not, I'd like the IETF leadership to make the decision
about whether we're in the business of doing web application protocol work
or not and then decide what to do with the OPES charter request.

Lee M. Rafalow

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Jun 2001 12:14:41 -0400

> there!  

so what?  why is that a justification for demanding IETF's imprimatur on 
protocols and architecture that don't make good engineering sense?

the E in IETF stands for "Engineering".  why then, do so many folks believe 
that it's IETF's purpose to endorse their business models?

> Sacred models do not serve a fast paced industry; informed thought and 
> engineering work do.  

true enough.  and this applies equally to sacred business models.  

but it's naive to dismiss an underlying architectural principle such as 
end-to-end transparency, or clean separation of layers, as 'sacred'.
to one who understands why they are beneficial, they are not sacred - 
they are (in most cases) essential.

> That thought and work occur in the WG, not in a meta-discussion.

not if that WG is focused on promoting a poorly chosen architecture.
we have to have architectural discussions somewhere, and this is as good a
place as we currently have.

> We're also not going to make interception proxies go away no matter what we do.  

true. but we don't have to endorse them.

> But we can contribute to providing Internet-level scalability and improved 
> user experience for the web applications that are the current and future Internet.

indeed we can, and we should.  but perhaps we should start by examining the 
barriers to scalability that exist in present-day web applications.

> or not and then decide what to do with the OPES charter request.

you will, I hope, recognize that these are separate questions.

Keith

---

From: [email-masked]
Date: Wed, 20 Jun 2001 09:57:21 -0700 (PDT)

> do we do cache invalidation protocol work and how scalable is the solution?)

See draft-day-cdnp-model-06.txt for some of the work going on; though
the CDNI work has not yet resulted in a working group, Mark Day et al
certainly seem to be doing their work with a view to the IETF process
(open publication of documents and input from as broad a community as
possible).  

> or not and then decide what to do with the OPES charter request.

Having a Norwegian Chair does not mean we like red herrings.  The IESG needs
to decide whether or not the work specified in the OPES charter belongs as
a working group effort within the IETF; that does not imply a decision on
whether we're in the business of doing web application protocol work.

			regards,
				Ted Hardie