Subject: [midcom] Compromise on OOP Agents?

From: "Fleischman, Eric W" <[email-masked]>
Date: Tue, 19 Jun 2001 15:04:14 -0700

I don't want to influence the straw poll with this posting, 
but Pyda's and Keith Moore's recent postings both suggested a 
compromise solution to me that I wanted to explicitly ask the 
group about. Specifically, what would the WG's reaction be 
to the following idea, which I propose as a potential 
compromise position:

1) The framework document primarily deals with In-Path 
Agents -- i.e., restricts itself to the scenarios identified 
by Christian Huitema's Scenarios draft, which I believe is 
the charter of both the FW document and this WG. In-Path 
Agents will thus comprise the vast majority of the material 
within the frameworks document.
2) However, the framework document should explicitly mention 
that OOP agents are an implementation possibility and that 
the following benefits accrue by including OOP agents 
(an enumeration can then be made by the OOP advocates).
3) However, should OOP agents be implemented, those OOP 
agents should be implemented to appear to be MIDCOM Agents 
resident on end systems (and, by implication, their 
implementation is accomplished via proprietary/vendor-
specific methods rather than something specifically detailed
by the Midcom WG).

--Eric

-----Original Message-----
From: Pyda Srisuresh [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 2:26 PM
To: Melinda Shore; [email-masked]
Subject: Re: [midcom] Straw poll - out-of-path midcom agents

I believe, the framework document should make the distinction
between In-Path and Out-Of-Path (OOP_ agents. There is no difference
in MIDCOM protocol, per se, irrespective of the agent type. Support
for diversion function or its implementation can be vendor proprietary.
There has never been a suggestion that this WG (or the follow-on WG)
should address it.

Not all applications have In-Path entities such as Proxies or Gateways.
There are many that dont. For those applications, the only viable choice
that this WG offers would be to fold the agent into end-hosts. This is
not necessarily a scalable or acceptable solution.

Even when an application has In-path entities(say proxies), there are
many enterprises that dont run them. It is not necessarily economical 
to run the agent on these entities, even when an enterprise has these
proxies installed in-house. The MIDCOM agent should not be mandated 
to run on just the In-path entities. 

There are many ASP vendors that might have a  proposition to 
accomplish the same using OOP agents, more economically - Say, running
the same OOP agent to work with multiple enterprises to enable a 
specific application (or) a set of applications. OOP agents have
the advantage of not being tied to a certain topological restriction.  

As such, it would be a mistake for the FW draft to restrict the use
or mention of OOP agents.

To reiterate - I believe, Support for OOP agents on a middlebox could be 
made vendor proprietray and as such, the diversion function or its 
implementation can be out of bounds for this WG (or the follow-on WG).

Ignoring or failing to mention the OOP agents in a MIDCOM framework
document is, at best, an incomplete work.

regards,
suresh

--- Melinda Shore <[email-masked]> wrote:
> We've been going around and around on out-of-path agents
> since the first draft of the document and it's my sense
> that we're failing to make progress on it.  I'd like to
> take a straw poll to see how much support there is for
> including support for diversion to out-of-path agents.  
> Please indicate to the mailing list whether or not you'd
> like us to include consideration of out-of-path agents.
> Be prepared to defend your position :-).
> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom

__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom

---

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

fwiw, I'm also opposed to midcom working on OOP agents, now or ever.

Keith